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 обязательно


Обсуждение (51) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 00:13, 14/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Мартовский отчёт:
    https://www.netcraft.com/blog/march-2026-web-server-survey
     
     
  • 2.34, Аноним (34), 09:09, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Графа other продолжает медленно, но верно расти. Вытесняя устаревший и дырявый nginx.
     
     
  • 3.39, Tron is Whistling (?), 10:18, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Смещение апача в отхерию произошло только из-за того, что банально стали прятать собственно идентификацию типа сервера. А так его всё столько же почти. За клаудшмарой тоже зачастую он.
     
     
  • 4.40, Tron is Whistling (?), 10:20, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    (если к графику приглядеться - падение апача почти в точности повторяет рост отхера, что бы это могло быть :) )
     
     
  • 5.46, Аноним (46), 11:04, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не думаю, что отсюда можно делать далеко идущие выводы. Варианты:
    1. Апач стали прятать за нелепыми названиями
    2. Апач стали заменять на что-то более адекватное
    3. Просто независимые величины со случайной корреляцией

     
     
  • 6.51, Tron is Whistling (?), 12:06, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > 1. Апач стали прятать за нелепыми названиями

    Yes. В т.ч. за Nginx/Cloudflare

    > 2. Апач стали заменять на что-то

    Минимально, где была необходимость.

    > 3. Просто независимые величины со случайной корреляцией

    А вот тут графики против - на графиках у апача и отхера почти полная симметрия, с небольшим отклонением как раз на (2) в сторону named, а не отхера.

     
     
  • 7.52, Tron is Whistling (?), 12:07, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    (уточнение: симметрия наблюдается по 1 производной, т.е. по изменению)
     
  • 5.63, Анонисссм (?), 15:45, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >падение апача почти в точности повторяет рост отхера

    не видел апача в проде лет 15. tomcat/netty/nginx это всё используется

     
  • 4.66, Аноним (66), 16:46, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > стали прятать собственно идентификацию типа сервера

    Интересно, зачем бы это делать? Может быть из-за высокого качества этого сервера? 🤔

    Или потому, что массово выкидывают внешний HTTP сервер и заменяют на встроенный в приложение? Не, бред какой-то, специально делают чтобы статистику подпортить.

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

  • 1.4, Аноним (34), 00:17, 14/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Уязвимость которую с 2008 года случайно никто не заметил. Верим, практикуем.  
     
     
  • 2.10, Аноним83 (?), 00:33, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    А должны?
    Вот вы собирали nginx с ASAN и потом гоняли под нагрузкой?
     
     
  • 3.55, Аноним (55), 13:08, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > А должны?

    Думается, что Центр Развлекательных Услуг должен был как-то проводить аудит.

     
  • 2.11, Аноним (11), 00:39, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Тысячи глаз, они такие.
     
     
  • 3.32, Аноним (34), 09:03, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да даже глаза мейнтейнера не хотят видеть коммиты на исправлениеие. Если у мейнтейнера заказ на эту уязвимость.  
     
     
  • 4.56, Аноним83 (?), 13:16, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Меинтейнерам часто не платят, поэтому они и смотрят раз в пол года когда им самим надо.
     
  • 3.59, нах. (?), 14:00, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    шоколадненькие, ога
    но видимо ребятам дали подержаться за mythos или просто модельку поприличней

     
  • 2.38, Аноним (38), 10:09, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Этой уязвимости уже 18 лет. Совершеннолетняя.
     
     
  • 3.50, Аноним (-), 12:03, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Этой уязвимости уже 18 лет. Совершеннолетняя.

    Ну так вот, как стала совершеннолетней - так ее и... :)

     
  • 3.53, Аноним (53), 12:07, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    18 лет назад это могло не быть уязвимостью, просто потому что nginx либо вообще не принимал заголовки более 4к, либо дефолты были другие.
     

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

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

     
     
  • 3.16, Аноним (16), 01:36, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > не на отдельном домене а в директории

    Эталoннoe нeнyжнo ведь, зачем так делать?

     
     
  • 4.20, Аноним83 (?), 03:35, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У меня городить домены верхнего уровня нет возможности.
     
     
  • 5.44, ы (?), 11:00, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    от этого оно не перестаёт быть костылём
     
  • 5.67, Аноним (66), 17:16, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    В года бородатые в одном коллективчике админы чётко делились на три категории: те, у кого был рут от прода, те, у кого не было, и те, у кого был рут вообще от всего, включая ДНС. Ты, вижу, из второй категории.
     
     
  • 6.71, Аноним83 (?), 17:49, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    У меня динднс домены, даже если бы я мог (а кое где могу) создавать домены верхнего уровня - то это не переносимо, ибо в других местах мне не дают так делать.
    Да, это бомжатский сервер всё в одном, но кто сказал что должно быть иначе?
     
  • 3.29, Аноним (53), 05:57, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Переписывание URI - это костыль. nginx, чья роль по сути является быть терминирующей прокладкой всего того бреда, что понакрутили вокруг HTTP, максимум должен по матчам понять, к какому бэку отправить запрос. Реврайт параметров в пути - это размазывание функционала.
     
     
  • 4.42, ы (?), 10:28, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    а у них lamp. поэтому обрабатывать uri самостоятельно - лапки.

    вот таких и должен заменить ии. и туда им дорога.

     
     
  • 5.54, Аноним (53), 12:11, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Лучше бы таких заменили люжи, которым не пофигу. Ллмки сами натренерованны на лютом гкоде, который пишется для выполнения тасков манагеров, а не для эволюции кода самого по себе.
     
     
  • 6.68, Аноним (66), 17:19, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > для эволюции кода самого по себе

    В очередной раз подтверждаешь мой тезис о том, что без менеджмента программисты будут заняты бесконечной оптимизацией тулчейна вместо работы.

    Никому не нужна «эволюция кода», деньги платят за решение задач бизнеса. Те, кто это не понимает будут заменены ллм.

     
  • 2.33, Аноним (34), 09:06, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Конечно Пото у эксплуатировать уязвимость должны только свои люди, а не левые васяны.
     

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

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

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

     
     
  • 2.30, Аноним (30), 08:07, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >я доверяю nginx и не хочу его пихать в chroot как я тут уже упихал всё остальное.

    Это почему-ж? Ты думаешь нжиксу в чруте сильно плохо будет?

     
     
  • 3.57, Аноним83 (?), 13:19, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, дело в другом.
    С одной стороны там мастер процесс всё равно под рутом работает.
    С другой у меня там довольно расвесистый конфиг и придётся кучу путей пробрасывать, которые ещё надо будет все найти.
    Это при том, что реальных уязвимостей в нём никогда не было.
     
     
  • 4.69, Аноним (66), 17:22, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > мастер процесс всё равно под рутом
    > расвесистый конфиг
    > кучу путей пробрасывать, которые ещё надо будет все найти

    Классика администрования локалхоста. Что-то откуда-то накопировал не глядя, что в системе происходит одному богу ведомо, что-то поменять невозможно в принципе, в одном месте изменил -- в другом всё отвалилось.

    Ну попроси ллм, она разберётся и поможет.

     
     
  • 5.72, Аноним83 (?), 17:52, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Не настолько всё плохо, но конфиг за 15 лет порядочно разросся и там куча всего прикручено.
     

  • 1.17, Аноним (17), 02:43, 14/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    rewrite_module для тех, кто не смог сделать красивую и информативную страницу 404 "Ой, что-то пошло не так"
     
     
  • 2.21, Аноним83 (?), 03:37, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для этого давно есть другие способы, типа:
    error_page 404 = /landing.html;
     

  • 1.36, Аноним (36), 09:26, 14/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Да что такое, опять ненастоящие сишники попались. Да как так то?
    >вызвана переполнением буфера
    >Уязвимость присутствует начиная с версии 0.6.27, выпущенной в марте 2008 года.

    Напоминаю, что работа над ATS, языка с зависимыми типами, началась в 2006.

     
     
  • 2.41, Tron is Whistling (?), 10:22, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Равно как и над многими другими.
    Но вот проблема - real world занимают C, C#, Java и PHP.
    Все остальные фантазии тихонечько помирают.
     
  • 2.43, Хру (?), 10:44, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Погрузился я тут с Вашей подачи в Lean 4. Впечатление - надо мозги перестраивать с императивного стиля в этот. Эти инструменты хорошо зайдут с контрактным программированием, но чето страшновато как-то :)
     
     
  • 3.47, Аноним (36), 11:17, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Впечатление - надо мозги перестраивать с императивного стиля в этот.

    Как промежуточный вариант - можно для тренировки взять Ocaml. Там можно начать с империативного стиля и постепенно переходить в функциональный.

     

  • 1.45, Аноним (46), 11:01, 14/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да потому что rewrite - это маразм! Костыли на пустом месте.
     
     
  • 2.62, Аноним (62), 14:52, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    а че делать если надо сохранить старый формат ссылок при переезде на новый? Это же не SЕО-трушно, старые ссылки ведь должны хотя бы редирект оформить.
     

  • 1.48, bublick (ok), 11:44, 14/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "для выполнения кода с правами рабочего процесса nginx через отправку HTTP-запроса со специально оформленным URI"

    Там же по умолчанию пользователь ww-data. Это все равно что анонимус.

     
     
  • 2.58, Аноним (58), 13:40, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Fragnesia, Copy Fail и Dirty Frag вам в помощь.
     
  • 2.60, нах. (?), 14:30, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    видишь ли, не все используют nginx на локалхосте в качестве украшения, у некоторых он работает на веб-сервере.

    А вот на нем - нет практически НИЧЕГО такого, что имело бы хоть малейшую ценность и при этом не было бы доступно "пользователю ww-data".
    Потому что таки вебсервер.

    Особенно настроенный васянами вроде тебя, у кого и приложение от того же пользователя работает.

     
     
  • 3.64, Твайлайт Спаркл 2 (?), 16:03, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    selinux по идее ещё больше ограничивает возможности бинарника nginx. Например, запрет веб-серверу читать файлы с сетевых дисков или слушать левые порты.
     
     
  • 4.65, нах. (?), 16:14, 14/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > selinux по идее ещё больше ограничивает возможности бинарника nginx. Например, запрет веб-серверу
    > читать файлы с сетевых дисков или слушать левые порты.

    Уровень этогосайта.

     

  • 1.73, Аноним (73), 18:22, 14/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Быстрый фикс:

    Иван Иваныч, перепиши конфиг nginx для закрытия уязвимости CVE-2026-42945

    Пример уязвимой конструкции:

       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;

    Конфиг:

    ...

     

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



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

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