В библиотеке Apache HttpComponents Client, одной из самых распространённых в Java-экосистеме, обнаружена уязвимость, позволяющая злоумышленнику выдать себя за доверенный сервер. Проблема затрагивает асинхронную версию клиента и вызвана некорректной проверкой имени хоста при установке TLS-соединения. Уязвимости присвоен идентификатор CVE-2026-71290, оценка по шкале CVSS v3.1 составляет 9,1 балла из десяти. Это максимальный уровень опасности, поскольку атака выполняется удалённо, не требует аутентификации и участия пользователя.
Уязвимость CVE-2026-71290
Apache HttpComponents Client используют для обращения к веб-сервисам, интеграции систем, реализации облачных и корпоративных приложений. Асинхронная версия рассчитана на сценарии с большим количеством одновременных запросов, когда важна высокая пропускная способность и низкая задержка. Она работает в неблокирующем режиме и позволяет эффективно использовать ресурсы при интенсивном обмене данными. Однако именно в этой реализации обнаружилась ошибка, которая сводит на нет ожидания разработчиков относительно защиты соединений.
Для защиты каналов связи в клиенте предусмотрены механизмы проверки сертификатов. Разработчик может включить встроенную политику проверки имени хоста, которая в классической версии гарантирует, что сертификат сервера соответствует запрошенному домену. В асинхронной реализации эта политика не применяется из-за ошибки в обработке параметров TLS-соединения. Настройка остаётся активной, но фактически игнорируется, поэтому клиент не выполняет сверку имени хоста с сертификатом.
В результате клиент доверяет любому действующему сертификату, выпущенному доверенным центром сертификации, даже если он выдан для другого домена. Это создаёт возможность для атаки "человек посередине". Злоумышленник, перехватывающий трафик между клиентом и сервером, может предъявить собственный сертификат или сертификат, приобретённый для своего домена, и клиент установит соединение, полагая, что общается с легитимным сервером. При этом приложение не получает никаких предупреждений о несоответствии имени хоста.
Успешная атака позволяет не только читать данные, передаваемые по HTTPS, но и изменять их. Злоумышленник может подменять ответы API, внедрять вредоносное содержимое в загружаемые страницы или перехватывать учётные данные, передаваемые в запросах. В зависимости от того, какие функции выполняет приложение, последствия могут включать кражу конфиденциальной информации, нарушение работы сервисов и компрометацию учётных записей. Особенно опасно это для систем, которые обмениваются данными с внешними сервисами или автоматически обрабатывают входящие ответы.
Для эксплуатации уязвимости необходимо находиться на пути прохождения сетевого трафика. Это достигается через скомпрометированное сетевое устройство, вредоносную точку доступа Wi-Fi, подмену DNS-записей или другие методы перенаправления. Сложность атаки низкая, а необходимости во взаимодействии с пользователем нет, поскольку жертва обычно не подозревает о вмешательстве в канал связи. Атакующему достаточно один раз оказаться между клиентом и сервером, чтобы перехватывать или изменять все последующие сообщения.
По классификации CWE-295 проблема относится к некорректной проверке сертификата. Вектор атаки в стандарте CVSS выглядит следующим образом: сетевая атака с низкой сложностью, без привилегий и без взаимодействия с пользователем. Уровень влияния на конфиденциальность и целостность оценивается как высокий, при этом доступность затронута не существенно. Это соответствует сценарию, когда атакующий может полностью контролировать поток данных между клиентом и сервером, но не может напрямую нарушить работу службы.
Уязвимость присутствует в версиях Apache HttpComponents Client с 5.4 по 5.6.3 включительно. Исправление вышло в версии 5.6.4. Важно отметить, что классическая версия HttpClient не затрагивается проблемой. Поэтому организациям не следует считать себя уязвимыми только потому, что в проекте установлена зависимость от Apache HttpComponents. Необходимо проверить, используется ли асинхронный клиент и включена ли встроенная проверка имени хоста. В крупных проектах такая проверка усложняется тем, что зависимость может подключаться не напрямую, а через библиотеки и фреймворки, которые незаметно используют асинхронный HttpClient внутри себя.
Для определения фактической подверженности риску нужно проанализировать конфигурацию сборки. В проектах на Maven или Gradle можно изучить дерево зависимостей и выяснить, какая версия HttpComponents подключается и какой модуль её вызывает. Если асинхронный клиент не используется напрямую, но присутствует в составе фреймворка, необходимо убедиться, что тот не активирует уязвимую функцию. Помочь может также поиск в коде обращений к асинхронным классам клиента и настройкам политики проверки хоста.
Наибольший риск уязвимость представляет для API-клиентов, облачных сервисов, микросервисов и корпоративных интеграций, которые применяют асинхронный HttpClient для высоконагруженных HTTPS-соединений. В таких средах через клиент часто передаются конфиденциальные данные: ключи доступа, финансовые сведения, внутренние документы и административные команды. Компрометация канала связи может привести к масштабной утечке данных или нарушению целостности бизнес-процессов, поскольку атакующий получит возможность изменять ответы сервисов и внедрять ложную информацию.
Разработчикам рекомендуется обновить Apache HttpComponents Client до версии 5.6.4 или более поздней. Командам безопасности необходимо выявить все прямые и транзитивные зависимости, включая библиотеки и фреймворки, которые могут подключать асинхронный клиент косвенно. Следует проверить приложения, работающие из публичных сетей, поскольку они более доступны для перехвата трафика. Не стоит забывать и о внутренних системах, где атакующий может получить доступ к сети через менее защищённые сегменты.
До установки обновления важно защитить интернет-сервисы и рабочие нагрузки, обрабатывающие учётные данные, финансовую информацию, внутренние API и привилегированный административный трафик. Дополнительные меры включают усиление контроля за перехватом TLS-трафика, мониторинг аномалий в сертификатах и ограничение возможности несанкционированного изменения сетевых маршрутов. Однако все эти меры носят временный характер, единственным надёжным решением остаётся обновление.
После обновления рекомендуется провести тестовые сценарии, которые подтвердят, что асинхронный клиент отклоняет сертификаты с несовпадающим именем хоста. Также стоит убедиться, что все зависимые библиотеки используют исправленную версию, поскольку менеджеры зависимостей могут автоматически подтягивать более старые версии, если они явно указаны в конфигурации. Проверка должна затрагивать как внутренние интеграции, так и внешние API, с которыми обменивается приложение.
Ошибки в реализации проверки сертификатов периодически появляются даже в зрелых проектах. Данная проблема показывает, что наличие механизма безопасности в коде не гарантирует его фактическую работу во всех режимах. Поэтому при использовании критически важных библиотек необходимо проверять их поведение в тех конфигурациях, которые применяются в реальном продукте, а не только полагаться на документацию и декларируемые функции.
Ссылки
- https://lists.apache.org/thread/bhf7g2zwpom2ohvwjjjlonc93br2s8vq
- https://nvd.nist.gov/vuln/detail/CVE-2026-71290
