nginx 1.30 — стоит ли обновляться, если всё работает на 1.24/1.26?

[koneko2]

Сидим на nginx 1.24 stable, продакшн, нагрузка средняя — около 3к rps. Вышел 1.30.2 с фиксом CVE-2026-9256 (buffer overflow в ngx_http_rewrite_module). Насколько это критично? У нас rewrite активно используется — редиректы, переписывание путей для PHP-приложения. Стоит ли прямо сейчас обновляться или подождать пока дистрибутив сам не подтянет пакет?

[tor1]

@koneko2, CVE в rewrite_module — это серьёзно если у вас пользовательский ввод как-то попадает в rewrite-правила. Если правила статические и написаны вами — риск минимальный. Но обновиться всё равно стоит, тем более что 1.30 это просто новая stable, ничего революционного.

[lost300z]

Смотри на CVSS score. Если там 7+ и у тебя торчит наружу — обновляй немедленно. Если внутренний сервис за файрволом — можно по плановому окну. Я обычно не жду когда дистрибутив обновит, беру пакеты с nginx.org напрямую, там всегда свежее.

[doppe]

Мы перешли с 1.26 на 1.30 две недели назад на нескольких серверах Debian 12. Никаких сюрпризов. Конфиги полностью совместимы. Единственное — если используешь nginx.org репозиторий, не забудь что теперь у них новая модель релизов: LTS раз в год и Continuous Release. 1.30 это stable/LTS ветка.

[lost300z]

А чем не устраивает версия от дистрибутива? На Ubuntu 24.04 сейчас 1.24, да немного отстаёт, но зато апстрим тестирует и backport-ит CVE-патчи. Для большинства задач достаточно.

[Kutz]

Для продакшна я делаю так: сначала обновляю на стейджинге, прогоняю нагрузочный тест ab или wrk, смотрю на error.log сутки. Потом rolling update по одному серверу из пула. С nginx проблем практически никогда не было — проект очень стабильный.

[middlewarlock]

Кстати в том же 1.30 пофиксили ещё buffer overflow в ngx_http_mp4_module и проблемы с mail session authentication. Если используешь nginx как mail proxy — обновляться надо точно.

[solidity2024]

Обновили четыре фронта с 1.26 на 1.30.2 на прошлой неделе, нагрузка сопоставимая с вашей. Из практики: nginx -T до и после, diff вывода — единственное место, где вообще что-то могло разойтись, у нас не разошлось. Вся процедура с rolling-обновлением и наблюдением заняла вечер. При активном rewrite на пользовательских путях я бы не ждал планового окна: дешевле потратить вечер сейчас, чем потом доказывать, что вас не задело.

[barbs]

@lost300z, дистрибутивная версия хороша ровно до момента, когда CVE громкий, а backport едет неделю-другую. У Ubuntu бывали случаи: фикс в апстриме уже есть, а в пакете тишина, и сидишь выбираешь между ручной сборкой и ожиданием. Мой компромисс: внутренние сервисы — на дистрибутивных пакетах, всё что торчит наружу — с nginx.org с пином версии и обновлением по своему графику. Тогда есть и стабильность, и контроль скорости реакции.

[alla_mihailova]

@tor1, не соглашусь с логикой «правила статические — риск минимальный». Buffer overflow в rewrite-модуле триггерится не текстом правила, а данными, которые через него прогоняются: $uri, $args, capture-группы из регекспов — это всё пользовательский ввод. Статичность правил тут почти ничего не гарантирует. У ТС rewrite стоит на путях PHP-приложения, то есть внешние данные идут через модуль постоянно — я бы относился как к «обновить в ближайшее окно», а не ждать дистрибутив.