Что срочно обновить: PHP, GitLab, Node.js, Brotli и eMudhra

Середина октября выдалась тяжёлой. За две недели вышли экстренные исправления для PHP, GitLab и Node.js. В эталонном декодере Brotli нашли запись за границу буфера, а оттуда она попала в Node.js, Bun, Python-библиотеки и прокси. А у удостоверяющего центра eMudhra закрытые ключи подбирались за доли секунды. Собрали в одном месте, что случилось, какие версии ставить и что делать, если обновиться прямо сейчас нельзя.

Коротко

Что	До какой версии обновиться	Насколько срочно
PHP	8.5.12, 8.4.27, 8.3.36, 8.2.35	Сегодня: выполнение кода без авторизации, атаки уже идут
GitLab (self-managed)	19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13	Сегодня: оценка 10 из 10, уязвимы все версии начиная с 7.0
Node.js	26.12.1, 24.22.1, 22.23.4	Сегодня: выполнение кода через Brotli и ещё девять уязвимостей
Brotli в библиотеках и прокси	libbrotli 1.2.1, Python Brotli 1.2.1, Bun 1.4.4, Envoy, Istio	На этой неделе: проверьте зависимости и пересоберите образы
Сертификаты eMudhra	свежие ca-certificates в ОС, Go 1.27.3 или 1.26.10	На этой неделе: обновите хранилища корневых сертификатов
nginx	1.30.6 или 1.31.7 и новее	Если используете alias с rewrite, SSI с AIO или HTTP/3

Почему это касается туннелей

Туннель делает локальный сервис доступным из интернета, поэтому всё написанное ниже относится и к нему. Тестовый сайт на PHP, dev-сервер на Node.js или GitLab в домашней лаборатории за туннелем уязвимы так же, как боевые серверы. Только обновляют их обычно реже.

Две привычки заметно снижают риск:

1. Обновлять локальное окружение вместе с боевым. Уязвимый PHP на ноутбуке разработчика, открытый через туннель, — такая же точка входа для атаки.
2. Не открывать сервис всем, если он нужен двоим. Туннель можно закрыть паролем, ключом в заголовке или белым списком подсетей. Запрос, который не прошёл проверку, до приложения не дойдёт. Для правил посложнее есть политики трафика и Приложения с авторизацией через SSO. Все способы мы сравнили в посте «5 способов закрыться авторизацией».

tuna http 8080 --basic-auth="anna:s3cret" --cidr-allow="203.0.113.0/24"

PHP2Shell: выполнение кода без авторизации

Что случилось: 21 октября PHP выпустил внеплановый релиз с исправлением двух критических уязвимостей в самом интерпретаторе. Обе оценены в 9.2 по CVSS 4.0, обе эксплуатируются без авторизации:

• CVE-2026-109618. Если запрос упирается в memory_limit в неудачный момент, внутренние данные остаются инициализированными наполовину, а при очистке запроса считаются корректными. Итог — повреждение памяти.
• CVE-2026-109619. Состояние запроса переживает освобождение своей памяти и достаётся следующему запросу того же воркера. Это use-after-free.

Кого касается: Уязвимы все способы запустить PHP для веба: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Хуже всего с mod_php: там атака срабатывает раньше, чем начинает выполняться код приложения. Ошибка сидит в интерпретаторе, поэтому под угрозой любые сайты на уязвимых версиях: WordPress, Битрикс, Laravel, самописные. Обновлять нужно сам PHP, обновление CMS не поможет.

Почему срочно: Номера CVE утекли 20 октября, и релиз пришлось выпустить на день раньше плана. Первую попытку атаки Amazon заметила на своих ханипотах ещё 17 октября, за четыре дня до исправлений, а теперь сообщает о массовой эксплуатации. Публичные эксплойты тоже уже есть. 22 октября НКЦКИ потребовал от операторов КИИ срочно обновиться, а серверы, которые обновить не успевают, закрыть от внешнего доступа или отключить.

Что делать:

1. Обновиться до 8.5.12, 8.4.27, 8.3.36 или 8.2.35 либо поставить пакет дистрибутива с бэкпортом. После обновления перезапустите все воркеры: php-fpm, Apache. Если PHP работает в контейнере, пересоберите образ приложения на официальном образе php с исправленной версией, например php:8.4.27-fpm или php:8.3.36-apache.
2. Для PHP 8.1 и старше официальных релизов не будет. Для веток 7.4–8.1 команда PHP выложила минимальные патчи, но их нужно собирать из исходников. Остальным остаётся переход на поддерживаемую ветку или помощь вендора с LTS-поддержкой. Учтите, что поддержка PHP 8.2 заканчивается 31 декабря 2026 года.
3. Если обновиться сразу нельзя, примените временные меры из бюллетеня PHP. Они сужают пути атаки, но полностью уязвимости не закрывают.

В php.ini или в настройках пула FPM — только не через ini_set() и не в .user.ini:

; CVE-2026-109619
session.upload_progress.enabled = 0

В пуле PHP-FPM — через php_admin_value, чтобы приложение не смогло переопределить:

; CVE-2026-109618
php_admin_value[memory_limit] = -1

Кроме того, ограничьте размер запроса: post_max_size = 8M для сайтов без загрузки файлов и 32M для сайтов с загрузкой. На PHP 8.5 дополнительно выставьте fatal_error_backtraces = 0. После изменений перезапустите воркеры.

Отключили upload progress — не включайте обратно

23 октября PHP опубликовал ещё одно предупреждение, CVE-2026-115560, тоже связанное с upload progress. Сценарий редкий: приложение должно переключать session.serialize_handler на лету. Исправление выйдет в плановом релизе, а до тех пор session.upload_progress.enabled = 0 лучше оставить.

Подробнее:

• Бюллетень PHP от 21 октября и предупреждение от 23 октября
• Пост PHP Foundation и советы на GitHub: CVE-2026-109618, CVE-2026-109619
• FAQ от Tenable и разбор Rapid7
• Требование НКЦКИ — новость на Хабре

GitLab: две уязвимости с оценкой 10 из 10 за месяц

Что случилось: 12 октября GitLab закрыл CVE-2026-97229 с оценкой 10.0 по CVSS. Через специально составленное регулярное выражение в конфигурации CI/CD можно было выполнить код на сервере без авторизации. Уязвимы были версии начиная с 19.2.

21 октября вышел ещё один внеплановый релиз. Главная уязвимость в нём — CVE-2026-110264, тоже с оценкой 10.0: целочисленное переполнение в компиляторе регулярных выражений снова позволяет выполнить код без авторизации. Затронуты Community и Enterprise Edition всех версий начиная с 7.0, то есть с 2014 года. Тот же релиз закрыл ещё 11 уязвимостей, в том числе захват LDAP-аккаунтов через автопривязку OmniAuth (8.2) и отравление кеша OAuth/OIDC discovery (7.5).

Обновились 12 октября — этого мало

Релиз от 12 октября закрывал другую уязвимость. От CVE-2026-110264 защищает только релиз от 21 октября.

Что делать:

• Self-managed: обновиться до 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 или 18.11.13. Для версий старше 18.11 исправлений нет, нужен переход на поддерживаемую ветку.
• Если версия сильно отстала, сразу на последнюю перейти не получится: GitLab требует проходить обязательные промежуточные версии. Маршрут поможет построить Upgrade Path. Укажите текущую версию, и инструмент покажет, через какие версии идти до последней, какие в них критические изменения и какие функции начнут вести себя иначе.
• GitLab в Docker обновляется сменой тега образа gitlab/gitlab-ce или gitlab/gitlab-ee: 19.5.1-ce.0, 19.5.1-ee.0 и так далее. Указывайте версию явно, без latest, иначе промежуточные версии проскочат.
• На одноузловой установке миграции из этого релиза могут вызвать простой, обновление стоит запланировать. Многоузловые инсталляции обновляются без простоя по стандартной процедуре.
• GitLab.com и GitLab Dedicated уже обновлены, делать ничего не нужно.

Подробнее:

• Релиз 19.5.1 от 21 октября и релиз 19.4.2 от 12 октября
• Как спланировать путь обновления — документация GitLab
• Новость на OpenNet и разбор в «Хакере»

Brotli: уязвимость в декодере, который есть почти везде

Что случилось: CVE-2026-111497 — запись за границу буфера в эталонном декодере google/brotli версий с 1.0.3 по 1.2.0. Специально собранный сжатый поток заставляет декодер писать за пределы выделенной памяти. Последствия — от падения процесса и утечки памяти до выполнения кода. Оценка по CVSS 4.0 — 9.2. Название у уязвимости пока не устоялось: её называют Node2Shell, Broccoli2Shell и HTTP2Shell.

Почему опасно: Распаковка Brotli часто включена по умолчанию, и разработчик об этом может не знать:

• Node.js. Встроенный fetch() сам запрашивает у HTTPS-серверов Brotli и распаковывает ответы. Express 5 и body-parser 2.x распаковывают тела запросов с Content-Encoding: br.
• Python. urllib3, requests, httpx и aiohttp распаковывают Brotli, если в окружении установлен пакет Brotli или brotlicffi. Импортировать его в коде не нужно — достаточно, что он стоит как зависимость.
• Bun, Envoy и Istio с фильтром распаковки Brotli, curl с флагом --compressed.

nginx и Apache по умолчанию входящий Brotli не распаковывают.

Первыми стоит обновить сервисы, которые ходят по адресам от пользователей (вебхуки, превью ссылок, парсеры), и сервисы, которые принимают сжатые тела запросов.

Что делать:

Компонент	Исправленные версии	Образ на Docker Hub
libbrotli (google/brotli)	1.2.1, 1.1.1, 1.0.10	пакет базового образа
Python: Brotli	1.2.1	—
Python: brotlicffi	1.2.1.0	—
Node.js	26.12.1, 24.22.1, 22.23.4	node
Bun	1.4.4	oven/bun
Envoy	1.40.0, 1.39.3, 1.38.6, 1.37.8	envoyproxy/envoy
Istio	1.31.2, 1.30.6, 1.29.9	istio/proxyv2
Go: andybalholm/brotli	v1.2.7	—

• Системный libbrotli обновляется пакетом дистрибутива. Проверьте, вышло ли исправление для вашего базового образа, и пересоберите образ. Копию, вкомпилированную статически, обновит только пересборка. Это касается и исполняемых файлов, собранных bun build --compile.
• В контейнерах указывайте исправленную версию в теге явно или заново скачайте образ с docker pull. Плавающий тег вроде node:24 в локальном кеше может указывать на старую сборку.
• Brotli встроен и в другие проекты: .NET, расширения для PHP и Ruby, ClickHouse, DuckDB. По данным OpenNet, на момент выхода новости не все они выпустили исправления. Следите за бюллетенями своего стека.
• Временно снизить риск можно, отключив распаковку Brotli или отклоняя запросы с Content-Encoding: br на прокси. Обновление это не заменяет.

Подробнее:

• Разбор Wiz с таблицей затронутых продуктов
• Разбор Aikido про Python-библиотеки и автоматическую распаковку
• Новость на OpenNet

Node.js: ещё девять уязвимостей

21 октября вышли Node.js 26.12.1, 24.22.1 и 22.23.4. Кроме Brotli, релиз закрывает ещё девять уязвимостей. Самые важные из них:

• CVE-2026-105483 и CVE-2026-106069 (High). Проверку имени хоста в TLS-сертификате можно обойти, если записать IP-адрес нестандартно: полноширинными цифрами или с ведущими нулями.
• CVE-2026-105482 (High). dns.resolve*() обрезает имя на NUL-байте, поэтому attacker.example\0.trusted.example резолвится как attacker.example. Это опасно для приложений, которые сверяют хост с белым списком, а потом резолвят его.
• CVE-2026-106074 (Medium). Кеш энтропии crypto.randomUUID() и crypto.randomInt() попадает в снапшоты (--build-snapshot) и в одиночные исполняемые файлы (SEA). Все процессы, запущенные из одного снапшота, выдают одинаковые UUID. Одного обновления Node.js здесь мало: снапшоты и SEA, собранные уязвимой версией, нужно пересобрать.

В тот же релиз вошли обновления OpenSSL, c-ares, undici и встроенного набора корневых сертификатов: из него убраны скомпрометированные сертификаты eMudhra (о них ниже). Node.js 20 и старше больше не поддерживаются, исправлений для них не будет.

Исправленные версии уже есть в официальном образе node: 26.12.1, 24.22.1 и 22.23.4.

Подробнее:

• Бюллетень Node.js
• Как найти уязвимые среды выполнения — Qualys
• Обзор на Хабре

eMudhra: ключи удостоверяющего центра подбирались за секунду

Что случилось: 17 октября исследователь, проверявший базу удостоверяющих центров CCADB, обнаружил, что закрытые ключи восьми промежуточных сертификатов индийского УЦ eMudhra восстанавливаются из открытых меньше чем за секунду. Каждый ключ оказался числом меньше 256, а один был буквально равен 4. Шесть из этих сертификатов предназначались для выпуска TLS-сертификатов сайтов, два — для подписи кода. Цепочки вели к корневым сертификатам, которым доверяли Apple, Google, Microsoft и Mozilla. Значит, с такими ключами можно было выпустить валидный сертификат для любого домена и перехватывать HTTPS-трафик.

Реакция: Chrome и Firefox заблокировали сертификаты в день сообщения, Apple — 19 октября, Microsoft — 20-го. Mozilla перестала доверять корневому сертификату, которым были подписаны скомпрометированные промежуточные. Google убирает из Chrome корень emSign ECC Root CA – G3. 22 октября eMudhra объявила, что уходит из глобального бизнеса TLS-сертификатов. Около 30 тысяч клиентских сертификатов придётся перевыпустить. О поддельных сертификатах, выпущенных с этими ключами, пока не сообщалось. Индийские электронные подписи (DSC) и сервис eSign, по заявлению властей Индии, не затронуты.

Что делать: Браузеры и операционные системы уже защищены, достаточно поставить обновления. Сложнее с софтом, у которого своё хранилище корневых сертификатов:

• Серверы и контейнеры. Обновите пакет ca-certificates. Образы пересоберите на свежем базовом образе — debian, ubuntu, alpine — и проверьте, что в нём обновлённый ca-certificates.
• Go. Версии 1.27.3 и 1.26.10 от 19 октября отклоняют цепочки через скомпрометированные сертификаты (CVE-2026-111943). Блокировка находится в стандартной библиотеке, поэтому Go-приложения нужно пересобрать новой версией компилятора. В многоэтапной сборке Docker поднимите версию в образе golang до 1.27.3 или 1.26.10.
• Node.js. Обновлённый встроенный набор корневых сертификатов вошёл в релиз от 21 октября.
• Java, Python certifi, хранилища для mTLS, вшитые в приложения наборы сертификатов. Проверьте каждое отдельно.
• Сайты с сертификатом от eMudhra. Перевыпустите сертификат у другого УЦ.

Не отключайте проверку сертификатов

Если после обновлений что-то перестало открываться по HTTPS, не «чините» это флагами --insecure, InsecureSkipVerify или переменной NODE_TLS_REJECT_UNAUTHORIZED=0. Это ровно та атака, от которой защищает блокировка.

Подробнее:

• Сообщение об инциденте в Mozilla Bugzilla
• Разбор Cloudflare с советами для серверов, контейнеров и mTLS
• Разбор Скотта Хелма и хронология Help Net Security
• Новость на OpenNet

Что ещё вышло в октябре

• nginx 1.30.6 и 1.31.7 (14 октября). Пять уязвимостей, которые проявляются только при определённой конфигурации: alias вместе с rewrite, вычисление строковых выражений с переменными, SSI вместе с AIO, HTTP/3 и ротация ключей TLS session tickets. Сам nginx оценивает их как средние, но если узнали свой конфиг — обновитесь. Список — в бюллетенях nginx. Исправленные версии есть в официальном образе nginx: 1.30.6 (stable) и 1.31.7 или новее (mainline).
• Go 1.27.2 и 1.26.9 (8 октября). Исправления безопасности в crypto/tls, net/http, html/template, net/textproto, os и в команде go. Подробности — в списке релизов Go.
• Collabora Online в Nextcloud (CVE-2026-110447). Выполнение команд ОС через встроенный CODE-сервер — приложение richdocumentscode до версии 26.4.303. Уязвимость уже используют в атаках, чтобы ставить веб-шеллы на серверы Nextcloud. 23 октября CISA внесла её в каталог эксплуатируемых уязвимостей. Обновите приложение до 26.4.303 или удалите его — простого отключения недостаточно (подробнее на BleepingComputer).

Что сделали мы

Данные пользователей Tuna в безопасности, угрозы для них нет. Базовые образы наших серверных приложений уже обновлены. Новые версии tuna-cli и Tuna Desktop выйдут на этой неделе — следите за журналом изменений.

Чек-лист

1. Найдите все установки PHP — боевые, тестовые, локальные — и обновите их. Если нельзя, примените временные меры.
2. Обновите self-managed GitLab до релиза от 21 октября. Если версия старая, постройте маршрут в Upgrade Path.
3. Обновите Node.js, Bun и Python-пакеты Brotli и brotlicffi. Пересоберите контейнерные образы, снапшоты и SEA.
4. Обновите ca-certificates, пересоберите Go-приложения на Go 1.27.3 или 1.26.10 и проверьте свои хранилища сертификатов.
5. Проверьте конфигурацию nginx и обновите Collabora в Nextcloud.
6. Всё, что опубликовано через туннель и нужно не всем, закройте паролем, ключом или белым списком IP.

Оставьте отзыв

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем либо, то пожалуйста оставьте отзыв.

Новости

Анонсы новых функций и статей публикуем в Telegram-канале. Подписывайтесь, чтобы ничего не пропустить.

Помощь

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

• Электронная почта
• Telegram сообщество