Критическая уязвимость HTTP2Shell в декодере Brotli позволяет атакующему испортить память процесса, извлечь чувствительные данные и, в отдельных сценариях, добиться удалённого выполнения кода. Проблема затрагивает распространённые версии библиотеки, встроенной в Node.js и используемой Python-клиентами и .NET: российским командам стоит не откладывать инвентаризацию зависимостей и перезапуск сервисов после обновления.
Уязвимость получила идентификатор CVE-2026-111497 и несколько имён: HTTP2Shell, Broccoli2Shell и Node2Shell. Как сообщает BleepingComputer, сначала её обнаружили в контексте Node.js, а затем выяснилось, что ошибка находится в C-декодере Brotli и способна затронуть ПО в разных экосистемах. Под риск попали Brotli 1.0.3–1.0.9, 1.1.0 и 1.2.0.
Brotli — алгоритм сжатия с открытым исходным кодом, который поддерживает Google. Его обычно встречают в веб-стеке: сервер сжимает ответ, клиент распаковывает его и экономит трафик. Поэтому название HTTP2Shell немного сбивает с толку. Ошибка не привязана к HTTP/2: уязвимой становится любая программа, которая передаёт декодеру Brotli данные, контролируемые атакующим.
Технически это переполнение буфера в потоковом декодере. Специально подготовленный сжатый поток вызывает некорректное переключение блока. Вместо окончательной ошибки формата декодер воспринимает ситуацию как просьбу дождаться очередной порции данных и продолжает дописывать байты во внутренний буфер размером восемь байт. В результате запись выходит за его границы и повреждает соседние области памяти. Последствия зависят от процесса и окружения: от аварийного завершения до утечки памяти и выполнения кода.
Опасен не только входящий трафик
Типичный сценарий для серверов очевиден: злоумышленник отправляет приложению запрос со злонамеренно сжатым телом, а приложение его распаковывает. Но есть и менее заметный путь — исходящий запрос. Достаточно, чтобы сервис по URL атакующего получил Brotli-сжатый HTTP-ответ и автоматически декодировал его. Поэтому ограничение входящих запросов с Brotli не закрывает проблему для бэкендов, краулеров, интеграционных сервисов и иных приложений, которые ходят во внешние API.
Особенно внимательно стоит проверить Python-зависимости. В списке потенциально затронутых клиентов названы urllib3 с дополнительной поддержкой Brotli, requests, httpx и aiohttp в конфигурации speedups — при условии, что они используют уязвимый декодер. Наличие одного из этих пакетов ещё не доказывает риск: важно установить, какая именно библиотека Brotli попала в окружение, как она поставляется и обрабатывает ли приложение сжатые данные от недоверенных источников.
Microsoft 26 октября выпустила экстренное обновление .NET и предупредила, что успешная эксплуатация может привести к повышению привилегий на системах с уязвимой версией платформы. Node.js и Google выпустили стабильные исправления 21 октября, публично раскрыли проблему на следующий день, а обновлённые пакеты на PyPI появились 23 октября. Уже опубликованы proof-of-concept для варианта Node2Shell; сведений об атаках в реальной среде на момент публикации нет. Это, однако, слабое утешение для бага с готовыми демонстрационными эксплойтами.
Безопасными версиями названы Google Brotli 1.0.10, 1.1.1 и 1.2.1; Node.js 22.23.4, 24.22.1 и 26.12.1; Python Brotli 1.2.1 и brotlicffi 1.2.1.0. Командам полезно проверить не только системные пакеты, но и vendored-копии библиотек в зависимостях, образах контейнеров и сборках. Обновление системной Brotli-библиотеки само по себе не исправит Node.js-приложение, если рантайм или пакет принёс собственную копию декодера.
Что делать до и после патча
Приоритетный план короткий: обновить рантаймы и пакеты до исправленных версий, пересобрать контейнерные образы, развернуть их и обязательно перезапустить процессы. Один только новый пакет в репозитории не меняет код, уже загруженный работающим сервисом в память. Если обновление пока невозможно, временная мера для Python-приложений — убрать поддержку Brotli. Для сервисов, принимающих сжатые запросы, можно блокировать Brotli на прокси или межсетевом экране, но это лишь частичное снижение риска: сценарий с вредоносным ответом остаётся.
Уязвимость HTTP2Shell хорошо показывает цену незаметных низкоуровневых зависимостей. Brotli редко фигурирует в планах разработки, зато живёт на границе сети, браузеров, API-клиентов и серверных рантаймов. В ближайшие дни ключевым вопросом для компаний станет не только скорость установки патча, но и способность быстро ответить на более неприятный вопрос: где именно в их инфраструктуре вообще происходит распаковка недоверенных данных.
