14 сентября 2026 года LWN выложил понедельничную сводку security-апдейтов. В таблице отдельно стоит nginx: AlmaLinux 9, Debian stable и Oracle Linux 9. Это не релиз с nginx.org и не смена ветки. Это дистрибутивные сборки, которые доедут на прод только через свой пакетный менеджер.
11 сентября AlmaLinux отправила в announce ALSA-2026:66542: security-апдейт nginx для AlmaLinux 9, тип Security, важность Important. В письме одна дыра: CVE-2026-42533, произвольное выполнение кода через специально сформированные HTTP-запросы. Карточка errata, на которую указывает само письмо: errata.almalinux.org/9/ALSA-2026-66542.html.
Debian в той же сводке закрыл nginx ещё 12 сентября, DSA-6496-1. Это другой пакет и другая нумерация. Здесь речь про линейку 1.20.1 на AlmaLinux 9 и Oracle Linux 9.
ALSA-2026:66542 и CVE-2026-42533
Формулировка AlmaLinux короткая: NGINX: Arbitrary code execution via crafted HTTP requests. Оценок CVSS, PoC и факта «уже бьют в дикой природе» в письме нет. Important – оценка вендора, не чужой CVSS.
На типичном VPS с WordPress за nginx это тот бинарник, который держит TLS, отдаёт статику и проксирует PHP-FPM. Дыра в обработке HTTP-запроса, не дыра ядра WordPress. Плагины и тема сами по себе этот CVE не закрывают.
Пакет дистрибутивный. База апстрима на AlmaLinux 9 – nginx 1.20.1. Номер 1.20.1 после патча, скорее всего, останется тем же: фикс сидит в суффиксе rpm, не в новой ветке с nginx.org. Mainline 1.31.x и stable 1.30.x сами не приедут, если репозиторий штатный.
nginx-1.20.1-28.0.1.el9_8.6 в ELSA-2026-66542-0
14 сентября, уже в понедельник, Oracle Linux опубликовал ELSA-2026-66542-0: Important, Oracle Linux 9, тот же номер errata 66542. Related CVE в письме один: CVE-2026-42533. В changelog этой сборки прямо: Resolves RHEL-212458 – nginx: Arbitrary code execution via crafted HTTP requests.
Список rpm для x86_64 и aarch64 одинаковый по составу. Версия: nginx-1.20.1-28.0.1.el9_8.6. Рядом модули: nginx-core, nginx-filesystem, nginx-all-modules, nginx-mod-devel, nginx-mod-http-image-filter, nginx-mod-http-perl, nginx-mod-http-xslt-filter, nginx-mod-mail, nginx-mod-stream.
Письмо AlmaLinux списка файлов не содержит. Подставлять OL9 NVR в dnf install на AlmaLinux «наугад» я бы не стал: зеркало своё, суффикс может отличаться. Сверить локально:
rpm -q nginx nginx -v sudo nginx -t sudo systemctl reload nginx
Если rpm уже показывает 1.20.1-28.0.1.el9_8.6 или новее из своего репозитория – вы на этой линии. Если старше – dnf update nginx из штатных реп, не подмешивать nginx.org и не тащить debian-security. После обновления снова nginx -t, затем reload. Restart «на всякий случай» здесь не нужен: воркеры подхватят новый бинарник без полного останова.
Копия конфига перед правкой директив – да. Сам security-апдейт конфиг не меняет. Ломается обычно не пакет, а руки: обновили и не проверили -t, либо смотрят nginx -v, видят всё тот же 1.20.1 и решают, что «ничего не приехало». Апстримная база та же. Патч в релизе rpm.
Не пакет из apt и не USN
Типичный WordPress на Ubuntu или Debian этот ALSA не закрывает. Свой nginx там собирает Debian или Canonical. Мешать almalinux-base в sources.list Ubuntu «чтобы быстрее» – способ сломать зависимости, не способ закрыть CVE.
На Debian 13 смотреть DSA-6496-1: там trixie, сборка 1.26.3-3+deb13u8 и три CVE, не этот rpm 1.20.1. На Ubuntu в понедельничной nginx-строке LWN USN нет. Ждать свой notice Canonical, не подмешивать el9 в apt.
К базе это не относится. MariaDB и MySQL в advisory нет. PHP-FPM перезапускать из-за nginx не требуется. Кэш FastCGI и proxy_cache сами по себе эту дыру не включают и не выключают: если map с regex или нестандартный script engine у вас в конфиге есть, смысл патча как раз в обработке запроса, не в «пересобрать кэш».
Сначала понять, чей бинарник: rpm -q nginx или apt policy nginx. Потом errata своего дистрибутива. Потом -t и reload. «Обновите все серверы сегодня» из письма AlmaLinux не следует: пакет вышел 11 сентября, на прод он встанет, когда его поставят.
