Framework Pingora, rozwijany przez firmę Cloudflare jako wysokowydajny system proxy dla infrastruktury internetowej, znalazł się ostatnio w centrum uwagi specjalistów ds. bezpieczeństwa. Badacze ujawnili kilka poważnych podatności, które mogą umożliwić przeprowadzanie ataków typu HTTP Request Smuggling, prowadzących do przejęcia sesji użytkowników, manipulowania zapytaniami HTTP oraz zatruwania pamięci cache. Choć infrastruktura Cloudflare nie była podatna na te błędy, problem dotyczy instalacji Pingora używanych jako niezależne serwery proxy wystawione bezpośrednio do Internetu.
Czym jest Pingora i dlaczego jest ważny?
Pingora to nowoczesny framework proxy stworzony przez Cloudflare w celu obsługi ogromnej liczby zapytań HTTP przy minimalnym zużyciu zasobów. Oprogramowanie zostało udostępnione jako projekt open source i gwałtownie stało się atrakcyjnym rozwiązaniem dla organizacji budujących własne systemy reverse proxy lub warstwy cache.
System działa jako pośrednik między klientem a serwerem aplikacyjnym (backendem), analizując i przekazując ruch HTTP. Dzięki temu może pełnić funkcje takie jak:
- load balancing,
- caching treści HTTP,
- kontrola bezpieczeństwa i filtrowanie ruchu,
- przyspieszanie dostarczania treści.
Właśnie ta pozycja „pośrodku” infrastruktury sprawia, iż błędy w parserze protokołu HTTP mogą mieć bardzo poważne konsekwencje.
Odkryte podatności i identyfikatory CVE
Badacz bezpieczeństwa Rajat Raghav odkrył kilka luk w Pingora, którym przypisano identyfikatory CVE-2026-2833, CVE-2026-2835 oraz CVE-2026-2836.
Podatności te umożliwiają przeprowadzanie ataków typu HTTP Request Smuggling, czyli manipulowania sposobem interpretacji zapytań HTTP przez różne elementy infrastruktury sieciowej.
Co ważne, Cloudflare potwierdziło, iż ich własna infrastruktura CDN nie była podatna na te błędy, ponieważ Pingora nie jest tam używany jako zewnętrzny proxy przyjmujący ruch z Internetu.
Na czym polega HTTP Request Smuggling
Atak request smuggling polega na wykorzystaniu różnic w interpretacji zapytań HTTP między komponentami systemu – na przykład między serwerem proxy a backendem aplikacji.
Jeżeli jeden element infrastruktury uzna, iż zapytanie HTTP już się zakończyło, a drugi przez cały czas je parsuje, możliwe staje się „przemycenie” drugiego, ukrytego zapytania w tym samym strumieniu danych.
W efekcie backend może przetworzyć złośliwe zapytanie jako kolejne żądanie pochodzące od niewinnego użytkownika.
Mechanizm podatności w Pingora
Jednym z mechanizmów prowadzących do podatności jest nieprawidłowa interpretacja nagłówków HTTP określających długość zapytania.
Szczególnie problematyczne są sytuacje, gdy jednocześnie używane są nagłówki:
- Content-Length
- Transfer-Encoding: chunked
W takim przypadku proxy i backend mogą różnie interpretować moment zakończenia wiadomości HTTP.
Przykładowy schemat ataku:
GET / HTTP/1.0 Host: example.com Connection: keep-alive Transfer-Encoding: identity, chunked Content-Length: 29 0 GET /admin HTTP/1.1 X:W tym scenariuszu proxy może uznać, iż pierwsze zapytanie jest zakończone, podczas gdy backend potraktuje fragment „GET /admin” jako nowe zapytanie.
Desynchronizacja proxy i backendu
Podstawą wielu exploitów jest tzw. HTTP Desynchronization Attack.
Powstaje on, gdy:
- proxy interpretuje zapytanie w jeden sposób,
- backend interpretuje je w inny sposób,
- kolejne zapytanie użytkownika zostaje połączone z fragmentem złośliwego payloadu.
Może to doprowadzić do sytuacji, w której odpowiedź backendu zostanie wysłana do niewłaściwego klienta lub zawiera zmodyfikowane nagłówki.
Potencjalne skutki ataku
Eksploatacja podatności w Pingora może prowadzić do kilku poważnych scenariuszy:
1. Przejęcie sesji użytkownika
Złośliwe zapytanie może zostać wykonane w kontekście innego użytkownika.
2. Zatruwanie cache (cache poisoning)
Atakujący może spowodować zapisanie złośliwej odpowiedzi w pamięci cache proxy, która następnie będzie serwowana wielu użytkownikom.
3. Ominięcie zabezpieczeń proxy
Niektóre mechanizmy filtrujące ruch (np. WAF lub ACL) działają tylko na pierwszym zapytaniu i mogą zostać ominięte.
4. Manipulacja nagłówkami HTTP
Atakujący może wstrzykiwać nagłówki lub zmieniać adres docelowy zapytania.
Inny wariant podatności – upgrade połączenia
Jedna z luk dotyczyła także obsługi nagłówka Upgrade.
Pingora w niektórych sytuacjach przekazywał dane do backendu, zanim otrzymał potwierdzenie zmiany protokołu (101 Switching Protocols).
To zachowanie umożliwiało przesłanie dodatkowych danych do backendu i przemycenie kolejnych zapytań HTTP.
Które instalacje są zagrożone?
Najbardziej narażone są środowiska, w których:
- Pingora działa jako publiczny ingress proxy,
- obsługiwany jest ruch HTTP/1.x,
- wykorzystywany jest wspólny backend dla wielu użytkowników.
Infrastruktura Cloudflare CDN nie była podatna na ataki, ponieważ stosuje inną architekturę ruchu i dodatkowe mechanizmy parsowania HTTP.
Aktualizacje bezpieczeństwa
Cloudflare opublikowało poprawki w wersji Pingora 0.8.0, które eliminują opisane problemy.
Najważniejsze zmiany obejmują:
- poprawioną logikę parsowania zapytań HTTP,
- bezpieczniejszą obsługę upgrade połączeń,
- dodatkowe mechanizmy walidacji nagłówków,
- wzmocnione zabezpieczenia przed desynchronizacją HTTP.
Administratorzy korzystający z Pingora powinni jak najszybciej zaktualizować oprogramowanie, szczególnie jeżeli serwer proxy jest dostępny z Internetu.
Podsumowanie
Podatności w Pingora pokazują, jak trudne jest bezpieczne implementowanie parserów protokołu HTTP w złożonych środowiskach proxy. choćby niewielkie różnice w interpretacji nagłówków lub długości wiadomości mogą prowadzić do poważnych luk bezpieczeństwa.
Ataki typu request smuggling należą do najbardziej podstępnych w nowoczesnych architekturach webowych, ponieważ wykorzystują subtelne różnice w działaniu wielu komponentów infrastruktury.
W związku z tym organizacje korzystające z reverse proxy i systemów cache powinny regularnie aktualizować oprogramowanie, monitorować ruch HTTP oraz stosować dodatkowe mechanizmy walidacji zapytań.