The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Уязвимости в проекте Pingora, позволяющие вклиниться в сторонние запросы

10.03.2026 19:30 (MSK)

Компания Cloudflare объявила об устранении трёх уязвимостей во фреймворке Pingora, двум из которых присвоен критический уровень опасности (9.3 из 10). Фреймворк Pingora написан на языке Rust и предназначен для разработки защищённых высокопроизводительных сетевых сервисов. Построенный при помощи Pingora прокси используется в сети доставки контента Cloudflare и обрабатывает более 40 млн запросов в секунду. Уязвимости устранены в выпуске Pingora 0.8.0.

Две наиболее опасные уязвимости допускают проведение атак класса "HTTP Request Smuggling", позволяющих обходить системы ограничения доступа и вклиниваться в содержимое запросов других пользователей, обрабатываемых в том же потоке между фронтэндом и бэкендом (например, для подстановки вредоносного JavaScript-кода в сеанс другого пользователя с сайтом). Проблемы выявлены участником программы Bug Bounty, предусматривающей выплату вознаграждения за обнаружение уязвимостей.

В схеме с обращением к бэкенду через обратный прокси запросы клиентов принимает дополнительный узел, который устанавливает длительно действующее TCP-соединение с бэкендом, осуществляющим непосредственную обработку запросов. Через данное общее соединение обычно передаются запросы разных пользователей, которые следуют по цепочке один за другим с разделением средствами протокола HTTP. Атаки класса HTTP Request Smuggling возникают из-за разной трактовки HTTP-заголовков и спецификаций протокола HTTP на фронтэндах и бэкендах, например, когда фронтэнд использует для определения размера запроса HTTP-заголовок "Content-Length", а бэкенд "Transfer-Encoding: chunked".

Первая уязвимость CVE-2026-2835 присутствует в коде разбора запросов HTTP/1.0 и вызвана некорректной обработкой заголовка "Transfer-Encoding" с несколькими значениями, а также использованием закрытия соединения как признака конца тела запроса (close-delimited). Pingora проверял только вариант "Transfer-Encoding: chunked" и игнорировал данный заголовок, если в нём указывалось несколько значений. В этой ситуации Pingora не учитывал размер в заголовке "Content-Length", а считал телом запроса все данные, полученные до закрытия соединения.

Через указание нескольких значений в заголовке "Transfer-Encoding" атакущий мог создать условия, при которых на бэкенд перенаправлялся запрос, фактический размер которого не соответствовал размеру chunked-цепочки, вычисленному на основе заголовка "Transfer-Encoding. Pingora перенаправлял все полученные данные как один запрос, а бэкенд, например, Node.js, вычислял запрос на основе "Transfer-Encoding: chunked" и оставшийся хвост обрабатывал как начало другого запроса.


   GET / HTTP/1.0
   Host: example.com
   Connection: keep-alive
   Transfer-Encoding: identity, chunked
   Content-Length: 29

   0

   GET /admin HTTP/1.1
   X:


Вторая уязвимость CVE-2026-2833 вызвана некорректной обработкой HTTP-заголовка "Upgrade" в запросах HTTP/1.1. При наличии в запросе заголовка "Upgrade" прокси сразу пробрасывал к бэкенду и остальные данные запроса, следующие за заголовком "Upgrade", не дожидаясь от бэкенда ответа с кодом 101 (Switching Protocols). Из-за этого синхронизация потока между прокси и бэкендом нарушалась и бэкенд воспринимал отправленные после заголовка "Upgrade" данные как отдельный запрос, и отправлял результат выполнения этого запроса в ответ на пришедший следом запрос другого пользователя.


   GET / HTTP/1.1
   Host: example.com
   Upgrade: foo


   GET /admin HTTP/1.1
   Host: example.com


Проблемы проявляются при использовании Pingora в форме обратного прокси (ingress proxy), транслирующего запросы пользователей к бэкендам с использованием протоколов HTTP/1.0 или HTTP/1.1. Применяемая в сети доставки контента Cloudflare конфигурация Pingora не позволяла эксплуатировать уязвимости, так как Pingora в CDN не используется в роли ingress-прокси, перенаправляет запросы только с использованием протокола HTTP/1.1, блокирует запросы с некорректными значениями Content-Length, перенаправляет только одно значение заголовка "Transfer-Encoding: chunked" и подставляет в запросы с заголовком "Upgrade:" дополнительный заголовок "Connection: close", не позволяющий передавать дополнительные запросы в том же соединении.

Третья уязвимость CVE-2026-2836 (степень опасности 8.4 из 10) приводит к отравлению кэша (cache poisoning) из-за генерации ключа размещения данных в кэше (CacheKey) только на основе пути из URI, игнорируя содержимое заголовка "Host". Подобная недоработка приводит к формированию одинаковых ключей кэширования для одинаковых HTTP-путей к разным хостам. Уязвимость может использоваться для подмены содержимого кэша при использовании режима кэширования для нескольких хостов. В Pingora кэширование является экспериментальной функцией, не рекомендованной для рабочих внедрений.

  1. Главная ссылка к новости (https://blog.cloudflare.com/pi...)
  2. OpenNews: Выпуск Pingora 0.7, фреймворка для создания сетевых сервисов
  3. OpenNews: SMTP Smuggling - новая техника спуфинга почтовых сообщений
  4. OpenNews: Атака Continuation flood, приводящая к проблемам на серверах, использующих HTTP/2.0
  5. OpenNews: Атака на системы фронтэнд-бэкенд, позволяющая вклиниться в сторонние запросы
  6. OpenNews: Новая атака на системы фронтэнд-бэкенд, позволяющая вклиниться в запросы
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/64957-pingora
Ключевые слова: pingora, http, smuggling
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (17) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Диды (ok), 20:53, 10/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Ну ожидаемо.
    На brainfuck весьма сложно отслеживать логику приложения.
     
     
  • 2.19, Аноним (19), 21:39, 10/03/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > В Pingora кэширование является экспериментальной функцией, не рекомендованной для рабочих внедрений.

    Если так, почему её использовали?

     
  • 2.28, Аноним (28), 22:21, 10/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > На brainfuck весьма сложно отслеживать логику приложения.

    А на каком легко? На Go?

     

  • 1.3, Аноним (3), 20:53, 10/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    РЕШЕТO!!1

    А если серьезно: спецификации содержат настолько большое количество нюансов, что нам ещё долго предстоит выгребать последствия, даже если языки будут супер-пупер безопасные.

     
     
  • 2.16, Аноним (16), 21:23, 10/03/2026 [^] [^^] [^^^] [ответить]  
  • –2 +/
    https://www.opennet.dev/opennews/art.shtml?num=64574
     
  • 2.34, Аноним (34), 22:52, 10/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    никакой спеки там нет, костыль на костыле
     

  • 1.8, Аноним (16), 21:08, 10/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Уязвимости устранены в выпуске Pingora 0.8.0

    Реагируют, уже хорошо.
    Хотя сейчас везде так, ПО становится всё сложнее и сложнее.

     
     
  • 2.9, Аноним (16), 21:10, 10/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >Проблемы выявлены участником программы Bug Bounty, предусматривающей выплату вознаграждения за обнаружение уязвимостей.

    А это прям хорошо.

     
  • 2.12, Аноним (12), 21:17, 10/03/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Хотя сейчас везде так, ПО становится всё сложнее и сложнее.

    Так и есть. Диды не зря завещали: "Keep it simple, stupid". Но теперь же надо всё переписать, да навернуть покруче.

     
     
  • 3.15, Аноним (16), 21:22, 10/03/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И без переписывания за всем не уследишь:
    1) https://opennet.ru/62635-kernel
    2) https://opennet.ru/64574-bug
     
  • 3.33, Аноним (33), 22:41, 10/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Диды не зря завещали: "Keep it simple, stupid".

    А делали Keep it simple-stupid.
    В первом же новом юниксе выcpaли дырень в 50 строках.

    Как говорится "не мешки ворочать".

     

  • 1.24, Аноним (24), 22:02, 10/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    "haha, classic" (ц)
    Оказывается, если использовать язык программирования, с которым не надо тщательно обдумывать каждую строку, то можно знатно нафакапить.
     
     
  • 2.27, Аноним (28), 22:20, 10/03/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Оказывается, если использовать язык программирования, с которым не надо тщательно обдумывать каждую строку, то можно знатно нафакапить.

    Обдумавания вроде "как не вылезти за пределы буфера", "как не сделать дабл-фри" и "как не уронить память" на каждую строку никак не спасут тебя от багов, о которых говорится в новости.

    Наоборот: в дополнение к проблемам ищ новости у тебя были бы те самые дабл-фри, вылазания за буфер и т.п.

     
     
  • 3.37, Аноним (37), 23:06, 10/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Мне кажется ты не разобрался.
     
  • 2.29, Аноним (29), 22:25, 10/03/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Он берёт на себя некие гарантии по безопасной работе с памятью, что снижает потребность пограммиста заботиться именно об этом - о памяти. Какие из этого можно сделать выводы? На кону миллион долларов:

    A) Освобождаются силы, что позволяет больше уделять времени другим вещам (общее количество трудозатрат остаётся то же, но перераспределяется на другие проблемы)

    B) Программист перестаёт думать над каждой строчкой вообще, а не только о некоторых моментах с памятью

    Можно позвонить другу, если кажется, что ответ не очевиден. Или попросить помощи у других комментаторов, прямо из зала.

     

  • 1.35, ятупойтролль (ok), 23:00, 10/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    так, а зачем на этот небезопасный язык переписывают ядро и коре утилс?
     
  • 1.36, Аноним10084 и 1008465039 (?), 23:03, 10/03/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Противники божественного Rust'а сейчас побегут писать: "Ага, вот видите, Раст не спасает!1" Но на деле эта новость именно что подтверждает, что божественный Раст спасает! Уязвимость не переполнение буффера, а реальная логическая ошибка. Она и на Си завсегда могла быть, только прежде чем ее обнаружить, было бы куча ошибок памяти. А тут сразу логика - успех.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2026 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру