The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Обновление nginx 1.31.0 с устранением RCE-уязвимости, эксплуатируемой через HTTP-запрос

13.05.2026 23:20 (MSK)

Сформирован выпуск основной ветки nginx 1.31.0, в рамках которой продолжается развитие новых возможностей, а также выпуск параллельно поддерживаемой стабильной ветки nginx 1.30.1, в которую вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей. В обновлениях устранено 6 уязвимостей, наиболее опасная из которых допускает удалённое выполнение кода через отправку специально оформленного HTTP-запроса. Для angie и freenginx на момент написания новости исправления не опубликованы.

Уязвимость (CVE-2026-42945), которой присвоен критический уровень опасности, вызвана переполнением буфера в модуле ngx_http_rewrite_module, которое может быть эксплуатировано для выполнения кода с правами рабочего процесса nginx через отправку HTTP-запроса со специально оформленным URI. Проблема проявляется в конфигурациях с директивой "rewrite", в которой в регулярных выражениях используются подстановки масок при помощи неименованных переменных (например, $1 и $2), при условии, что в заменяющей строке имеется символ "?". Пример уязвимой конструкции:


   rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;

Выражения с именованными подстановками уязвимости не подвержены. Например, уязвимость не затрагивает конструкции:


   rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;

Уязвимость присутствует начиная с версии 0.6.27, выпущенной в марте 2008 года. Причиной появления уязвимости стало то, что буфер выделялся с расчётом, что в него будут записаны неэкранированные данные, а фактически копировались данные после выполнения экранирования спецсимволов, размер которых был больше, так как каждый символ "+", "%" и "&" кодировался не одним, а тремя байтами. Подобное рассогласование возникало из-за того, что при наличии в правиле rewrite символа "?" выставлялся флаг "e->is_args", при котором включалось экранирование, но выделение буфера осуществлялось при сброшенном флаге, при котором экранирование не применялось.

Другие уязвимости:

  • CVE-2026-42926 - возможность подстановки данных атакующего в проксируемый запрос при использовании в настройках директивы "proxy_set_body" и обращении к бэкенду через HTTP/2 (proxy_http_version=2).
  • CVE-2026-40701 - обращение к памяти после её освобождения (use-after-free) в модуле ngx_http_ssl_module, возникающее при обработке ответов от DNS-сервера в конфигурациях с директивой "ssl_ocsp".
  • CVE-2026-42946 - чтение из области за пределами буфера в модулях ngx_http_uwsgi_module и ngx_http_scgi_module, возникающее при обработке специально оформленного ответа. Проблема может привести к утечке содержимого памяти рабочего процесса или его аварийному завершению.
  • CVE-2026-42934 - чтение из области за пределами буфера в рабочем процессе, возникающее при обработке ответов с декодированием из кодировки UTF-8 при использовании директивы "charset_map". Проблема может привести к утечке содержимого памяти рабочего процесса или его аварийному завершению.
  • CVE-2026-40460 - уязвимость в реализации протокола HTTP/3, допускающая спуфинг IP-адреса для обхода авторизации или ограничений.

Улучшения, добавленные в выпуске nginx 1.31.0:

  • В состав включён модуль ngx_http_tunnel_module, реализующий возможность работы в виде прокси ("forward proxy"), перенаправляющего запросы на другой сервер при обращении клиента при помощи метода HTTP/1.1 CONNECT. Возможна настройка аутентификации обращения к прокси, используя директивы "auth_basic", "satisfy" и "auth_delay".
  • В блок "upstream" добавлена директива "least_time", включающая метод балансировки нагрузки с передачей запроса серверу с наименьшими средним временем ответа и наименьшим числом активных соединений.
  • В модуль "stream_proxy" добавлена директива "proxy_ssl_alpn" для задания списка протоколов, допустимых в расширении ALPN при подключении к проксируемому серверу. Например: "proxy_ssl_alpn h2 http/1.1".
  • Обеспечено отклонение запросов по протоколам HTTP/2 и HTTP/3, включающим заголовки "Connection", "Proxy-Connection", "Keep-Alive", "Transfer-Encoding", "Upgrade".
  • В модуле ngx_http_dav_module обеспечено отклонение запросов COPY и MOVE с повторяющимися исходным и целевым ресурсом или вложенными коллекциями.
  • Уровень логгирования ошибок SSL "invalid alert", "record layer failure" и "SSL alert number N" понижен с "crit" до "info".
  • В скрипт configure добавлен параметр "--without-http_upstream_sticky_module" для отключения сборки модуля http_upstream_sticky_module (параметр "--without-http_upstream_sticky" объявлен устаревшим).


  1. Главная ссылка к новости (https://nginx.org/news.html...)
  2. OpenNews: В Apache httpd 2.4.67 устранена уязвимость в HTTP/2, не исключающая удалённое выполнение кода
  3. OpenNews: Вышел nginx 1.4.1 с устранением уязвимости, приводящей к удалённому выполнению кода
  4. OpenNews: Атаки, меняющие настройки nginx для перенаправления трафика
  5. OpenNews: Обновления nginx 1.29.7 и 1.28.3 с устранением 6 уязвимостей
  6. OpenNews: Выпуск nginx 1.30.0 и форка FreeNginx 1.30.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/65442-nginx
Ключевые слова: nginx
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (14) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 00:13, 14/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Мартовский отчёт:
    https://www.netcraft.com/blog/march-2026-web-server-survey
     
     
  • 2.3, Аноним (3), 00:15, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Nginx он как Жигули большие объемы выпуска и низкое качество. Вот и итог.  

     
     
  • 3.9, Аноним83 (?), 00:32, 14/05/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     

  • 1.4, Аноним (3), 00:17, 14/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Уязвимость которую с 2008 года случайно никто не заметил. Верим, практикуем.  
     
     
  • 2.5, РКН (?), 00:21, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    О сколько нам открытий чудных
    Готовят просвещенья дух
    И опыт, сын ошибок трудных,
    И гений, парадоксов друг,
    И случай, бог изобретатель...

    А. С. Пушкин.

    P.S. Он уже тогдо о чем-то таком догадывался.

     
     
  • 3.7, Аноним (3), 00:24, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Пушкин не догадывался что аналогичные АНБ организации будут приходить к разработчику нжинкс и говорить где ему оставлять уязвимости.
     
  • 3.8, Аноним (3), 00:24, 14/05/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 3.15, Аноним (15), 01:01, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > О сколько нам открытий чудных
    > Готовят просвещенья дух
    > И опыт, сын ошибок трудных,

    Пердух.

     
  • 2.6, Аноним (3), 00:22, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Как же админа этого сайта бомбит от того что про нжинкс говорят правду как она есть. И админ не может с этим смириться.
     
  • 2.10, Аноним83 (?), 00:33, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    А должны?
    Вот вы собирали nginx с ASAN и потом гоняли под нагрузкой?
     
  • 2.11, Аноним (11), 00:39, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Тысячи глаз, они такие.
     

  • 1.12, Аноннейм123 (?), 00:41, 14/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В большинстве конфигураций nginx что я видел люди предпочитают этот модуль не использовать, плюс найти уязвимость и уметь ее проэксплуатировать это 2 большие разницы
     
     
  • 2.14, Аноним83 (?), 00:49, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Это rewrite то не использовать!?
    Видимо вы какие то статические лэндинги видили.

    dokuwiki, nextcloud в конфигах когда оно не на отдельном домене а в директории - без реврайтингов не может.

     

  • 1.13, Аноним83 (?), 00:45, 14/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очередная реклама LLM.
    https://depthfirst.com/nginx-rift

    Перечитал но так и не увидел реального PoC или даже близко к нему, только общие рассуждения что это возможно если+если+если...короче нейрослоп какой то.
    По факту это больше похоже DoS приводящий к просадке производительности из за систематического караша ворверов.

    В остальном, я доверяю nginx и не хочу его пихать в chroot как я тут уже упихал всё остальное.
    cups вот реально страшный комбайн, и упихать его в chroot не очень тривиальное занятие.
    dnsmasq легко упихался, почти не сопротивлялся :)
    Ещё apcupsd упихать можно, но тогда он сервер погасить не сможет...

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2026 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру