В мире информационной безопасности открытый исходный код - это палка о двух концах. С одной стороны, он способствует прозрачности и ускорению разработки, с другой - любая ошибка в популярной библиотеке может поставить под угрозу тысячи организаций. Недавний инцидент с фреймворком Pingora от Cloudflare наглядно демонстрирует эту дилемму. Исследователь в области кибербезопасности обнаружил в этом высокопроизводительном решении для прокси-серверов ряд критических уязвимостей, которые позволяют злоумышленникам обходить защитные механизмы и подменять легитимный контент. Между тем, важно подчеркнуть, что сама инфраструктура Cloudflare и трафик её клиентов не были затронуты, поскольку компания использует собственную, модифицированную версию. Однако для всех, кто развернул Pingora как самостоятельный прокси на периметре сети, актуальна срочная необходимость в обновлении.
Детали уязвимости
Суть проблемы заключается в трёх уязвимостях, получивших идентификаторы CVE-2026-2833, CVE-2026-2835 и CVE-2026-2836. Все они затрагивают изолированные развертывания Pingora, которые используются в качестве входных прокси-серверов, обращенных к интернету. Основной вектор атак связан с техникой, известной как «контрабанда HTTP-запросов». Этот метод основан на создании рассинхронизации между фронтенд-прокси и бэкенд-сервером относительно границ отдельных запросов. Проще говоря, злоумышленник может «спрятать» вредоносный запрос внутри легитимного. Когда прокси передает данные далее, бэкенд обрабатывает скрытую часть как отдельный, новый запрос, часто от лица другого, ничего не подозревающего пользователя. Это открывает дорогу для обхода правил межсетевого экрана приложений, похищения сессий и многого другого.
Первая уязвимость была связана с преждевременным обновлением протокола. Когда атакующий отправлял запрос с заголовком "Upgrade", Pingora немедленно переключался в режим прямой передачи данных, не дожидаясь подтверждения от бэкенд-сервера в виде стандартного ответа «101 Switching Protocols». Этой оплошностью можно было воспользоваться, отправив сразу после запроса на обновление второй, сконструированный запрос. Pingora слепо пересылал его на бэкенд, минуя все проверки безопасности, реализованные на уровне прокси. Вторая проблема заключалась в неправильной обработке устаревших запросов по протоколу HTTP/1.0. Согласно строгим стандартам, запрос, содержащий одновременно противоречащие друг другу заголовки "Content-Length" и "Transfer-Encoding", должен быть отклонён. Однако Pingora проявлял опасную снисходительность, трактуя тело такого запроса как завершённое при закрытии соединения. Это позволяло атакующему присоединить к концу запроса частичные заголовки нового HTTP-сообщения, что и вызывало критическую рассинхронизацию с сервером приложения.
Третья уязвимость, хотя и не являлась прямым вектором для контрабанды запросов, представляла не меньшую опасность для пользователей. Речь идёт о механизме формирования ключей кэша по умолчанию. Исходная реализация учитывала только путь URL, полностью игнорируя заголовок хоста и схему протокола. Такой подход создавал риск коллизий в кэше для разных веб-сайтов, использующих одинаковые пути. Этим мог воспользоваться злоумышленник для отравления кэша, то есть подмены легитимного контента на вредоносный. В результате посетители вполне добропорядочного сайта могли получить, например, фишинговую страницу или скрипт для кражи данных, хранящийся в памяти самого прокси-сервера.
Последствия эксплуатации этих недостатков для организаций, использующих уязвимые версии Pingora, могут быть крайне серьёзными. Успешная атака позволяет не только обходить правила безопасности на уровне прокси, включая межсетевые экраны веб-приложений, но и перехватывать активные пользовательские сессии, похищая учётные данные. Кроме того, отравление кэша превращает инфраструктуру самой компании в инструмент для распространения вредоносной нагрузки среди её клиентов или сотрудников, что подрывает доверие и может привести к прямым финансовым потерям или репутационному ущербу.
Команда инженеров Cloudflare оперативно отреагировала на отчеты, полученные через программу Bug Bounty, и выпустила комплексные исправления. В обновленной версии фреймворка 0.8.0 строго соблюдаются стандарты формирования HTTP-запросов, правильно валидируется потоковое кодирование, а также реализовано ожидание подтверждения от бэкенда перед обновлением соединений. Проблемный алгоритм создания ключей кэша по умолчанию был полностью удален. Специалистам по информационной безопасности, в чьей инфраструктуре используется Pingora, необходимо незамедлительно предпринять несколько шагов. В первую очередь, требуется обновить все экземпляры фреймворка до версии 0.8.0. Во-вторых, при использовании собственных реализаций кэширования следует убедиться, что в логике формирования ключей учитываются заголовок хоста и схема протокола. Наконец, рекомендуется усилить мониторинг журналов входных прокси на предмет аномальных HTTP/1.0 запросов или неожиданных заголовков "Upgrade", которые могут свидетельствовать о попытках разведки или эксплуатации. Этот инцидент служит важным напоминанием о необходимости тщательной проверки и настройки даже самых надежных с точки зрения производительности решений, особенно когда они становятся критическим элементом периметра защиты.
Ссылки
- https://www.cve.org/CVERecord?id=CVE-2026-2833
- https://www.cve.org/CVERecord?id=CVE-2026-2835
- https://www.cve.org/CVERecord?id=CVE-2026-2836
- https://blog.cloudflare.com/pingora-oss-smuggling-vulnerabilities/
- https://github.com/cloudflare/pingora
