CVE-2026-111497 в Brotli: почему командам нужно учитывать декодеры, а не только Node.js

Что на самом деле затрагивает CVE-2026-111497

CVE-2026-111497 — это запись за пределами допустимой области памяти в декодере Google Brotli. Дефект проявляется, когда уязвимое приложение распаковывает некорректный поток, сжатый Brotli: декодер воспринимает недопустимое переключение блока так, будто ему нужно лишь получить дополнительные входные данные, а затем продолжает добавлять байты во внутренний восьмибайтный буфер. В результате входные данные выходят за предназначенную для них границу памяти. В Node.js уязвимый код включён в модуль zlib, поэтому приложение, использующее распаковку Brotli, может подвергаться риску без установки отдельного пакета с названием brotli.

В сообщении о выпуске обновлений безопасности Node.js последствие описано напрямую. Злоумышленник, способный передать приложению данные Brotli, которые оно распаковывает с помощью node:zlib, может повредить память процесса, что потенциально приведёт к сбою, раскрытию содержимого памяти процесса или удалённому выполнению кода. В выпуске уязвимости присвоен высокий уровень серьёзности; затронутыми указаны ветки Node.js 26.x, 24.x и 22.x. Поэтому владельцу важно выяснить не только «Какая версия Node.js установлена?», но и «Можно ли заставить этот работающий процесс распаковать данные Brotli, поступившие от злоумышленника или другой ненадёжной системы?»

Это условие важно, поскольку уязвимость не означает, что скомпрометирована каждая машина, на которой есть библиотека с поддержкой Brotli. В бюллетене Red Hat та же проблема описана как повреждение памяти при обработке приложением специально сформированного потока с ненадёжными входными данными Brotli. Среди возможных последствий перечислены раскрытие информации, отказ в обслуживании и выполнение произвольного кода; при этом отмечается, что среды, где ни одно приложение не распаковывает данные Brotli из ненадёжных источников, на практике не затронуты. Для эксплуатации нужен специально сформированный некорректный поток; обычный правильно сформированный результат нормального кодировщика проблему не вызывает.

Именно расположение декодера делает задачу инвентаризации легко недооценённой. Brotli используется для HTTP-заголовка Content-Encoding: br, но также может присутствовать в виде отдельной библиотеки, Python-привязок, внутри браузеров и других клиентов либо как часть более крупного продукта. Red Hat указывает, что библиотека доступна через такие пакеты, как brotli, и Python-привязки Brotli, а также отмечает, что Node.js включает её в состав zlib. В том же бюллетене упоминаются встроенные копии в Firefox, Thunderbird и многоуровневых продуктах. Инвентаризация программного обеспечения, учитывающая только приложения верхнего уровня, может поэтому показывать обычный на вид сервис, скрывая нативный декодер, который фактически разбирает поступающие извне сжатые байты.

По этой же причине идентификатор CVE следует отслеживать на двух уровнях. В записи CVE названа базовая уязвимость, а в уведомлении о среде выполнения или продукте указано, как этот компонент упакован, исправлен или обновлён с обратным переносом исправления в конкретном дистрибутиве. Обновление Node.js может устранить проблему в копии, включённой в Node.js, но само по себе ничего не говорит об отдельной библиотеке Brotli, Python-привязке, сборке браузера, образе устройства или другом продукте со своей встроенной копией. И наоборот, обнаружение CVE сканером не доказывает, что уязвимый путь декодирования доступен из ненадёжного источника.

Поэтому первая полезная классификация должна сочетать компонент и путь поступления данных. Зафиксируйте, откуда Brotli попадает в систему, какому продукту или среде выполнения принадлежит используемая копия и обрабатывает ли она ответы сети, HTTP-запросы, загруженные файлы, удалённые артефакты или другой контент, контролируемый за пределами доверенной границы. В Node.js такая проверка должна охватывать использование API распаковки Brotli и поведение, при котором ответы br декодируются автоматически. Для других продуктов обращайтесь к уведомлению поставщика о компоненте и примечаниям к выпуску, а не предполагайте, что имя пакета или версия приложения однозначно соответствуют уязвимому бинарному файлу.

Такой подход позволяет отделить подтверждённые сведения от предположений об эксплуатации. Доступные рекомендации по безопасности подтверждают наличие проблемы с безопасностью памяти, которая может иметь серьёзные последствия, если уязвимые процессы декодирования обрабатывают данные под контролем злоумышленника. Но они не подтверждают, что каждая установка подвержена риску одинаково или что уже идёт широкая подтверждённая кампания эксплуатации. Обоснованный приоритет — найти декодеры, которые одновременно уязвимы и доступны для обращения, а затем проверить исправленный выпуск того продукта, в состав которого они действительно входят. Это основа инвентаризации зависимостей, необходимой на следующем этапе.

Почему исправление Node.js не закрывает всю область воздействия

Обновить Node.js необходимо, если приложение использует затронутую ветку выпусков, но этого недостаточно для устранения CVE-2026-111497. Уязвимый код находится в декодере Google Brotli на языке C, и Cisco отмечает, что этот компонент часто входит в состав программного обеспечения, не связанного напрямую с Node.js, или подключается к нему. Поэтому продукт может унаследовать ту же ошибку, не выглядеть в инвентаризации как приложение Node.js и не предоставлять операторам отдельный пакет Brotli для обновления. Важно спрашивать не только: «Какие версии Node.js мы используем?» — но и: «В каких продуктах есть декодер Brotli и какие из них могут заставить его распаковывать данные, предоставленные другой стороной?»

Рекомендации Cisco от 5 ноября показывают, почему это различие имеет практическое значение. Cisco проверяет продукты по отдельности, а не считает весь портфель одинаково затронутым. В таблице приоритетных продуктов указаны разные результаты: Catalyst SD-WAN Software, Identity Services Engine, IOS XE Software, Secure Firewall Management Center и Secure Firewall Threat Defense признаны незатронутыми, тогда как IOS XR Software и Secure Firewall Adaptive Security Appliance Software всё ещё расследуются. Для NX-OS Software предлагается обращаться к другим таблицам воздействия и исправлений. Такая разница показывает: оценка на уровне поставщика зависит от того, как конкретный продукт включает общий компонент в свой состав и использует его, а не просто от того, выпускает ли поставщик программное обеспечение, связанное с Node.js или Brotli.

В тех же рекомендациях перечислены продукты, которые активно расследуются, в самых разных категориях: наблюдаемость приложений, безопасность сетей и контента, управление сетями, маршрутизация и коммутация, унифицированные вычислительные системы, видео и совместная работа, беспроводные сервисы, а также размещённые Cisco сервисы. Для владельцев активов такой охват важен, поскольку затронутый путь выполнения может находиться внутри устройства, контроллера, виртуального устройства, служебной утилиты конечной точки или сервиса, подключённого к облаку. Название продукта в CMDB может описывать его бизнес-функцию — например, менеджер межсетевого экрана, контроллер или платформа для совместной работы, — тогда как уязвимый декодер скрывается в среде выполнения, встроенной библиотеке или компоненте сервиса. Поэтому обычный реестр приложений может быть точным на уровне продукта и всё равно не показать код, обрабатывающий сжатые входные данные.

Таблица исправленных выпусков Cisco также показывает, почему слово «исправлено» нельзя считать единым статусом для всего портфеля. В рекомендациях указаны разные пути устранения проблемы для разных продуктов: для Duo Network Gateway приведён выпуск 3.4.2, для Duo Authentication Proxy Local Manager for Windows — 6.8.1, а для Catalyst Center — 3.4.1. Для других записей номер выпуска ещё предстоит определить либо целевой выпуск помечен как ожидающий. Поэтому организации нужно сопоставить точный продукт, форму развёртывания и используемую ветку выпуска со статусом поставщика и исправленной версией. Установка обновлённого пакета Node.js на хосте сборки не доказывает, что образ устройства, встроенный сервис или продукт с отдельным циклом сопровождения получили соответствующее исправление.

В самом потоке данных есть ещё одна ловушка при инвентаризации. Сервис может не предоставлять пользователю функцию, связанную с Brotli, но всё равно декодировать Brotli при обработке HTTP-контента или другого потока, поступающего извне. Red Hat рассматривает наличие уязвимости с точки зрения получения декодером недоверенных данных Brotli и приводит такие примеры, как HTTP-обмен с использованием Content-Encoding: br, API распаковки Node.js и приложения, напрямую вызывающие библиотеку Brotli. Это более полезная граница анализа, чем одно лишь наличие имени пакета. Командам следует выяснить, может ли компонент получать сжатые байты, контролируемые атакующим, через какой слушатель или интеграцию это происходит и содержит ли работающий продукт — а не только манифест исходных зависимостей — уязвимый декодер.

Именно поэтому чистое сканирование зависимостей может создать ложное ощущение безопасности. В lock-файле может быть указана зависимость приложения, но отсутствовать библиотека, скомпилированная в бинарный файл поставщика. И наоборот, инвентаризация пакетов хоста может показать системный пакет Brotli, хотя фактически используемый сервис работает с отдельной копией внутри собственного образа. В рекомендациях Cisco администраторам предлагается обращаться к записям об ошибках для конкретных продуктов и исправленным выпускам ПО, а Red Hat отмечает, что многоуровневые продукты и контейнеры могут зависеть от обновлённых базовых пакетов. Поэтому практической единицей устранения уязвимости должен быть развёрнутый продукт и его исполняемый путь декодирования. Обновление Node.js закрывает компонент Node.js там, где он установлен; оно автоматически не устраняет уязвимость во всех продуктах Cisco, устройствах, контейнерах и сервисах, где может использоваться тот же декодер Brotli.

Важная для защиты инвентаризация

Полезно спрашивать не просто, установлен ли на сервере Node.js. Нужно определить, какие компоненты умеют декодировать данные Brotli, где они работают и может ли недоверенная сторона влиять на поступающие данные. Декодер может входить в состав Node.js, быть библиотекой Brotli, используемой через привязки Python, SDK, встроенным в приложение, образом контейнера или компонентом устройства, который не даёт операционной команде очевидного представления на уровне пакетов. Поэтому стандартная инвентаризация ПО может выявить приложение, но пропустить библиотеку, выполняющую нужный разбор данных.

Начните с инвентаризации сред исполнения, а не с поиска одного имени пакета. Зафиксируйте установки Node.js и приложения, которые встраивают его или зависят от него. Проверьте сервисы, использующие поддержку Brotli через привязки Python или другие языковые интеграции, а также включённые в состав SDK, зависимости которых сопровождаются отдельно от операционной системы хоста. Расширьте проверку на контейнеры, базовые образы, артефакты сборки и устройства поставщиков. Для каждого объекта укажите продукт и выпуск, версию образа или прошивки, процесс, загружающий декодер, и ответственного за обновление. Цель — связать абстрактную зависимость с бинарным файлом, который действительно будет обрабатывать данные.

Следующее важное различие — степень доступности извне. Само наличие декодера в системе ещё не означает, что он доступен для атаки. Составьте карту путей, по которым каждый сервис получает сжатый контент: публичные HTTP-запросы, загрузки с удалённых устройств, требующие аутентификации, сообщения от внешних систем, трафик через прокси, каналы поставки пакетов или артефактов и административные интерфейсы. Также учтите сервисы, распаковывающие данные косвенно, например шлюзы, брокеры, API-компоненты и фоновые обработчики приложений. На этой схеме достаточно описать поток данных на высоком уровне; проверять уязвимость или отправлять специально сформированный ввод не требуется. Важно установить, может ли атакующий, недоверенный клиент или вышестоящая система управлять содержимым, которое достигает пути декодирования Brotli.

Практическую инвентаризацию для каждой среды исполнения или продукта можно построить вокруг четырёх вопросов:

• Что декодирует Brotli? Определите задействованные среду исполнения, библиотеку, привязку, SDK, компонент устройства, слой контейнера или реализацию сервиса.
• Где это работает? Зафиксируйте хосты, контейнеры, образы, прошивки, среды развёртывания, а также процесс или продукт, который загружает компонент.
• Кто может предоставить входные данные? Укажите, поступают ли сжатые данные из публичной сети, от партнёра, пользователя, внутреннего сервиса или контролируемого источника.
• Какой выпуск поставщика устраняет проблему? Сопоставьте обнаруженный продукт или компонент с применимым исправленным выпуском Node.js, поставщика продукта или дистрибьютора, поставляющего пакет.

Последнее сопоставление нужно выполнять на уровне развернутого продукта. Обновление Node.js может закрыть проблему в среде выполнения одного сервиса, но оставить без изменений отдельный программно-аппаратный комплекс, SDK или скопированную библиотеку. И наоборот, поставщик может выпустить обновление продукта с исправленным декодером, хотя в отчете о пакетах приложения зависимость по-прежнему будет выглядеть так же. Авторитетным источником служат рекомендации поставщика и исправленный релиз для конкретного затронутого продукта; после этого нужно подтвердить, что именно установлено в работающей среде.

С контейнерами требуется особая осторожность: обновление lock-файла или манифеста пакетов не меняет уже собранный образ. Проверьте разрешение зависимостей, использованное на этапе сборки, но также изучите получившийся образ или установленную в нем среду выполнения, а затем разверните ее заново. Образы, пересобранные на основе неизмененного базового слоя, могут снова содержать тот же уязвимый компонент, даже если исходный код приложения не менялся. Когда исправленный образ готов, замените работающую нагрузку, не полагаясь на то, что последующая сборка изменит существующие контейнеры на месте. Храните сведения о старом образе и связанном с ним развертывании так, чтобы можно было определить, какие экземпляры еще требуют внимания.

Тот же принцип относится к долгоживущим процессам и программно-аппаратным комплексам. Обновление пакета может не повлиять на процесс, уже загрузивший старую библиотеку, а обновление устройства может требовать документированного перезапуска или активации прошивки, прежде чем начнет использоваться исправленный компонент. Считайте требования к перезапуску частью записи о remediation: укажите примененное обновление, перезапущенный экземпляр или устройство, время активации нового процесса или прошивки и доказательства, использованные для проверки. Если у продукта нет независимо доступного инвентаря пакетов, опирайтесь на соответствие версий в релизах поставщика и операционную проверку, а не делайте вывод о безопасности по нерелевантной версии приложения.

Такой инвентарь помогает расставлять приоритеты, не превращая каждый случай в чрезвычайную ситуацию. В первую очередь обрабатывайте декодеры, доступные через сервисы, обращенные к интернету, или через контент, поступающий извне; затем — общие шлюзы, критически важные устройства и нагрузки, чьи результаты потребляют другие системы. Для изолированных инструментов разработки или сервисов, декодирующих только контролируемые данные, оценка риска может быть иной, но их все равно следует учитывать, пока ответственная команда не сопоставит их с применимыми рекомендациями поставщика. Получившаяся карта должна быть рабочим списком remediation: для каждой записи указаны владелец продукта, оценка доступности, сопоставление с исправленным релизом и шаг проверки, привязанный к фактически работающему компоненту.

Как исправить, ограничить риск и проверить результат без догадок

Обоснованный ответ начинается с триажа, а не с предположения, что любая система с Node.js подвержена риску в одинаковой степени. Расставьте декодеры по тому, каким образом до них доходит сжатое содержимое: сначала сервисы и шлюзы, доступные из интернета, затем приложения, принимающие загрузки или сообщения партнеров, и после них внутренние сервисы, получающие данные из менее доверенных сетей. Главный вопрос не в том, присутствует ли где-то в инвентаре хоста уязвимый релиз. Нужно выяснить, является ли этот релиз компонентом, который в работающем процессе или продукте действительно декодирует данные Brotli, контролируемые атакующим.

Для каждого кандидата зафиксируйте ответственную команду, продукт и его релиз, источник среды выполнения или библиотеки, форму развертывания и путь входных данных, запускающий декодирование. Включите установки Node.js, приложения со встроенным Node.js, отдельные библиотеки Brotli, языковые привязки, например интеграции с Python, SDK, контейнеры и программно-аппаратные комплексы. В рекомендациях поставщика для разных релизов одного продукта могут быть указаны разные статусы, поэтому проверяйте точную версию продукта, а не делайте вывод о подверженности на основании общего заявления о базовой библиотеке. Рекомендации Cisco показывают, почему это важно: одна и та же исходная проблема может встречаться в разных продуктах с разным состоянием remediation.

Предпочтительный способ устранения проблемы — документированное обновление от поставщика компонента или продукта. Если декодер поставляется через Node.js, используйте релиз, указанный в рекомендациях Node.js по безопасности. Если он встроен в устройство, SDK или приложение, следуйте инструкциям поставщика по выпуску и развертыванию. Не считайте замену зависимости верхнего уровня доказательством того, что все встроенные копии исчезли. Lock-файл описывает разрешение зависимостей при сборке, но в развернутом образе всё ещё могут находиться более старая транзитивная версия пакета, поставляемый вместе с продуктом исходный код, нативный модуль или отдельный слой среды выполнения. Завершенность устранения проблемы определяется артефактом, который выполняется.

Временные меры сдерживания должны быть узкими по охвату, задокументированными и обратимыми. Если это возможно с операционной точки зрения, сократите или приостановите конкретный маршрут, принимающий ненадежный контент Brotli, разместите его за утвержденным фильтром или шлюзом либо выведите уязвимый компонент из эксплуатации на время подготовки исправления. Эти меры не заменяют установку исправления; команды не должны придумывать их на основе предположений о поведении сжатия в продукте. Используйте только меры, документированные ответственным поставщиком или проверенные в рамках процессов управления изменениями и безопасности организации. Зафиксируйте время включения контроля, затрагиваемую им функцию и ответственного за его отключение после устранения проблемы.

Детали развертывания — часть устранения уязвимости. Процесс, загружающий среду выполнения или общую библиотеку при запуске, может продолжать использовать старый декодер, пока его не перезапустят. Образ контейнера можно пересобрать правильно, но существующие реплики всё ещё могут обслуживать трафик из предыдущего образа. После поэтапного обновления убедитесь, что старые поды, рабочие процессы, сайдкары и узлы устройства остановлены или перезапущены, а отказоустойчивое переключение и автомасштабирование не смогут снова ввести в работу замененный артефакт. Для систем за пределами основного конвейера приложения внесите перезапуски сервисов или перезагрузки устройств в запись об изменении, соблюдая документированную процедуру продукта.

Проверка должна объединять свидетельства о программном обеспечении и данные об экспозиции. Определите точный запущенный бинарный файл, среду выполнения, дайджест образа, манифест пакета или сборку поставщика, обслуживающую путь декодирования, а затем сравните их с исправленным релизом, указанным в применимой записи CVE, релизе Node.js или уведомлении о безопасности продукта. Убедитесь, что соответствующий процесс перезапущен и ожидаемые экземпляры работают с новым артефактом; одного исходного репозитория, кэша пакетов или результата CI недостаточно. Повторно проверьте дубликаты в неактивных образах, резервных конфигурациях, тестовых средах, подключенных к производственным каналам, и устройствах, которые обслуживает другая команда.

В записи следует указать, что именно было и не было обнаружено: найденные затронутые версии, развернутые исправленные версии, маршруты, принимающие ненадежные сжатые данные, временные средства контроля и релевантные результаты мониторинга. Приведенные источники устанавливают контекст уязвимости и ее устранения, но не подтверждают широкомасштабную эксплуатацию. Это различие помогает выстроить соразмерную реакцию: быстро расставить приоритеты для доступных извне декодеров и проверить исправления, не утверждая, что была атакована каждая система, использующая Brotli, или что проблема устранена лишь потому, что изменился файл зависимостей. Итогом должна стать работающая инвентаризированная служба, чей декодер привязан к документированному исправленному релизу, а путь развертывания не способен незаметно вернуть уязвимый компонент.