--- title: "Уязвимости NGINX: причины, исправления и производственная проверка" description: "Ознакомьтесь с пятью уязвимостями NGINX, обнаруженными в октябре 2026 г., предварительными условиями их конфигурации, исправлениями для конкретных отраслей, резервными портами распространения и производственной проверкой." language: "ru" url: "https://keendigit.com/ru/insights/nginx-remediation-guide" author: "KeenDigit" published: "2026-10-14" updated: "2026-10-27" --- # Уязвимости NGINX: причины, исправления и производственная проверка Ознакомьтесь с пятью уязвимостями NGINX, обнаруженными в октябре 2026 г., предварительными условиями их конфигурации, исправлениями для конкретных отраслей, резервными портами распространения и производственной проверкой. Дата исторической статьи: 2026-10-14 (дата раскрытия информации и безопасности). Источники проверены и информация дополнена через 2026-10-27. Эта статья заархивирована по дате события; Ниже приведены версии и обновления выпусков, выпущенные после 14 октября. Аудитория: NGINX Open Source / NGINX Plus, персонал по эксплуатации и обслуживанию обратного прокси-сервера, персонал службы безопасности, специалисты по сопровождению распространения, а также инженеры, которые самостоятельно компилируют NGINX и поддерживают сторонние модули. В этой статье основное внимание уделяется пяти основным уязвимостям NGINX, которые были обнаружены и тщательно исправлены 14 октября 2026 года, а также рассмотрены типичные уязвимости безопасности памяти и целостности запросов с мая по сентябрь 2026 года. Содержимое охватывает условия срабатывания, причины на уровне кода, масштаб воздействия, рабочий процесс исправления, краткосрочные меры по смягчению последствий, официальную реализацию исправлений, бэкпорты в старые ветки и проверку производства. Такие ссылки, как [S1](https://keendigit.com/ru/insights/nginx-remediation-guide#source-1), указывают на исходное приложение. Примеры конфигураций используются только для иллюстрации идей развертывания и аудита и перед внедрением должны быть проверены на основе фактической версии, наследования конфигурации, зависимостей и возможностей бизнеса. ## TL;DR: Приоритетные действия 1. Отдавайте приоритет обновлениям безопасности. Для пакетов с открытым исходным кодом nginx.org обновите ветку Stable 1.30 как минимум до 1.30.6 и ветку Mainline 1.31 как минимум до 1.31.7.. На дату проверки 1.31.8 является последней версией. Выпуск Mainline. Это отдельные базовые показатели ветвей; не сравнивайте их количество в разных отраслях. [S1](https://keendigit.com/ru/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/ru/insights/nginx-remediation-guide#source-2) 2. Проверьте установку дистрибутива по полной версии пакета. Ubuntu 22.04 / 24.04 / 26.04 / 26.10 имеют бэкпорты поставщиков; Debian 13 (trixie) требует как минимум `1.26.3-3+deb13u10`. При проверке пакет Debian 12 (bookworm) `1.22.1-9+deb12u10` по-прежнему помечен как затронутый. Проверьте каждое CVE; рекомендация Debian 13 не устанавливает, что Debian 12 исправлен. [S13](https://keendigit.com/ru/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/ru/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/ru/insights/nginx-remediation-guide#source-15) 3. Аудит пяти комбинаций конфигурации: `alias + rewrite + $request_filename`, `map` + регулярное выражение + оценка переменной, `aio + ssi + include virtual`, HTTP/3 с `proxy_request_buffering on` и `ssl_session_cache shared:...` с автоматической ротацией ключа билета сеанса TLS. Наличие директивы само по себе не означает возможность использования; оценить путь запроса и область конфигурации. [S1](https://keendigit.com/ru/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/ru/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/ru/insights/nginx-remediation-guide#source-4) 4. Замените все старые процессы и контейнеры. Запустите `nginx -t`, затем перезапустите службу или выполните последовательное развертывание высокой доступности. Убедитесь, что старые процессы master/worker завершились; `nginx -s reload` сам по себе не доказывает, что работающий двоичный файл изменился. 5. Проверьте фактические конечные точки: HTTP/1.1, HTTP/2, HTTP/3, если они включены, загрузку через прокси и тела запросов API, аутентификацию сертификата mTLS, страницы SSI и журналы доступа. Запишите происхождение пакета, версию, дайджест образа, запущенные процессы и результаты для каждой конечной точки. 6. Если немедленное обновление невозможно, удалите применимые триггерные условия: отключите ненужные SSI/AIO или HTTP/3, проверьте уязвимые ссылки на переменные `alias`/`rewrite`/`map` и оцените временные ссылки на переменные `ssl_session_tickets off;` на предмет затронутых проблем. mTLS услуги. WAF, ASLR, ограничения скорости и изменения конфигурации охватывают только некоторые условия и не могут заменить официальные исправления. [S3](https://keendigit.com/ru/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/ru/insights/nginx-remediation-guide#source-4)[S8](https://keendigit.com/ru/insights/nginx-remediation-guide#source-8)[S12](https://keendigit.com/ru/insights/nginx-remediation-guide#source-12) ## 1. Обзор уязвимостей и оценка рисков NGINX выпустил 1.30.6 (Stable) и 1.31.7 (Mainline) 14 октября 2026 г., исправив пять проблем безопасности. Три связаны с переполнением кучи или использованием после освобождения и получили оценку F5 CVSS v4.0 9.2 / Critical. Два других влияют на целостность запроса HTTP/3 и аутентификацию сертификата клиента TLS. [S1](https://keendigit.com/ru/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/ru/insights/nginx-remediation-guide#source-2)[S3](https://keendigit.com/ru/insights/nginx-remediation-guide#source-3) Различайте системы оценок: nginx.org перечисляет все пять проблем как `medium`, а F5 CVSS v4.0 и некоторые агентства национальной безопасности классифицируют три проблемы с памятью как критические. Это не означает, что все пять допускают безусловное удаленное выполнение кода. Конфигурация, доступность трафика и условия, находящиеся вне контроля злоумышленника, имеют значение. Повреждение памяти и надежный RCE — это разные уровни доказательств. [S1](https://keendigit.com/ru/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/ru/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/ru/insights/nginx-remediation-guide#source-4) | CVE | Технические проблемы и типичные условия срабатывания | основное воздействие | Оценка и утилизация | | -------------- | --------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | CVE-2026-15176 | `alias` Сопоставление пути + изменение `rewrite` URI + оценка `$request_filename` | Переполнение буфера кучи, сбой Worker; потенциальный RCE при определенных условиях | F5 CVSS v4.0 9.2; расставить приоритеты в устранении неполадок | | CVE-2026-93479 | Оценка сценария HTTP/Stream, особенно захват регулярных выражений `map` и каталог root, перекрестная ссылка на переменную журнала | Зарезервированный буфер перезаписывается, и куча переполняется; потенциальный RCE при определенных условиях | F5 CVSS v4.0 9.2; риск регресса после предыдущего ремонта | | CVE-2026-97205 | SSI виртуальный включает и AIO/асинхронную работу; переполнение счетчика выдающихся операций | Use-After-Free, сбой Worker, повреждение памяти; потенциальный RCE | F5 CVSS v4.0 9.2; требуется конфигурация не по умолчанию | | CVE-2026-95101 | HTTP/3 Неизвестный кадр фрагментирован по буферам, буферизация тела запроса прокси включена | Неправильное внедрение байтов, отличных от DATA, в тело запроса восходящего потока, возможно, в обход ограничения размера тела запроса. | Эта уязвимость влияет на целостность запроса. Он сам по себе не обеспечивает удаленное выполнение кода (RCE). | | CVE-2026-97629 | Общий кэш сеансов TLS, автоматическая ротация ключей и зеркальное отображение ключей Worker. | Подделка билетов на сеанс; Для затронутой службы mTLS может произойти обход аутентификации сертификата клиента. | Особое внимание необходимо уделить бизнес-влиянию типа аутентификации сертификата API. | Приведенная выше оценка CVSS дается F5 с использованием v4.0; одна и та же уязвимость может иметь различную серьезность в собственных классах CVSS 3.1, nginx.org и рейтингах серьезности распространения. [S1](https://keendigit.com/ru/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/ru/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/ru/insights/nginx-remediation-guide#source-4) ### 1.1 Уделяйте приоритетное внимание воздействию развертывания, а не только оценкам CVE. | Форма развертывания | Ключевые моменты расследования | Рекомендации по приоритету утилизации | | -------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | Обратный прокси-сервер общедоступной сети, включая настроенные `rewrite`, `alias` и сложный `map`. | CVE-2026-15176, CVE-2026-93479 и перезапись/картирование уязвимостей с мая по июль. | P0: Немедленная проверка и обновление. | | API / Плоскость управления с использованием сертификата клиента в качестве единственного или основного входа для аутентификации. | Билет сеанса и конфигурация общего кэша CVE-2026-97629 | P0: Немедленно подтвердите границу аутентификации и обновите | | Обеспечивает внешнюю загрузку HTTP/3, интерфейс изменения статуса, класс транзакции API. | CVE-2026-95101, особенно тело запроса пересылается на серверную часть | P0/P1: расположите по важности бизнеса. | | SSI Динамический страничный или асинхронный файловый ввод-вывод | CVE-2026-97205 | P1: Подтвердите условия комбинации и отремонтируйте как можно скорее. | | Только статические страницы + простой обратный прокси HTTP/1.1/2. | Конфигурацию и версию по-прежнему необходимо проверять, но некоторые условия CVE могут отсутствовать. | P1: Включено в окно аварийного обновления безопасности. | | Использовать устаревшее сообщество Kubernetes ingress-nginx | Проект прекращает обслуживание безопасности, и риски не ограничиваются этими пятью CVE. | Составьте индивидуальный план миграции контроллера | P0/P1 — это рекомендации по эксплуатации и техническому обслуживанию, приведенные в этой статье для уязвимости общедоступной сети и чувствительности сертификации. Это не официальная классификация CVSS, и она не должна заменять внутренние активы предприятия и оценку рисков изменения. ### 1.2 Влияние границ и разрешения на атаку Основные уязвимости в этом пакете в основном расположены в плоскости данных NGINX: точкой входа для атаки является клиентское соединение и запрос, а фактическое воздействие обычно происходит в процессе Worker. Если условия повреждения памяти соблюдены, разрешение на выполнение кода обычно ограничивается работающим пользователем, ограничениями контейнера, возможностями Linux, разрешениями на монтирование и сетевыми разрешениями Worker; потенциальный RCE не подразумевает автоматически привилегии root или компрометацию хоста. [S4](https://keendigit.com/ru/insights/nginx-remediation-guide#source-4) Но даже если процесс непривилегирован, он все равно может иметь доступ к учетным данным прокси, читаемым файлам, содержащим закрытые ключи сертификата, токенам восходящих служб, временным файлам, внутреннему API и доступным сетям. Для mTLS обход аутентификации сам по себе может стать серьезным бизнес-последствием и не обязательно должен сопровождаться выполнением кода. ## 2. Анализ причин ### 2.1 Понимание трех границ ошибок в NGINX. NGINX worker — это долгоживущий, управляемый событиями процесс, который поддерживает статус запроса, асинхронные операции и анализаторы протоколов. Эта уязвимость включает в себя ограничения на трех инженерных уровнях: 1. оценка переменной и размер памяти должны быть согласованы: `rewrite` После изменения запроса URI сопоставление путей должно соответствовать текущему действующему `location`; когда интерпретатор сценария вычисляет длину переменной, пространство записи должно охватывать фактические выходные и зарезервированные области. 2. Асинхронные операции должны продлевать жизненный цикл запрошенной памяти: при наличии незавершенных операций чтения и записи файлов, ожидания кэша или задач потоков соответствующий пул памяти запроса не может быть освобожден заранее. 3. статус протокола и статус безопасности нельзя смешивать или опускать: HTTP/3 Длина неизвестного пропуска кадров не может рассматриваться как длина тела запроса DATA; TLS Все ключевые слоты, участвующие в проверке подписи, должны быть правильно инициализированы и синхронизированы во время ротации билетов сеанса. Следующее содержимое основано на фиксации исходного исправления NGINX и объявлении поставщика, чтобы объяснить механизм сбоя, который может быть запущен; фрагмент примера предназначен для анализа, а не является полным кодом, который можно напрямую использовать для восстановления производственной среды. [S5](https://keendigit.com/ru/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/ru/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/ru/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/ru/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/ru/insights/nginx-remediation-guide#source-9) ### 2.2 CVE-2026-15176: Сопоставление путей между `alias` и перезаписанным URI неверно. В NGINX совпадающие `location` и его `alias` определяют путь к файлу; `rewrite` может изменить текущий запрос URI. После переписывания предположения, использованные в исходном сопоставлении `location`, могут больше не выполняться. Затронутый путь обработки не смог должным образом проверить, был ли запрос перезаписан при проверке статуса `alias` в `ngx_http_map_uri_to_path()`. Когда конфигурация продолжает оценивать `$request_filename` после перезаписи, путь может быть построен с предположениями, которые не соответствуют текущему состоянию URI, что в конечном итоге приведет к записи за пределами допустимого диапазона в динамической памяти. [S5](https://keendigit.com/ru/insights/nginx-remediation-guide#source-5) Типичная комбинация (используется только как контрпример для аудита конфигурации, развертывание не рекомендуется): ```nginx # 仅用于识别风险模式：不是修复配置 location /foo/ { alias /srv/alias-root/; rewrite ^/foo/.*$ /new-path; return 200 $request_filename; } ``` Опасность не ограничивается `return`: `set`, `if`, `add_header`, `log_format` и т. д. также необходимо проверять, если в том же процессе запроса запускается оценка `$request_filename`. `return` в примере только позволяет легко увидеть этот путь состояния, но его нельзя использовать для вывода о том, что все производственные конфигурации будут вызывать переполнение. [S5](https://keendigit.com/ru/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/ru/insights/nginx-remediation-guide#source-10) Последствия атаки: Построение запроса может привести к перезапуску Worker или прерыванию обслуживания; в таких условиях, как ASLR закрыт или его можно обойти, существует потенциальный RCE. Суть восходящего патча заключается в отказе от завершения переписанного сопоставления путей URI в контексте `alias`, который больше не является действительным, а не в простом расширении определенного буфера. [S5](https://keendigit.com/ru/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/ru/insights/nginx-remediation-guide#source-10) ### 2.3 CVE-2026-93479: несоответствие между «зарезервированным пространством» и реальной длиной переменной при оценке скрипта. Модули HTTP и Stream NGINX имеют оценщики сценариев, которые объединяют литеральные строки и значения переменных в результирующую строку. Примеры приложений включают пути HTTP-документа root, пути журнала доступа и выражения переменных в Stream. Определенные конфигурации регулярных выражений `map` + позволяют считывать полученные значения другими выражениями до того, как будет оценена результирующая переменная `map`. В сочетании с методом выполнения сценария с зарезервированной длиной старая реализация заранее будет учитывать зарезервированное пространство `len` в аккумуляторе оцененной длины, так что последующие вычисления указателя записи больше не будут соответствовать границе буфера. В определенной последовательности оценки переменной последующие записи строк могут перезаписать зарезервированную область, что приведет к переполнению кучи. [S6](https://keendigit.com/ru/insights/nginx-remediation-guide#source-6) | элементы участия | Почему на это стоит обратить внимание | | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | регулярное выражение в `map` | Оценка переменной захвата может иметь независимый жизненный цикл и поведение кэширования. | | Анонимные захваты, такие как `$1`, `$2` и т. д. | Легко перезаписывается другими регулярными выражениями или выражениями, что затрудняет отслеживание владельца. | | Переменные в `root` | Выполнение скрипта и резервирование буфера при запуске построения пути | | `log_format`/Путь к динамическому журналу | Тот же тип оценки может быть запущен позже в запросе. | | Выражения сценария в `stream` | Исправление исходной версии также изменяет `ngx_stream_script_run()`. Вы не можете только просмотреть модуль HTTP. | Важная регрессионная связь: код, связанный с этой уязвимостью, связан с предыдущими изменениями, исправившими CVE-2026-42533. В официальном DSA для Debian 13 четко указано, что затронутый код был добавлен в пакет trixie через более раннюю версию безопасности. Таким образом, сообщение «Июльский патч уязвимости `map` установлен» не означает, что октябрьский патч CVE-2026-93479 покрыт; должна быть проверена полная цепочка исправлений безопасности. [S6](https://keendigit.com/ru/insights/nginx-remediation-guide#source-6)[S14](https://keendigit.com/ru/insights/nginx-remediation-guide#source-14)[S17](https://keendigit.com/ru/insights/nginx-remediation-guide#source-17) Потенциальный риск RCE здесь связан со средой защиты памяти, и не следует утверждать, что анонимные злоумышленники смогут использовать только регулярное выражение `map`. [S11](https://keendigit.com/ru/insights/nginx-remediation-guide#source-11) ### 2.4 CVE-2026-97205: AIO Зацикливание счетчика незавершенных операций приводит к Use-After-Free Эта уязвимость не просто «включите SSI и вы получите UAF». Ключ заключается в счетчике ссылок на асинхронную операцию, хранящемся в основном запросе. NGINX Используйте `r->main->blocked` для отслеживания еще не завершенной асинхронной обработки, в старой реализации это был 8-битный счетчик; некоторые пути не проверяли верхний предел перед увеличением счетчика. Когда один и тот же основной запрос накапливает 256 невыполненных операций, счетчик может перейти с 255 на 0. Последующие процессы будут ошибочно полагать, что не существует асинхронной операции, препятствующей освобождению запроса, тем самым освобождая пул памяти запроса, на который все еще ссылается задача. [S7](https://keendigit.com/ru/insights/nginx-remediation-guide#source-7) Процесс отказа можно разделить на: 1. При включенном пути асинхронного ввода-вывода/потока страница SSI представляет несколько подзапросов или операций чтения через `include virtual`. 2. Невыполненные операции определенного основного запроса накапливаются до верхнего предела, представленного полем счетчика. 3. 8-битный счетчик зацикливается, что неправильно выражается как «нет ожидающих операций». 4. Пул памяти запросов освобождается, в то время как операции чтения файлов, ожидания кэша или обратные вызовы задач потока по-прежнему сохраняют ссылки на него. 5. Последующие обратные вызовы асинхронного завершения обращаются к освобожденной памяти, что приводит к сбоям UAF, Worker или потенциальному повреждению памяти. Официальное исправление добавляет `NGX_HTTP_MAX_BLOCKED 250` в файл заголовка запроса и добавляет ограничения на выходной фильтр, чтение кэша и путь восходящего потока; при достижении порога операции с синхронизированными путями выполняются синхронно, и если их невозможно безопасно обработать, в дальнейшем добавлении ожидающих задач будет отказано. [S7](https://keendigit.com/ru/insights/nginx-remediation-guide#source-7) Решение о применимости: необходимо оценить, могут ли SSI, AIO, виртуальное включение, подзапросы и связанные асинхронные операции встречаться в комбинации в одной и той же цепочке запросов. Обычно это не простые статические конфигурации прокси по умолчанию. `aio off;` или `ssi off;` могут удалять определенные элементы триггера, но сначала следует подтвердить зависимости бизнес-функций. [S4](https://keendigit.com/ru/insights/nginx-remediation-guide#source-4)[S7](https://keendigit.com/ru/insights/nginx-remediation-guide#source-7)[S25](https://keendigit.com/ru/insights/nginx-remediation-guide#source-25) ### 2.5 CVE-2026-95101: неизвестный кадр HTTP/3 перепутан со статусом тела запроса DATA. Анализатор кадров HTTP/3 должен различать кадры `DATA` (которые необходимо передать в обработку тела HTTP-запроса) и неизвестные кадры, которые следует пропускать. Длина неизвестных кадров также должна точно сохраняться при фрагментации по сетевым буферам. Старая реализация `ngx_http_v3_parse_data()` использовала поле `st->length` для сохранения «оставшегося числа пропущенных байтов» при пропуске неизвестных кадров, в то время как фильтр тела запроса интерпретировал это же поле как «оставшуюся длину полезной нагрузки DATA». Если неизвестный кадр охватывает несколько вызовов синтаксического анализа, следующий пакет байтов после прерывания синтаксического анализа может быть ошибочно принят за часть тела запроса. [S8](https://keendigit.com/ru/insights/nginx-remediation-guide#source-8) Возникают два типа рисков: - Внедрение тела запроса: полезная нагрузка кадра, отличная от DATA, отправленная клиентом, может быть передана вышестоящему приложению, изменяя данные, фактически полученные серверной частью. - ограничение размера обходит: `client_max_body_size` и другие ограничения. Ожидаемые проверки сосредоточены на пути DATA, и неправильно преобразованный контент может обойти соответствующую проверку. Типичный сценарий срабатывания, описанный официальным лицом, — это когда `ngx_http_v3_module` получает запрос HTTP/3 и пересылает `proxy_request_buffering on`. Буферизация тела прокси-запроса включена по умолчанию в `ngx_http_proxy_module`. Поэтому в первую очередь следует проверить обратный прокси, включающий HTTP/3. Неверно предполагать, что условие триггера отсутствует только потому, что `proxy_request_buffering on;` не записан явно. [S8](https://keendigit.com/ru/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/ru/insights/nginx-remediation-guide#source-18) Прямым следствием этой уязвимости является изменение целостности внутренних запросов и границ безопасности, которое не является эквивалентным выражением RCE, непосредственно завершенным в ядре NGINX. Конечный результат для бизнеса зависит от того, как эти байты анализируются и как им доверяют в восходящем направлении. [S24](https://keendigit.com/ru/insights/nginx-remediation-guide#source-24) ### 2.6 CVE-2026-97629: TLS При ротации билета не попадает в третий ключевой слот. В затронутых конфигурациях NGINX может автоматически генерировать и чередовать ключи билетов сеанса TLS через кэш общей памяти, позволяя нескольким Worker обрабатывать один и тот же пакет билетов. Соответствующая логика синхронизации выделяет 3 ключевых слота для каждого Worker, и обратный вызов дешифрования также будет проходить через эти слоты; но старая реализация каждый раз копирует только 2 слота ключей из общей памяти, в результате чего получается имя ключа, ключ HMAC и AES третьего слота. Ключ может остаться неинициализированным. Если идентификатор ключа билета соответствует этому статусу, неинициализированный ключевой материал может использоваться для проверки и дешифрования подписи, образуя таким образом путь для подделки сеанса TLS. [S9](https://keendigit.com/ru/insights/nginx-remediation-guide#source-9) Обычно используются следующие комбинации развертывания с высоким риском: ```nginx # 仅为排查触发条件所示：共享缓存本身不是恶意配置 ssl_session_cache shared:SSL:10m; # 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制 ``` Самым серьезным бизнес-последствием этой уязвимости является то, что в службах, использующих проверку подлинности сертификата клиента (mTLS) в `ssl_verify_client on;` и других способах, поддельные сеансы восстановления могут обходить проверку сертификата клиента. Успех атаки также зависит от неконтролируемых условий; сайт, который использует только обычный сертификат HTTPS на стороне сервера и не использует аутентификацию сертификата клиента, не должен ошибочно характеризоваться как «злоумышленник может обойти весь вход на сайт». [S9](https://keendigit.com/ru/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/ru/insights/nginx-remediation-guide#source-12) Это проблема статуса аутентификации сеанса TLS, и она не имеет ничего общего с тем, взломан ли закрытый ключ сервера TLS или затронут ли общедоступный сертификат CA root. [S24](https://keendigit.com/ru/insights/nginx-remediation-guide#source-24) ### 2.7 Как понять DoS, RCE, обход аутентификации и известные эксплойты - DoS: ошибка памяти приводит к сбою или массовой перезагрузке Worker. Вызывает ли это общую недоступность, зависит от нагрузки на трафик, возможности перезапуска процесса, времени обслуживания соединения и архитектуры высокой доступности. - потенциальный RCE: в некоторых объявлениях указывается, что существует возможность выполнения кода при закрытии или обходе ASLR. Это не означает, что раскрыта публичная цепочка атак, которая может стабильно и универсально выполнять команды. [S4](https://keendigit.com/ru/insights/nginx-remediation-guide#source-4) - Обход запроса/аутентификации: он может напрямую изменить защищенный бизнес-статус или содержимое запроса, и его нельзя игнорировать только потому, что он не получает оболочку напрямую. - обнаружил попытки атак: CVE-2026-42945 в мае 2026 года получил сообщения о деятельности по эксплуатации в дикой природе; не следует напрямую делать вывод из этого исторического факта, что все пять CVE в октябре были успешно использованы в больших масштабах. [S23](https://keendigit.com/ru/insights/nginx-remediation-guide#source-23) ## 3. Ремонт версии и выбор патча ### 3.1 NGINX Open Source базовая версия официального патча | восходящая ветвь | Первая официальная версия, охватывающая пять уязвимостей, в октябре. | Рекомендации от 2026-10-27 | | ------------------------------------ | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Stable 1.30.x | 1.30.6（2026-10-14） | Установите как минимум 1.30.6 и установите последующие версии безопасности. | | Mainline 1.31.x | 1.31.7（2026-10-14） | 1.31.8（2026-10-21） | | Более ранняя ветка NGINX Open Source | Нельзя судить только по тому, что «применены старые исправления уязвимостей». | Сначала перейдите в поддерживаемую ветку; в противном случае поставщик обязан предоставить официальное подтверждение поддержки на основе CVE-by-CVE. | Это выводы о версии исходного кода/официальной ветки исходной версии nginx.org, и их не следует использовать для прямого отказа в пакете безопасности с перенесенными исправлениями, предоставленными поставщиком дистрибутива. Даже если значение `1.31.6` больше, чем `1.30.6`, оно все равно ниже базового значения исправления основной ветки. [S1](https://keendigit.com/ru/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/ru/insights/nginx-remediation-guide#source-2) ### 3.2 Объем воздействия пяти CVE на восходящий канал Следующие диапазоны перечислены в соответствии с исходным текстом бюллетеня по безопасности nginx.org, и их следует понимать в сочетании с «текущей работающей ветвью» и «фактическим путем конфигурации»: | CVE | Версии, затронутые вышестоящими тегами | Официально обозначенная фиксированная версия | | -------------- | -------------------------------------- | ------------------------------------------------- | | CVE-2026-15176 | `0.1.29–1.31.6` | `1.30.6+` или `1.31.7+` в соответствующих ветках. | | CVE-2026-93479 | `1.30.0–1.30.5`，`1.31.2–1.31.6` | То же, что и выше | | CVE-2026-97205 | `0.8.11–1.31.6` | То же, что и выше | | CVE-2026-95101 | `1.25.0–1.31.6` | То же, что и выше | | CVE-2026-97629 | `1.23.2–1.31.6` | То же, что и выше | CVE-2026-93479 имеет определенные ограничения для ознакомительной версии; не каждая старая версия NGINX подвержена этой регрессии. На более старые версии за пределами этих диапазонов все еще может влиять более ранняя уязвимость регулярного выражения `map` CVE-2026-42533. [S1](https://keendigit.com/ru/insights/nginx-remediation-guide#source-1) ### 3.3 Ubuntu: резервные порты распространения (USN-8955-1) Canonical USN-8955-1 от 26 октября 2026 г. предоставляет обновление безопасности для четырех сборок Ubuntu: [S13](https://keendigit.com/ru/insights/nginx-remediation-guide#source-13) | Версия Ubuntu | `nginx` и та же исправленная версия исходного пакета. | Описание | | ------------- | ----------------------------------------------------- | ----------------------------------------------------------------------------- | | 22.04 LTS | `1.18.0-6ubuntu14.22` | Это поддержка поставщика; номер исходной версии по-прежнему показывает 1.18.0 | | 24.04 LTS | `1.24.0-2ubuntu7.19` | То же, что и выше | | 26.04 LTS | `1.28.3-2ubuntu1.12` | То же, что и выше | | 26.10 | `1.30.4-7ubuntu1.1` | То же, что и выше | В объявлении содержатся соответствующие фиксированные версии аналогичных пакетов, таких как `nginx-core`, `nginx-extras`, `nginx-full` и `nginx-light`. Не делайте выводов о том, стоит ли это исправлять, исходя только из восходящей части, показанной `nginx -v`. такие как Ubuntu, 24.04 и `1.24.0-2ubuntu7.19` были исправлены этим поставщиком, но `1.24.0` из любого источника не является по своей сути безопасным. Ubuntu официально также четко обозначил, что CVE-2026-95101 влияет только на Ubuntu 26.04 / 26.10, а CVE-2026-97629 влияет только на Ubuntu 24.04 / 26.04. /26.10. Здесь представлена собственная упаковка и функционал Ubuntu, которые нельзя напрямую продвигать в другие дистрибутивы. [S13](https://keendigit.com/ru/insights/nginx-remediation-guide#source-13) ### 3.4 Debian: Различия между версиями необходимо проверять отдельно. Рекомендации Debian DSA-6575-1 (2026-10-21) охватывают эти пять CVE и определяют фиксированный пакет `nginx` для Debian 13 / trixie как: ```text 1.26.3-3+deb13u10 ``` Однако на момент проверки этого отчета `1.22.1-9+deb12u10` для Debian 12 / bookworm все еще помечен как уязвимый системой отслеживания безопасности Debian. Поэтому: - Debian 13 Просто обновите и примите согласно DSA-6575-1. - Debian 12 должен проверить исправления безопасности, предоставленные текущим средством отслеживания безопасности или поставщиком ELTS, одно за другим; до того, как исправление будет подтверждено в объявлении, не заявляйте, что все пять элементов были исправлены на основе успеха `apt upgrade`. - Исходный пакет Debian может содержать набор исправлений, независимый от номера версии nginx.org. Для пользовательских сборок вам необходимо проверить полный набор исправлений пакета исходного кода, и вы не можете просто скопировать один исходный коммит и считать его завершенным. Вышеупомянутое различие основано на записях отслеживания DSA и CVE. [S14](https://keendigit.com/ru/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/ru/insights/nginx-remediation-guide#source-15)[S16](https://keendigit.com/ru/insights/nginx-remediation-guide#source-16) ### 3.5 NGINX Plus, njs и входной контроллер | Продукты/Компоненты | Ключевые моменты выбора и проверки безопасности | | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NGINX Plus (коммерческая версия) | Пожалуйста, обратитесь к инструкциям по объявлению и обновлению ветки Plus, соответствующей F5. Последний CR на момент проверки — `PLS.37.2.0.1`, а сборка безопасности LTS — `PLS.37.0.7.1`; Версия Plus и включенный бэкпорт не могут быть напрямую заменены пороговым значением 1.30/1.31 с открытым исходным кодом. [S19](https://keendigit.com/ru/insights/nginx-remediation-guide#source-19) | | njs / ngx\_http\_js\_module | 2026-10-14 выпускает `njs 1.0.2` и исправляет CVE-2026-101019 и CVE-2026-101025; если вы используете njs, необходимо также проверить совместимость модуля с NGINX. [S20](https://keendigit.com/ru/insights/nginx-remediation-guide#source-20) | | F5 NGINX Входной контроллер/структура шлюза | Ядро NGINX — это связанная, но независимая цепочка распространения программного обеспечения. Исправьте соответствующие уязвимости с помощью соответствующих контроллеров, изображений и примечаний к выпуску. Вы не можете просто заменить двоичный файл NGINX в Pod. | | Kubernetes Сообщество `kubernetes/ingress-nginx` | Проект выведен из эксплуатации в марте 2026 года и больше не будет обеспечивать новое обслуживание безопасности. Вам следует запланировать переход на поддерживаемый контроллер или Gateway API, а не путать номер его выпуска с F5 NGINX Ingress Controller. [S21](https://keendigit.com/ru/insights/nginx-remediation-guide#source-21) | ### 3.6 Какой патч вам действительно следует выбрать? | Форма развертывания | Рекомендуемые практики | Доказательство ремонта | | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | nginx.org официальный пакет DEB/RPM | Обновление до фиксированной версии восходящей ветки | `nginx -v/-V`, источник пакета, официальное сообщение о безопасности | | Официальный репозиторий Ubuntu/Debian | Установите пакеты безопасности поставщика | Полная версия пакета + USN/DSA поставщика + статус CVE | | RHEL/Alma/Rocky/SUSE/Другие дистрибутивы | Обновление в соответствии с бюллетенями по безопасности конкретного дистрибутива и версиями пакетов. | CSAF/объявление соответствующего поставщика, версия Ubuntu/Debian не может быть применена. | | Официальные или пользовательские изображения контейнеров | Восстановите или извлеките проверенный ремонтный образ и заменяйте его по мере поступления. | Дайджест образа, сборка SBOM, запуск идентификатора образа модуля/контейнера | | Самокомпилированные NGINX, OpenResty, Tengine или версии с исправлениями сторонних модулей. | Отдайте приоритет использованию полной версии безопасности сопровождающего; при необходимости выполнять проверенные бэкпорты исправлений для целевого дерева исходного кода. | Пять исправлений уязвимостей, совместимость ABI/модулей, регресс единиц и бизнеса. | OpenResty и Tengine — разные системы выпуска; в этой таблице описан только метод проверки. не означает, что все его версии затрагиваются одновременно со стандартом NGINX, и при этом исправление исходного кода не может быть применено безоговорочно. ## 4. Формальный процесс ремонта ### 4.1 Инвентаризация реальных случаев получения внешнего трафика Сопоставить по крайней мере каждую запись: - Имя домена, балансировка нагрузки/CDN/ссылка на пограничный прокси-сервер, метод раскрытия исходного сайта и используемый сетевой протокол. - Продукты NGINX (Open Source, Plus, Ingress и т. д.), полная версия, исходный код репозитория пакетов, дайджест образа. - `nginx -V` отображает модули сборки и параметры компиляции; есть ли njs, Lua, OpenResty и сторонние динамические модули. - Реально работающий master/worker PID, сервисный блок/контейнер/под, реплика и узел Worker. - Фактически действующие конфигурации `http`/`stream`, `server`, `location`, `include`. - Включить ли HTTP/3, mTLS, SSI/AIO, динамический путь журнала, сложный `map` и захват регулярных выражений. Не просто проверяйте `/etc/nginx/nginx.conf` по умолчанию. Производственная среда часто загружает несколько сайтов, TLS и конфигурации модулей через `include`. Также может быть несколько путей установки NGINX или несколько уровней прокси. ### 4.2 Проверьте информацию о версии и компиляции. ```bash # NGINX 版本及构建选项 nginx -v nginx -V 2>&1 # Linux：查看实际运行的 NGINX 进程 ps -eo pid,ppid,user,comm,args | grep '[n]ginx' # Debian / Ubuntu：查看完整已安装包版本、来源 apt-cache policy nginx # 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包 dpkg-query -W 'nginx*' 2>/dev/null # RPM 系：以实际安装包及仓库公告为准 rpm -qa | grep '^nginx' ``` `nginx -V` сообщает о сборке двоичного файла, найденного по пути командной строки; это не доказывает, что работающий worker его загрузил. В `nginx -v` может отсутствовать полный суффикс пакета дистрибутива, поэтому проверьте также менеджер пакетов или записи цепочки поставок. ### 4.3 Экспортируйте эффективную конфигурацию и выполните первый раунд статического скрининга. `nginx -T` проверит конфигурацию и выгрузит объединенную конфигурацию. Вывод может содержать конфиденциальную информацию, такую как учетные данные аутентификации, пути к ключам, внутренние имена хостов и т. д. Рекомендуется сохранять контролируемый терминал с разрешениями root и разрешениями для частных файлов и не публиковать исходные файлы в общедоступных рабочих заданиях: ```bash sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log' sudo grep -nE \ 'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \ /root/nginx-effective.conf ``` Это всего лишь указатель пути кандидата, а не надежный инструмент автоматического определения CVE: 1. `grep` не может определить, находятся ли переменные в одном и том же `location` или в одной и той же цепочке оценки запроса, а также не может вывести отношения наследования конфигурации. 2. `proxy_request_buffering on`, некоторые конфигурации кеша и билетов имеют значения по умолчанию, и отсутствие написания соответствующих инструкций не означает, что риск исчезает. 3. Конфигурации, созданные обратными прокси-серверами, CDN, дополнительными контейнерами или контроллерами, могут отличаться от файлов, проверенных вручную. 4. Характеристики `NGINX Plus` и динамических модулей, возможно, потребуется подтвердить с помощью соответствующих официальных инструментов управления. ### 4.4 Развертывание исправления по доверенным каналам. Debian/Ubuntu (официальный репозиторий дистрибутива): ```bash sudo apt-get update apt-cache policy nginx # 升级发行版仓库中已经安装的 NGINX 及相关包； # 先确认 Candidate 属于修复版本，再执行升级。 sudo apt-get install --only-upgrade nginx # 对实际安装的 nginx-core / nginx-full / nginx-extras 等包 # 确认它们的版本和依赖一同达到厂商修复要求。 dpkg-query -W 'nginx*' 2>/dev/null ``` Этот набор команд не может генерировать исправления безопасности из воздуха, которые еще не доступны. Если обновленный пакет по-прежнему считается уязвимым системой отслеживания безопасности, особенно для Debian 12, требуются дополнительные меры по восстановлению, изоляции или миграции поставщика. [S13](https://keendigit.com/ru/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/ru/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/ru/insights/nginx-remediation-guide#source-15) Официальный пакет nginx.org: ```bash # 先确认仓库来自 nginx.org、目标分支和候选版本 apt-cache policy nginx # 经变更审批后再执行对应仓库的升级命令 sudo apt-get install --only-upgrade nginx ``` При использовании самокомпилированных OpenResty, Tengine или NGINX Plus используйте версию исправления, поддерживаемую соответствующим сопровождающим, и не смешивайте nginx.org, дистрибутив и пакеты стороннего репозитория. Исходные двоичные файлы/образы, конфигурации, подписи и манифесты развертывания отката должны быть сохранены. Containers/Kubernetes: обновите неизменяемый образ, запишите его дайджест и замените все старые реплики поэтапным развертыванием. `kubectl rollout status` только подтверждает завершение работы контроллера развертывания; также проверьте дайджесты изображений, входную маршрутизацию и неработоспособные реплики. ### 4.5 Проверьте конфигурацию и замените старый Worker. ```bash sudo nginx -t # 按服务实际名称、主机高可用和变更窗口执行重启 sudo systemctl restart nginx sudo systemctl status nginx --no-pager # 核查真正存在的 master / worker ps -eo pid,ppid,user,comm,args | grep '[n]ginx' ``` Не рассматривайте `nginx -s reload` как доказательство того, что запущен новый двоичный файл: обычные перезагрузки конфигурации позволяют старому master запускать новые рабочие процессы без замены исполняемого файла. NGINX поддерживает специальную онлайн-процедуру обновления двоичных файлов, но она требует дополнительных действий и проверки. Без установленной процедуры используйте переключение трафика высокой доступности с последующим перезапуском службы или разверните замещающие контейнеры. [S22](https://keendigit.com/ru/insights/nginx-remediation-guide#source-22) Если вы управляете NGINX через сокет `systemd`, сценарий входа в контейнер или несколько установок, вам следует проверить фактическую цель запуска и путь процесса, а не сразу предполагать, что `systemctl restart nginx` охватывает все экземпляры. ### 4.6 Принять и выполнить бизнес-регресс от реального внешнего входа Рекомендуется выполнить как минимум: - Правильны ли обычные HTTPS, переписанные маршруты, статические ресурсы и страницы сопоставления `alias`. - Правильны ли обычный дистрибутив `map`, переменный путь root, путь журнала доступа, маршрутизация SNI/сертификата и прокси-сервер Stream. - Нормальные загрузки, фрагментированные загрузки, запросы API и ограничения объема восходящего потока для HTTP/3 (если они включены) остаются такими же, как и ожидалось. - mTLS: законные запросы сертификатов должны быть успешными; отсутствующие, просроченные или неавторизованные сертификаты по-прежнему должны отклоняться, а возобновление/повторное подключение TLS не должно случайно изменять разрешения. - Нормальна ли страница SSI и асинхронный доступ к файлам; журнал ошибок не показывает никаких аномальных запросов на обращение к памяти или повторяющихся сбоев Worker. - После переключения трафика процесс старой версии и реплика старого образа должны были завершиться. Тестирование должно проводиться в собственной или авторизованной среде. Обычный дымовой тест запроса сам по себе не может доказать, что уязвимость памяти устранена; в конечном итоге исправленная версия поставщика, исправление исходного кода и тест времени выполнения должны быть совместно приняты для приемки. ## 5. Меры по смягчению последствий, когда немедленная модернизация невозможна. Этот раздел представляет собой вариант снижения риска, а не замену патча. Все временные изменения конфигурации необходимо скопировать, выполнить `nginx -t`, выпустить пакетно и при необходимости быстро откатить. [S3](https://keendigit.com/ru/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/ru/insights/nginx-remediation-guide#source-4) ### 5.1 Управление приоритетом трафика на основе внешнего воздействия Установите приоритет снижения поверхности атаки для сервисов, которые невозможно обновить вовремя: на поверхности управления и внутри API Добавьте контроль доступа к доверенным источникам, изоляцию вышестоящей сети или кратковременный автономный режим; добавить соединение, тело запроса и ограничения скорости для входов с высоким уровнем риска; убедитесь, что аутентификация источника происходит в NGINX, связанном с записью, перед цепочкой обработки запроса. Следует отметить, что большинство самих уязвимостей расположены в NGINX. Внутри плоскости данных традиционные правила WAF могут неточно определять условия срабатывания пользовательской конфигурации. ### 5.2 `alias`/`rewrite`: избегать вычисления `$request_filename` после перезаписи Рекомендуется проверить и отрегулировать: - Старайтесь не выполнять `rewrite`, который изменит URI одновременно с `location`, используя `alias`. - Избегайте использования `$request_filename`, когда URI был переписан, но правильное сопоставление позиций еще не завершено. - Проверьте наличие косвенных ссылок на переменные в `return`, `set`, `if`, `add_header`, формат журнала доступа и включаемые файлы. - Используйте чистый `root`/`try_files`/независимый `location`, когда это позволяет бизнес, но меняйте только `alias` на `root`. Это также может изменить семантику пути к файлу, которую необходимо проверять один за другим. Не копируйте общий «шаблон безопасной перезаписи» напрямую из Интернета, чтобы перезаписать существующую конфигурацию. Различные префиксы `location` и цели перезаписи приводят к сращиванию путей с совершенно разными значениями. [S5](https://keendigit.com/ru/insights/nginx-remediation-guide#source-5) ### 5.3 `map`/Regex: уменьшение смешивания состояний переменных захвата. Рекомендуется отдавать приоритет именованным захватам и ограничивать область их распространения, а не разрешать повторное использование анонимных захватов, таких как `$1`, в различных путях оценки регулярных выражений с течением времени. Например: ```nginx # 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整 map $host $tenant_root { default /srv/www/default; ~^(?[a-z0-9-]+)\.example\.net$ /srv/www/$tenant; } ``` Этот фрагмент демонстрирует лишь более простую для аудита структуру владения переменными; не означает, что было доказано, что он независимо устраняет все триггерные пути CVE-2026-93479. В частности, проверьте, ссылаются ли на переменные захвата заранее другие `root` или `log_format`, и существуют ли `volatile`, динамические пути и взаимозависимые цепочки вычислений. F5/CERT рекомендует использовать именованный захват и ограничить область использования соответствующей регулярной соответствующей конфигурацией в качестве краткосрочного облегчения. [S3](https://keendigit.com/ru/insights/nginx-remediation-guide#source-3)[S6](https://keendigit.com/ru/insights/nginx-remediation-guide#source-6) ### 5.4 AIO + SSI: Отключение ненужных комбинаций функций. Для серверов/путей, которым не требуется SSI или асинхронный файловый ввод-вывод, используйте: ```nginx # 在适当的 http/server/location 上下文中配置 ssi off; aio off; ``` С точки зрения условий срабатывания уязвимости, закрытия одной из двух обычно достаточно, чтобы удалить конкретную описанную цепочку; одновременное закрытие применимо только к сценариям, в которых бизнес не полагается на эту возможность. Проверьте `include virtual`, подзапросы, кэш и поведение пула потоков; когда нагрузка обратного прокси-сервера высока, выключение AIO может изменить задержку и производительность ввода-вывода. [S7](https://keendigit.com/ru/insights/nginx-remediation-guide#source-7) ### 5.5 HTTP/3 Запросить инъекцию тела: при необходимости временно закрыть вход Отключите прослушиватель `quic`, включающий HTTP/3, отмените заголовок ответа `Alt-Svc`, который объявляет HTTP/3, и проверьте, отправляет ли пограничный уровень/балансировщик нагрузки запросы QUIC непосредственно к невосстановленному NGINX: ```nginx # 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen server { listen 443 ssl; # 保留 HTTPS/TCP 入口 # 对支持新版语法的构建，可在此使用 http2 on; # 删除原有的 listen 443 quic reuseport; # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项） # 其余证书、server_name、location 等配置保持不变 } ``` Вышеуказанное является лишь описанием разницы в изменениях, а не полной конфигурацией сервера, которую можно включить индивидуально. Синтаксис настроек HTTP/2 связан с версией NGINX; если вам нужно сохранить HTTP/2, вам следует использовать `http2 on;` или существующий допустимый синтаксис в соответствии с соответствующей версией и проверить `nginx -t`. перед развертыванием необходимо объединить с существующей конфигурацией сервера, а не заменять весь раздел этим разделом. также проверяет брандмауэр UDP 443, местоположение завершения HTTP/3 и резервный путь клиента CDN/передний прокси. Другой тип краткосрочного смягчения — использовать `proxy_request_buffering off;` на затронутом пути прокси-сервера, но это изменит поведение потоковой передачи тела запроса в восходящем направлении, повторных попыток сбоя и некоторых рабочих процессов загрузки; использоваться только после достаточного тестирования и подтверждения того, что директива действительно соответствует затронутому пути прокси-сервера HTTP/3. [S8](https://keendigit.com/ru/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/ru/insights/nginx-remediation-guide#source-18) ### 5.6 TLS Билет сеанса: приоритетная защита mTLS Граница аутентификации Если обновление невозможно и экземпляр использует общий кэш сеансов + автоматическую ротацию ключей билетов, оцените: ```nginx # 在 nginx http/server 适当作用域进行配置 ssl_session_tickets off; ``` Это может отключить механизм билета сеанса TLS, тем самым удаляя путь подделки билета, описанный в этой уязвимости; однако это может повлиять на производительность возобновления сеанса. Вы не можете просто отключить проверку сертификата клиента mTLS, чтобы «избежать уязвимостей», так как это напрямую удалит исходную границу аутентификации. [S9](https://keendigit.com/ru/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/ru/insights/nginx-remediation-guide#source-12) Явные файлы `ssl_session_ticket_key` и безопасная ротация также могут использоваться профессиональными процессами управления TLS для обхода автоматически создаваемых условий, но хранение ключей, полное распределение узлов, ротация и жизненные циклы старых билетов требуют тщательного аудита. Не рекомендуется жестко запрограммировать долгосрочный многоразовый ключ в обычной веб-конфигурации или сценариях на случай временных чрезвычайных ситуаций. Критически важные службы, использующие mTLS, должны дополнительно отслеживаться на предмет возобновления сеанса TLS и отклонения запросов без действующего сертификата клиента. [S12](https://keendigit.com/ru/insights/nginx-remediation-guide#source-12) ### 5.7 Роль операционной системы и охраны границ ```bash # Linux：常见值 2 表示进程地址空间随机化处于完整启用状态 sysctl kernel.randomize_va_space ``` ASLR, рабочие процессы, отличные от root, контейнерные файловые системы только для чтения, минимальные права доступа к файлам и сетевая изоляция могут снизить влияние потенциального RCE. ASLR не исправляет переполнение кучи или UAF и не может гарантировать, что рабочие процессы не приведут к сбою. WAF, ограничения скорости и размера тела запроса не исправляют синхронизацию ключей билетов TLS. [S4](https://keendigit.com/ru/insights/nginx-remediation-guide#source-4) ### 5.8 Распространенное заблуждение: этих операций недостаточно для завершения ремонта. | Общие операции | Почему этого недостаточно? | | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | «nginx -v выглядит относительно новым» | Ветка, к которой он принадлежит, полная версия обратно перенесенного пакета релизной версии и онлайн-процесс не проверяются. | | «Обновлена только одна из интрасетей» | Старый исходный экземпляр Worker/старый контейнер/старый исходный экземпляр CDN по-прежнему получает запросы. | | «Сайт не использует PHP/динамические теги» | Дефект возникает при анализе основного пути NGINX или протокола и не зависит от выполнения PHP. | | «Открыть WAF/Cloudflare достаточно» | Невозможно доказать, что WAF блокирует все дефекты памяти, зависящие от конфигурации NGINX, или дефекты возобновления TLS. | | «Уже открыто ASLR» | Просто воспользуюсь преимуществами снижения сложности; DoS с внедрением запроса все еще возможно. | | «HTTP/3 не доступен в общедоступной сети, поэтому нет необходимости обновлять его вообще» | Остальные четыре CVE по-прежнему требуют независимой оценки; и могут быть прямые связи со скрытым происхождением | | «Июльская уязвимость `map` устранена» | Октябрь CVE-2026-93479 связан с последующими проблемами регрессии оценки сценария. | | «Отключение кэширования решает все проблемы» | Влияет только на некоторые кэши TLS или сценарии AIO и не распространяется на псевдонимы, сценарии, HTTP/3. | ## 6. Идеи по внедрению официального патча и замечания по ним В этом разделе описаны исправления NGINX, выпущенные в октябре 2026 г. Фрагменты иллюстрируют типичные изменения для проверки исправлений; они не являются полными, независимо компилируемыми исправлениями. Для пользовательских сборок просмотрите полные коммиты, окружающий код и тесты и отдайте предпочтение полностью поддерживаемому выпуску. [S5](https://keendigit.com/ru/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/ru/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/ru/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/ru/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/ru/insights/nginx-remediation-guide#source-9) ### 6.1 CVE-2026-15176: URI был переписан, чтобы включить условия отклонения сопоставления путей `alias`. Восходящий коммит изменил `ngx_http_map_uri_to_path()` на `src/http/ngx_http_core_module.c`: ```diff - if (alias && !r->valid_location) { + if (alias && (!r->valid_location || r->uri_changed)) { ``` Фокус обзора: невозможно продолжить вычисление пути к файловой системе, если URI изменился, но соответствующая семантика местоположения `alias` больше не является надежной. Это расширение предварительного ограничения. Это не простая проверка того, содержит ли запрос URI недопустимые символы. [S5](https://keendigit.com/ru/insights/nginx-remediation-guide#source-5) ### 6.2 CVE-2026-93479: правильно различать длину выходных данных и зарезервированную длину. Восходящий коммит одновременно обновляет `src/http/ngx_http_script.c` и `src/stream/ngx_stream_script.c`. Основное намерение можно резюмировать следующим образом: ```diff - n = len; + n = 0; /* ...计算实际脚本输出长度... */ - value->len = n; - value->data = ngx_pnalloc(pool, n); + value->len = n + len; + value->data = ngx_pnalloc(pool, n + len); ``` Здесь `pool` — это иллюстративное имя параметра: фактические выражения распределения HTTP и Stream различаются. Это изменение сначала вычисляет длину выходных данных сценария, а затем добавляет зарезервированную длину к окончательному распределению, чтобы выходные данные не перезаписывали зарезервированное пространство. [S6](https://keendigit.com/ru/insights/nginx-remediation-guide#source-6) При аудите и резервном портировании также должен быть задействован соответствующий оценщик HTTP/Stream; только проверка файла синтаксиса конфигурации `map` не может доказать, что дефект устранен. ### 6.3 CVE-2026-97205: установить порог безопасности для счетчика 8-битных асинхронных операций. Восходящий поток добавлен по адресу `src/http/ngx_http_request.h`: ```c #define NGX_HTTP_MAX_BLOCKED 250 ``` И добавьте аналогичные записи для асинхронного чтения файлов, ожидания кэша, фильтрации вывода и работы потоков: ```c if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) { /* 使用同步路径，或者拒绝新的异步操作 */ } ``` Фокус обзора: все фактические пути кода, которые добавят `r->main->blocked`, должны быть охвачены. Вы не можете просто записать пороговую константу в заголовочный файл. Backport также необходимо проверить полную координацию синхронного возврата, асинхронного обратного вызова и возврата ошибки, чтобы гарантировать, что взаимоблокировка или утечка ссылок не будут вызваны прямым отклонением задач. [S7](https://keendigit.com/ru/insights/nginx-remediation-guide#source-7) ### 6.4 CVE-2026-95101: ведение статуса `skip` отдельно для неизвестных кадров. Восходящий поток добавляет поле `skip` в структуру статуса парсера HTTP/3 и выполняет разделение статусов: ```c if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) { st->skip = st->length; st->length = 0; st->state = sw_skip; } /* ... */ rc = ngx_http_v3_parse_skip(b, &st->skip); ``` Ключевым моментом является не «отключение неизвестных кадров HTTP/3», а обеспечение того, чтобы при многократном чтении количество пропущенных байтов и длина полезной нагрузки DATA всегда управлялись независимыми состояниями. Обзоры должны быть сосредоточены на неизвестном сегментировании кросс-буфера кадров и возможной согласованности `client_max_body_size`. [S8](https://keendigit.com/ru/insights/nginx-remediation-guide#source-8) ### 6.5 CVE-2026-97629: синхронизировать весь массив слотов ключей TLS. Изменения восходящего потока расположены по адресу `src/event/ngx_event_openssl.c`: ```diff ngx_memcpy(keys->elts, cache->ticket_keys, - 2 * sizeof(ngx_ssl_ticket_key_t)); + keys->nelts * sizeof(ngx_ssl_ticket_key_t)); ``` Исходное изображение содержало три слота для ключей, но были скопированы только первые два. Вместо этого выполните синхронизацию на основе фактического количества элементов массива, чтобы гарантировать, что набор ключей голосования Worker соответствует общей памяти. При проверке также убедитесь, что логика распределения, инициализации, общей блокировки и ротации массива согласована, а не просто однократно проверяйте изменение длины `memcpy`. [S9](https://keendigit.com/ru/insights/nginx-remediation-guide#source-9) ### 6.6 Почему не рекомендуется применять только разрозненные фрагменты патчей? Эти пять модификаций охватывают `src/http`, `src/stream`, `src/http/v3` и `src/event` соответственно, а более старые версии могут иметь резервные копии безопасности и неофициальные расширения. Резервное копирование должно формировать следующую матрицу проверок: | Проверить объект | Что необходимо подтвердить | | ------------------------- | ----------------------------------------------------------------------------------------------------- | | источник патча | Официальная подача, соответствие целевой версии, полное исправление и проверка подписи. | | Оригинальный набор патчей | Не конфликтует с историческими модификациями, такими как CVE-2026-42533, бэкпорт дистрибутива и т. д. | | путь кода | Сценарий HTTP + Stream, AIO/thread, HTTP/3, OpenSSL — все билеты покрываются. | | Скомпилировано совместимо | OpenSSL, PCRE, модуль ABI, динамический модуль и зависимости ссылок согласованы. | | функциональная регрессия | Перезапись `alias`, динамический журнал, SSI/AIO, загрузка HTTP/3, возобновление сеанса mTLS | | время выполнения | На всех модулях Worker/Pods используются новые проверенные сборки, устаревших образов не осталось. | Для команд, которые поддерживают свои собственные выпуски, рекомендуется хранить проверяемые идентификаторы исправлений, версии пакетов, журналы сборки и отчеты о регрессии для каждого CVE; для обычной эксплуатации и обслуживания самым безопасным решением является установка полных обновлений безопасности поставщика. ## 7. Отслеживание исторических уязвимостей, старые ветки и другие продукты. ### 7.1 NGINX основная уязвимость, достойная одновременного подтверждения с мая по сентябрь 2026 г. Многие экземпляры NGINX, которые не обновлялись в течение длительного времени, затронуты не только новой проблемой в октябре. Ниже приведены типичные узлы ремонта в ближайшем будущем: [S1](https://keendigit.com/ru/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/ru/insights/nginx-remediation-guide#source-2). | CVE | Первый выпуск исправлений | Ключевые риски и условия, требующие аудита | | -------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | CVE-2026-42945 | Stable 1.30.1 / Mainline 1.31.0, 13 мая | `rewrite` Логика анонимного захвата и замены регулярных выражений вызывает переполнение кучи, потенциальный RCE; есть публичные сообщения о попытках атак в дикой природе | | CVE-2026-9256 | Stable 1.30.2 / Mainline 1.31.1, 22 мая | Перекрывающийся захват регулярных выражений и оценка длины в `rewrite` приводят к переполнению | | CVE-2026-42055 | Stable 1.30.3 / Mainline 1.31.2, 17 июня | HTTP/2 Специальная конфигурация для восходящего потока или gRPC, условие большого заголовка запроса вызывает переполнение буфера | | CVE-2026-42530 | Mainline 1.31.2, 17 июня | HTTP/3 Использование после бесплатного использования; официальная маркировка касается диапазона `1.31.0–1.31.1` | | CVE-2026-42533 | Stable 1.30.4 / Mainline 1.31.3, 15 июля | `map` + оценка переменной захвата регулярных выражений вызывает переполнение кучи, и последующие исправления имеют регрессионную корреляцию с CVE-2026-93479 в октябре. | | CVE-2026-60005 | Stable 1.30.4 / Mainline 1.31.3, 15 июля | `ngx_http_slice_module` Содержимое памяти просочилось при определенных условиях обновления переменных и кэша. | | CVE-2026-56434 | Stable 1.30.4 / Mainline 1.31.3, 15 июля | SSI связан с UAF; не та же самая причина root, что и октябрьская уязвимость подсчета AIO | | CVE-2026-90439 | Stable 1.30.5 / Mainline 1.31.6, 15 сентября | Ограниченное переполнение кучи HTTP/3 + конкретной комбинации версий OpenSSL, в основном проявляется как сбой/ограниченное повреждение памяти. | Другие уязвимости, такие как NGINX Core, HTTP/2, кодировка и SMTP, анонсированные в 2026 году, также должны быть исследованы в соответствии с официальными бюллетенями по безопасности; Эта таблица намеренно фокусируется на типичных событиях, которые наиболее актуальны для текущих общедоступных развертываний обратного прокси-сервера NGINX и имеют последствия для безопасности памяти или целостности запросов. это не все CVE в 2026 году. Список. [S1](https://keendigit.com/ru/insights/nginx-remediation-guide#source-1) #### Почему стоит обратить особое внимание на CVE-2026-42945 Существуют бюллетени по безопасности от государственных органов, в которых фиксируются активные действия по эксплуатации, а также общедоступная информация о коде эксплойта для этой уязвимости `rewrite` за май. Поэтому для экземпляров, которые не подвергались исправлениям в течение длительного времени с мая по настоящее время и имеют открытые сложные перезаписи регулярных выражений в публичной сети, помимо завершения ремонта, необходимо дополнительно просмотреть аномальный сбой Worker, журналы доступа и подозрительные изменения в это время. [S23](https://keendigit.com/ru/insights/nginx-remediation-guide#source-23) «Произошла попытка атаки» не доказывает автоматически, что злоумышленник надежно выполнил команды на каждой цели; когда речь идет о реагировании на инциденты, индикаторы компрометации и сбои процессов должны расследоваться отдельно от реальных доказательств повышения или сохранения привилегий. ### 7.2 Исправление для старых версий и бэкпортов дистрибутива. NGINX Разные ветки имеют свои собственные циклы поддержки и разное время внедрения уязвимостей. Пять новых патчей не могут быть развернуты во всех деревьях ранних исходных кодов без проверки. | сцена | Рекомендуемая стратегия | | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Релизная версия анонсировала полные исправления безопасности | Используйте пакеты поставщиков и документируйте полные версии пакетов; избегайте замены несовместимыми исходными двоичными файлами | | Debian 12 и другие затронутые выпуски, на которые еще не распространяются все CVE в этом пакете. | Отправляйте рабочие задания по риску, ограничивайте внешнее воздействие и проверяйте статус поставщика/ELTS; мигрируйте или используйте проверяемую цепочку обновлений, когда это необходимо. | | Исторические ветки, прекратившие поддержку вышестоящего уровня | Установите приоритет перехода на поддерживаемые версии; если необходимо краткосрочное резервное копирование, специалисты по сопровождению оценят зависимости и совместимость исправлений, а также напишут полные тесты. | | Поставляется с вилкой NGINX (OpenResty, Tengine, индивидуальный шлюз) | Сначала определите, включен ли соответствующий путь кода, а затем используйте заявление о безопасности сопровождающего ветки. Он не может быть напрямую эквивалентен исходной версии. | | Исправления безопасности приводят к изменениям в бизнес-функциональности | Внедрить поэтапное развертывание, переключение трафика между версиями и адаптацию конфигурации; нецелесообразно восстанавливать незафиксированную версию общедоступной сети без изоляции. | ### 7.3 Отдельное исправление для njs, Ingress и NGINX Core. - njs: Помимо основной программы NGINX, вам также необходимо проверить версию самого JavaScript-модуля NGINX. `njs 1.0.2` устраняет проблему нехватки памяти при синтаксическом анализе XML и несогласованность проверки XML с атрибутами ссылки на объект, возникшую в октябре 2026 г. Для развертываний, связанных с проверкой подписи XML с использованием `nginx-saml`, вам следует дополнительно прочитать официальные инструкции njs для сценариев подключаемых модулей. [S20](https://keendigit.com/ru/insights/nginx-remediation-guide#source-20) - F5 NGINX Plus / NGINX Контроллер входящего трафика. Кроме того, контроллер и структура шлюза могут иметь дополнительные бюллетени безопасности, разные версии упаковки и уникальные уязвимости политики. Обновление одного уровня не означает автоматическое обновление другого уровня. [S19](https://keendigit.com/ru/insights/nginx-remediation-guide#source-19) - Сообщество Kubernetes ingress-nginx: Официальные лица Kubernetes уже заявили, что контроллер прекратил обслуживание в марте 2026 года, и его склад нельзя спутать с контроллером F5. Затронутым компаниям следует планировать плавный переход и проверять аннотации Ingress и семантические различия Gateway API, а не ждать новой версии безопасности. [S21](https://keendigit.com/ru/insights/nginx-remediation-guide#source-21) ## 8. Критерии приемки и последующие проверки В качестве условий принятия изменений нарядов на работу рекомендуется использовать следующий список: | Проект | Квалификационные стандарты | Доказательства, которые можно сохранить | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Покрытие активов и портала | Все внешние и напрямую подключенные экземпляры, которые могут обходить CDN, были инвентаризированы. | Доменное имя, LB, IP, список подов/контейнеров | | Источник пакета и объем восстановления | Используйте подтвержденные версии, охватывающие все применимые CVE. | Рекомендации по безопасности восходящего потока, USN/DSA, версия пакета, дайджест образа | | старый процесс завершается | Все старые master/worker/контейнеры заменены. | PID/время запуска, скользящее состояние развертывания, работающий образ | | Аудит конфигурации | Комбинации высокого риска исключены или покрыты исправлениями, а отношения наследования проверены. | отредактированное резюме и запись аудита `nginx -T` | | TLS/mTLS | Доверенные сертификаты проходят; недействительные или отсутствующие сертификаты отклоняются; возобновление сеанса не обходит аутентификацию | Отрицательный/положительный авторизационный тест, контролируемые результаты теста TLS | | HTTP/3 Тело запроса | Включить путь исправлено; Тело запроса восходящего потока и регулирование ведут себя правильно | HTTP/3, загрузка прокси, регрессионный тест ограничения объема | | SSI/AIO | Функция соответствует требованиям, Worker не имеет аварийного прерывания. | Регрессия бизнеса, мониторинг сбоев и ошибок | | Мониторинг эксплуатации и технического обслуживания | Нет очевидного исключения 5xx, SIGSEGV, процесс завершается неоднократно | Индикаторы обслуживания и журналы до и после изменений | | Стратегия отката | Если необходим откат, сначала ограничьте воздействие и сохраните границы безопасности. | Приказы о внесении изменений, чрезвычайные потоки и планы карантина | | последующий жизненный цикл | Определите подписку на бюллетени по безопасности, частоту обновления контейнера и планы миграции филиалов. | Журнал обновления, ответственное лицо и дата следующего аудита | ### 8.1 На что следует обратить внимание в журналах и рабочем состоянии? Устраняйте неполадки на серверах, которые были открыты в течение длительного времени `worker process exited on signal` 、 `SIGSEGV` , всплески сбоев запросов, ненормальную агрегацию доступа к источнику, неожиданное возобновление сеанса TLS или успех аутентификации, а также ненормальное поведение тела запроса серверной части. Эти индикаторы могут использоваться только в качестве улик для расследования и не являются достаточными доказательствами для прямого доказательства того, что определенная CVE использовалась. ;Отсутствие соответствующих логов не доказывает, что атаки не было. ### 8.2 Рекомендуемая окончательная формулировка заключения о риске В отчете о приемке производственной среды должно использоваться следующее точное выражение: > NGINX внешний служебный вход и источник пакета программного обеспечения идентифицированы. Все применимые экземпляры были обновлены до исходной официальной версии безопасности или завершено резервное копирование, подтвержденное поставщиком выпуска; старый Worker и старые контейнеры заменены. Псевдоним/перезапись/карта, AIO/SSI, тело запроса HTTP/3 и конфигурации, связанные с билетом сеанса TLS/mTLS, были проверены и прошли регрессионные тесты на функциональность, аутентификацию и целостность запроса. Для экземпляров, еще не завершивших модернизацию, дополнительно прописать зоны воздействия, компенсационные меры, ответственных лиц и сроки выполнения. Если патч для Debian 12 или других выпусков все еще не завершен, нецелесообразно считать всю форму принятия «завершенной»; неразрешенный CVE, наличие соответствующей триггерной конфигурации, состояние изоляции и окончательный маршрут обновления должны быть четко записаны. *** ## Приложение: Цитируемые источники и ссылки Описание: Номера `[Sx]` в тексте единообразно соответствуют данному разделу. Далее приоритет отдается объявлениям о безопасности исходных проектов, фиксации кода, объявлениям о релизах поставщиков и информации агентств национальной безопасности. Серьезность указанных уязвимостей описывается в соответствии с критериями рейтинга каждой организации-эмитента; дата проверки данных – 27 октября 2026 года. ### S1 — NGINX Open Source Официальный бюллетень по безопасности - Содержит затронутые вышестоящие версии, ветки исправлений и официальные уровни серьезности пяти октябрьских CVE, а также охватывает исторические уязвимости до 2026 года. ### S2 — запись о выпуске официальной версии NGINX - - Подтвердите 1.30.6 / 1.31.7 для 2026-10-14, 1.31.8 для 2026-10-21 и важные этапы выпуска безопасности с мая по сентябрь. ### S3 — Агентство кибербезопасности Сингапура: F5 NGINX Три критические уязвимости - Описание оценок CVSS v4.0 9.2, необходимые условия конфигурации и временные рекомендации по снижению риска для CVE-2026-15176, CVE-2026-93479 и CVE-2026-97205. ### S4 – Национальная служба здравоохранения Англии: F5 NGINX Рекомендации по высокому риску - Описывает DoS/потенциальное влияние RCE на проблемы безопасности памяти, а также ограничения, такие как отключение или обход ASLR. ### S5 — Официальный источник: CVE-2026-15176 - Соответствует проверке состояния `alias` и `r->uri_changed` в `ngx_http_map_uri_to_path()`. ### S6 — Официальный источник: CVE-2026-93479 - Соответствует длине сценария HTTP/Stream и логике выделения зарезервированного буфера. ### S7 — Официальный источник: CVE-2026-97205 - Соответствует порогу счета `r->main->blocked` `NGX_HTTP_MAX_BLOCKED 250` и резервному асинхронному пути. ### S8 — Официальный источник: CVE-2026-95101 - Разделение состояний соответствует неизвестной оставшейся длине кадра HTTP/3 и длине тела запроса DATA. ### S9 — Официальный источник: CVE-2026-97629 - Соответствует всем слотам ключей во время ротации билетов сеанса синхронизации TLS. ### S10 — F5: CVE-2026-15176 Объявление поставщика - Перечислите триггерные факторы, такие как `alias`, `rewrite`, `$request_filename`, и журналы доступа. ### S11 — F5: CVE-2026-93479 Объявление поставщика - Получение списка регулярных выражений карты, путь root и условия оценки переменных журнала. ### S12 — официальная документация модуля NGINX TLS/SSL - Описание `ssl_session_cache`, `ssl_session_tickets`, `ssl_session_ticket_key` и проверка подлинности сертификата клиента и другие инструкции. ### S13 — Консультации по безопасности: Ubuntu USN-8955-1 (2026-10-26) - Предоставьте полный пакет программного обеспечения с фиксированной версией и объемом распространения Ubuntu 22.04 / 24.04 / 26.04 / 26.10.. ### S14 — Консультации по безопасности: Debian DSA-6575-1 (2026-10-21) - Подтвердите пакет исправлений безопасности `1.26.3-3+deb13u10` для Debian 13 / trixie и запишите ассоциацию обратного порта для CVE-2026-93479. ### S15 — Отслеживание уязвимостей: Debian Security Tracker: CVE-2026-15176 - Используется для проверки статуса исправления дистрибутива Debian 12/bookworm и Debian 13/trixie. Этот статус может измениться в будущих обновлениях безопасности. ### S16 — Отслеживание уязвимостей: Debian Security Tracker: CVE-2026-95101 - Дополнительное подтверждение статуса безопасности уязвимости HTTP/3 на разных ветках Debian. ### S17 — Консультации по безопасности: Red Hat: CVE-2026-93479 - Дополнительное понимание корреляции между октябрьской регрессионной уязвимостью и июльским исправлением CVE-2026-42533. ### S18 — официальный документ модуля обратного прокси-сервера NGINX. - - Запросите семантику и значения по умолчанию таких конфигураций, как `proxy_request_buffering`, `client_max_body_size`, `alias`, `aio` и т. д. ### S19 — Официальные примечания к выпуску NGINX Plus - Список ветвей Plus CR/LTS, версий, исправлений и напоминаний о совместимости обновлений. ### S20 — NGINX JavaScript / njs Официальный бюллетень по безопасности - - Содержит njs 1.0.2 за октябрь 2026 г. и связанные с ним проверки XML, а также проблемы нехватки памяти. ### S21 — Kubernetes: Официальные инструкции сообщества ingress-nginx по выходу на пенсию - - Обратите внимание, что в марте 2026 года проект прекратил выпуск новых выпусков и исправлений безопасности, поэтому рекомендуется перенести поддерживаемый контроллер или Gateway API. ### S22 — официальный сервисный контроль NGINX и онлайн-инструкции по обновлению двоичных файлов. - Различают методы перезагрузки конфигурации, перезапуска и оперативного обновления исполняемого файла для принятия переключения процесса. ### S23 — Уведомление государственной безопасности: май 2026 г., уязвимость перезаписи NGINX - - Предоставление истории рисков и предложения по обновлению безопасности для CVE-2026-42945; Суждения, касающиеся эксплуатации в дикой природе, должны основываться на заявлении агентства на тот момент и дополнительных доказательствах инцидента. ### S24 — F5: CVE-2026-95101 и CVE-2026-97629 Объявления поставщиков - - Покрывает риски, связанные с внедрением тела запроса HTTP/3 и автоматической ротацией ключа билета TLS соответственно. ### S25 — F5: CVE-2026-97205 Объявление поставщика - Описание Условия срабатывания SSI/AIO и потенциальные риски повреждения памяти. [Обновление безопасности NGINX: проверка конфигурации, обновления и проверка](https://keendigit.com/ru/news/nginx-security-update) ## Консультация по обеспечению безопасности Не знаете, как изменения доверия сертификатов влияют на ваши системы? Мы можем помочь оценить затронутых клиентов и спланировать обновления безопасности. [Обсудить обновления безопасности]() [Исходная страница]() · [Индекс содержания]() KeenDigit LLC · Идентификатор регистрации в Вайоминге: 2026-002106155 [Уточните у государственного секретаря штата Вайоминг.]() © 2026 KeenDigit LLC · Шеридан, Вайоминг, США · Все права защищены.