Контрабанда HTTP-запросов в Netty вышла за пределы фреймворка: под угрозой десятки продуктов Red Hat

Ошибка в обработке HTTP-запросов в популярном Java-фреймворке Netty открывает возможность для атак, известных как контрабанда HTTP-запросов. Уязвимость BDU:2026-11291 (CVE-2026-42581) затрагивает не только сам Netty, но и широкий перечень продуктов Red Hat - от серверов приложений до платформ контейнеризации. Разработчики уже выпустили исправления в актуальных версиях, а эксплойт доступен в открытых источниках.

Детали уязвимости

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

Согласно бюллетеню, опубликованному в Банке данных угроз безопасности информации (BDU), уязвимость позволяет удаленному нарушителю вызвать отказ в обслуживании. При этом базовая оценка CVSS 3.1 составляет 9,8 балла, а вектор показывает высокое воздействие на конфиденциальность, целостность и доступность. Это означает, что в зависимости от сценария эксплуатации последствия могут оказаться шире формального описания, вплоть до вмешательства в передаваемые данные. Официальное подтверждение от производителя, впрочем, акцентирует внимание именно на риске недоступности сервисов.

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

Масштаб проблемы усиливается за счет того, что Netty широко используется как базовый компонент множества корпоративных продуктов Red Hat. Среди затронутых - JBoss Enterprise Application Platform, Red Hat Single Sign-On, Red Hat AMQ Broker, Data Grid, OpenShift Serverless, Red Hat Fuse, Streams for Apache Kafka и другие. Фактически уязвимость распространяется на прикладное ПО информационных систем, сетевые средства и даже операционную систему Red Hat Enterprise Linux AI. Одна ошибка в популярной библиотеке создала риски для целой экосистемы продуктов, что делает проблему особенно серьезной для крупных организаций, использующих стек Red Hat.

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

Для Netty исправление вышло в версиях 4.1.133.Final и 4.2.13.Final. Всем проектам, использующим более ранние выпуски, необходимо обновить зависимость до указанных или более новых версий. Что касается продуктов Red Hat, компания подготовила обновления для всех перечисленных компонентов. Ссылки на рекомендации приведены в бюллетене BDU и на портале Red Hat Customer Portal. Установка патчей - основной способ устранения уязвимости, временных обходных мер не заявлено.

Отдельного внимания заслуживает тот факт, что CVE-2026-42581 уже фигурирует в открытых источниках, а значит, у злоумышленников есть рабочие инструменты для эксплуатации. Для организаций, использующих продукты Red Hat в критической инфраструктуре, рекомендуется в первую очередь обновить компоненты, напрямую связанные с обработкой внешнего трафика: серверы приложений, брокеры сообщений и системы единого входа. Также стоит проверить, не используются ли уязвимые версии Netty внутри собственных Java-приложений, даже если они не входят в официальный перечень Red Hat. Проверка должна охватывать не только прямые зависимости, но и транзитивные - библиотеки, которые подтягиваются в проект опосредованно. Сделать это можно с помощью инструментов анализа состава программного обеспечения, формирующих перечень используемых компонентов.

Эта уязвимость привлекает внимание к проблеме безопасности цепочки поставок в Java-экосистеме. Один неверный парсер HTTP-запросов в популярной библиотеке создает риски для десятков независимых продуктов. Подобные случаи подчеркивают важность регулярного обновления зависимостей и мониторинга бюллетеней безопасности. Для данной ситуации главное - оперативно установить исправления, так как эксплойт уже в публичном доступе, а уязвимость подтверждена и устранена производителем.