14 октября 2026 года NGINX выпустил исправления пяти уязвимостей. Для исходных веток NGINX Open Source они вошли в 1.30.6 stable и 1.31.7 mainline. Три ошибки работы с памятью при дополнительных условиях могут привести к удалённому выполнению кода. Владельцу сайта нужно проверить установленную сборку, действующую конфигурацию и применение исправления к работающему серверу.
Дата проверки материала — 24 октября 2026 года. К этому моменту уже вышла mainline 1.31.8, поэтому 1.31.7 ниже указана как первая исправленная версия этой ветки. При обновлении выбирайте актуальный поддерживаемый выпуск своего поставщика. Даты и состав исправлений опубликованы в новостях NGINX.
Что исправили и какие настройки имеют значение
В сообщениях об обновлении рядом оказались HTTP/3, TLS и несколько ошибок памяти. Это отдельные сценарии с разными предпосылками. Проверка одного модуля не отвечает на вопросы по остальным.
| Уязвимость | Условия, которые нужно проверить | Возможные последствия |
|---|---|---|
| CVE-2026-15176 | Сочетание alias, rewrite и определённых обращений к $request_filename, в том числе в формате access log. | Переполнение памяти в worker-процессе, его аварийное завершение; при дополнительных условиях — выполнение кода. |
| CVE-2026-93479 | Захваты regex из map, используемые в root или формате access log раньше выходной переменной map; также описаны строковые выражения с некэшируемой переменной. | Переполнение памяти, завершение worker-процесса; при дополнительных условиях — выполнение кода. |
| CVE-2026-95101 | Обработка HTTP/3; для сценария с проксированием F5 указывает proxy_request_buffering on. | Часть неизвестного frame может попасть в тело запроса; возможны обход ограничения размера тела и внедрение данных в проксируемый запрос. |
| CVE-2026-97629 | Автоматическая ротация ключей TLS session tickets при общей session cache, без явного файла ssl_session_ticket_key. | Возможна недетерминированная подделка клиентской TLS-сессии, в том числе обход проверки клиентского сертификата. |
| CVE-2026-97205 | AIO вместе с обработкой SSI-страниц с include virtual при определённой конфигурации. | Использование уже освобождённой памяти, повреждение памяти процесса или его падение; при дополнительных условиях — выполнение кода. |
Worker — процесс NGINX, который обслуживает соединения. Его падение способно нарушить обработку запросов, даже если основной процесс сервера продолжает работать. Удалённое выполнение кода, или RCE, означает возможность запустить код через уязвимый путь обработки данных. AIO — асинхронный ввод-вывод, SSI — обработка серверных вставок в страницах.
Таблица помогает выбрать направление проверки. Полные условия и исключения нужно сверять с бюллетенем конкретной CVE: например, наличие одного alias ещё не подтверждает сценарий CVE-2026-15176. Диапазоны затронутых upstream-версий различаются и перечислены в реестре уязвимостей NGINX.
Почему оценки серьёзности отличаются и когда возможен RCE
У трёх ошибок памяти — CVE-2026-15176, CVE-2026-93479 и CVE-2026-97205 — в записях F5 указаны 9.2 Critical по CVSS 4.0 и 8.1 High по CVSS 3.1. На сайте NGINX для этой группы используется обозначение medium. При пересказе важно сохранять название системы оценки: разные шкалы нельзя смешивать в одну общую метку «все пять критические».
F5 связывает возможность выполнения кода для этих трёх ошибок с отключённым ASLR либо возможностью его обойти. ASLR рандомизирует размещение областей памяти и затрудняет эксплуатацию определённых ошибок. Его включение полезно, но не устраняет саму уязвимость и не заменяет исправление. Эти условия приведены в первичных записях F5 для 15176, 93479 и 97205.
Из наличия NGINX на сервере нельзя сделать вывод о состоявшемся взломе. Вместе с тем отсутствие очевидных сбоев не подтверждает безопасность. Для решения об обновлении нужны данные о сборке и конфигурации; признаки возможной компрометации проверяются отдельным расследованием.
Как проверить свой сервер
Начните с инвентаризации всех мест, где работает NGINX. Он может находиться перед приложением на хосте, внутри контейнера или в отдельном контроллере Kubernetes. Для NGINX Plus, Ingress Controller и Gateway Fabric применяются версии и матрицы соответствующего продукта: номер Open Source нельзя автоматически переносить на них.
Для обычной установки полезны следующие команды:
nginx -v
nginx -V
sudo nginx -t
-v показывает версию вызываемого бинарника, -V — также параметры его сборки, -t проверяет конфигурацию и доступность указанных в ней файлов. Набор параметров описан в документации NGINX. Выполняйте команды в том окружении и с тем путём к конфигурации, которые использует проверяемый экземпляр: бинарник из PATH на хосте может отличаться от бинарника в контейнере.
Полную конфигурацию можно локально посмотреть через nginx -T, включая подключённые файлы. Её вывод может содержать закрытые адреса, служебные заголовки и секреты, поэтому передавать его в открытый чат или публиковать целиком не следует. Наличие параметра сборки в -V показывает возможность использования модуля; фактический режим определяют директивы конфигурации.
Для пакета Ubuntu или Debian дополнительно посмотрите полный номер сборки:
dpkg-query -W -f='${Package} ${Version}\n' 'nginx*'
apt-cache policy nginx
У дистрибутивов исправления могут переноситься в поддерживаемую ветку без смены основной версии NGINX. Поэтому короткой строки nginx/1.x недостаточно: нужен статус конкретной CVE для конкретного пакета и выпуска ОС. Такой подход к security-обновлениям описан, например, в документации Ubuntu.
По итогам проверки должны быть известны поставщик и сборка, затронутые функции, доступность сценария извне и исправленный пакет. Если доступ к серверу находится у хостинга, запросите у поддержки эти сведения вместе с подтверждением применения патча.
Как подготовить и применить обновление
Согласуйте окно работ с учётом всех сайтов на общем reverse proxy. Сохраните конфигурацию, сертификаты и настройки запуска в защищённом хранилище, зафиксируйте текущий пакет или образ и порядок восстановления. Проверка восстановления резервной копии подробно разобрана в отдельном материале DDRW.
На стенде проверьте совместимость выбранного выпуска с динамическими модулями, подключаемыми файлами и способом запуска. Пройдите через тот же TLS-вход и маршруты, которыми пользуются посетители: локальный ответ приложения за прокси не проверяет конфигурацию самого NGINX.
Обновляйте пакет из доверенного репозитория либо собирайте новый образ с зафиксированной версией. Для NGINX Plus и управляемых продуктов используйте процедуру поставщика. Если образ лежит в реестре, это ещё не означает, что работающие контейнеры уже используют его.
Почему одного reload недостаточно
Обычный nginx -s reload поручает существующему master-процессу перечитать конфигурацию и создать новые worker-процессы. Для замены исполняемого файла NGINX документирует отдельную процедуру обновления бинарника. Поэтому после установки нового пакета нужно применить предусмотренный поставщиком перезапуск либо документированный binary upgrade, а затем проверить фактическую смену процессов. Различие объясняется в руководстве по управлению NGINX.
Успешный nginx -t отвечает на вопрос о конфигурации. Он не подтверждает, что уже работающий master загрузил исправленный бинарник. Аналогично, новый результат nginx -v относится к вызываемому файлу, а состояние запущенного экземпляра требует отдельной проверки.
Для установки под systemd отправной точкой может быть:
systemctl show nginx --property=MainPID,ExecStart --no-pager
systemctl status nginx --no-pager
Сопоставьте процессы с записью об обновлении и установленной сборкой. В контейнерной среде проверьте идентификаторы работающих образов и состояние всех реплик. Конкретные команды зависят от принятого способа развёртывания.
Что проверить после обновления
Зафиксируйте результат по нескольким независимым признакам:
- Исправление: поставщик указывает нужные CVE как закрытые именно в установленной сборке.
- Работающий экземпляр: новые процессы или реплики используют обновлённый бинарник либо образ.
- Публичный вход: основные домены, HTTPS, сертификаты, редиректы и маршруты доступны снаружи.
- Функции: проходят нужные вашему сайту сценарии — формы, вход, загрузка файлов, API и длительные соединения.
- Ошибки: проверены журналы запуска, падения worker-процессов и изменения частоты ответов 5xx.
Если используются HTTP/3, клиентские TLS-сертификаты или SSI, включите их в план отдельно. Обычная открытая главная страница не проверяет эти режимы. Для действий, создающих заказ или отправляющих письмо, заранее используйте согласованный тестовый сценарий.
В отчёте об обновлении полезно сохранить дату, полный номер пакета или digest образа, применённую процедуру и результаты проверок. Этот набор позволит следующему специалисту понять состояние системы без повторного сбора всей истории.
Если установить патч сразу не получается
F5 описывает временные меры для отдельных сценариев: изменение использования alias и $request_filename, определённых захватов регулярных выражений, отключение AIO или SSI, а также настройки session tickets и буферизации проксируемых запросов. Выбирайте меру по бюллетеню конкретной CVE и проверяйте последствия на стенде.
Например, изменение alias способно нарушить выдачу файлов, а отключение SSI — отображение страниц с серверными вставками. Переключение proxy_request_buffering меняет обработку тела запроса и взаимодействие с upstream. Для TLS tickets важно сохранить управляемую политику ключей. Универсальный набор директив для копирования здесь был бы ненадёжным решением.
Временную меру зафиксируйте вместе с ответственной командой и сроком установки исправления. WAF и CDN могут участвовать в защите, но сами по себе не подтверждают устранение ошибки в NGINX на origin-сервере.
Частые вопросы владельцев сайтов
Если NGINX стоит перед приложением на Rust, его тоже нужно обновлять?
Да, состояние reverse proxy оценивается отдельно от языка приложения. Ошибка обработки запроса в NGINX возникает до передачи управления приложению или во время проксирования. Безопасность одного компонента не подтверждает безопасность соседнего.
Нужно ли срочно переходить со stable на mainline?
Исправления этой группы есть в обеих ветках: начиная с 1.30.6 stable и 1.31.7 mainline. Выбор должен учитывать поддержку поставщика, совместимость модулей и подтверждение патча в вашей сборке. Переход между ветками не является обязательным условием устранения этих пяти CVE.
Если сайт работает через HTTPS, почему проблема с TLS tickets всё ещё имеет значение?
HTTPS сам по себе не исключает ошибки реализации TLS. CVE-2026-97629 описывает определённый режим session tickets и возможность подделки клиентской сессии; из этого не следует вывод о взломе всех HTTPS-соединений. Условия приведены в записи F5 для этой CVE.
Нужен ли полный редизайн или перенос сайта?
Сначала нужно определить затронутую установку и применить исправление. Обновление reverse proxy обычно является задачей сопровождения инфраструктуры. Менять CMS или внешний вид сайта ради этой группы CVE само по себе не требуется.
Проверка и сопровождение сайта в DDRW
Если у команды нет понятной информации о сервере и порядке обновлений, начните с инвентаризации: где размещены приложение и reverse proxy, кто управляет доступами, какие копии доступны и как проверяется результат работ. Для подготовки к передаче проекта пригодится наш чек-лист выбора разработчика и проверки комплектности работ.
В DDRW можно обсудить поддержку и развитие сайта: определить границы проверки, план обновления и критерии приёмки. Для нового проекта инфраструктуру и порядок сопровождения стоит согласовать ещё на этапе разработки сайта для бизнеса.
Первичные источники
- NGINX: выпуски от 14 и 21 октября 2026 года.
- NGINX: перечень CVE и диапазоны затронутых upstream-версий.
- F5 CNA: CVE-2026-15176, CVE-2026-93479, CVE-2026-95101, CVE-2026-97629, CVE-2026-97205.
- NGINX: параметры командной строки и управление процессами и обновление бинарника.
- Ubuntu: доставка security-обновлений и перенос исправлений в поддерживаемые пакеты.
