Cloudflare hat die Behebung von drei Schwachstellen im Pingora-Framework angekündigt, von denen zwei als kritisch eingestuft sind (9,3 von 10). Das Pingora-Framework ist in Rust geschrieben und dient der Entwicklung sicherer, leistungsstarker Netzwerkdienste. Der mit Pingora erstellte Proxy wird im Content Delivery Network von Cloudflare eingesetzt und verarbeitet über 40 Millionen Anfragen pro Sekunde. Die Schwachstellen wurden in der Version 0.8.0 von Pingora behoben.
Die zwei gefährlichsten Schwachstellen ermöglichen HTTP Request Smuggling-Angriffe, die es Angreifern erlauben, Zugriffskontrollsysteme zu umgehen und in die Inhalte von Anfragen anderer Benutzer einzudringen, die im selben Stream zwischen Frontend und Backend verarbeitet werden (zum Beispiel zur Einspeisung schädlichen JavaScript-Codes in die Sitzung eines anderen Benutzers mit der Website). Die Probleme wurden von einem Teilnehmer des Bug-Bounty-Programms festgestellt, das eine Belohnung für die Entdeckung von Schwachstellen vorsieht.
In einer Architektur, die über einen Reverse-Proxy auf das Backend zugreift, nimmt ein zusätzlicher Knoten die Client-Anfragen entgegen und stellt eine langfristige TCP-Verbindung mit dem Backend her, das die direkten Anfragen verarbeitet. Über diese gemeinsame Verbindung werden in der Regel Anfragen verschiedener Benutzer nacheinander unter Verwendung der HTTP-Protokollmittel übertragen. HTTP Request Smuggling-Angriffe entstehen aus unterschiedlichen Interpretationen von HTTP-Headern und der HTTP-Protokollspezifikation zwischen Frontend und Backend, beispielsweise wenn das Frontend den HTTP-Header „Content-Length“ zur Bestimmung der Anfragegröße verwendet, während das Backend „Transfer-Encoding: chunked“ nutzt.
Die erste Schwachstelle CVE-2026-2835 ist im Code der HTTP/1.0-Anforderungsanalyse vorhanden und wird durch die fehlerhafte Verarbeitung des Headers „Transfer-Encoding“ mit mehreren Werten sowie durch die Verwendung des Verbindungsabschlusses als Indikator für das Ende des Anfragekörpers (close-delimited) verursacht. Pingora hat nur die Variante „Transfer-Encoding: chunked“ überprüft und diesen Header ignoriert, wenn mehrere Werte angegeben wurden. In dieser Situation hat Pingora die Größe im Header „Content-Length“ nicht berücksichtigt und hat alle Daten, die bis zum Abschluss der Verbindung empfangen wurden, als Anfragekörper betrachtet.
Durch die Angabe mehrerer Werte im Header „Transfer-Encoding“ konnte der Angreifer Bedingungen schaffen, unter denen eine Anfrage an das Backend geleitet wurde, deren tatsächliche Größe nicht mit der Größe der chunked-Kette übereinstimmte, die anhand des Headers „Transfer-Encoding“ berechnet wurde. Pingora leitete alle empfangenen Daten als eine Anfrage weiter, während das Backend, wie beispielsweise Node.js, die Anfrage auf der Grundlage von „Transfer-Encoding: chunked“ berechnete und den verbleibenden Teil als Beginn einer anderen Anfrage behandelte. GET / HTTP/1.0 Host: example.com Connection: keep-alive Transfer-Encoding: identity, chunked Content-Length: 29 0 GET /admin HTTP/1.1 X:
Die zweite Sicherheitsanfälligkeit CVE-2026-2833 entsteht durch die fehlerhafte Verarbeitung des HTTP-Headers „Upgrade“ in HTTP/1.1-Anfragen. Wenn der Header „Upgrade“ in einer Anfrage vorhanden ist, wird dieser sofort vom Proxy an das Backend weitergeleitet, während die übrigen Anfragedaten, die dem „Upgrade“-Header folgen, nicht auf die Antwort des Backends mit dem Code 101 (Switching Protocols) warten. Dadurch wird die Synchronisation des Streams zwischen Proxy und Backend gestört, und das Backend interpretiert die nach dem „Upgrade“-Header gesendeten Daten als separate Anfrage und sendet das Ergebnis dieser Anfrage als Antwort auf die nachfolgende Anfrage eines anderen Benutzers. GET / HTTP/1.1 Host: example.com Upgrade: foo GET /admin HTTP/1.1 Host: example.com
Probleme treten auf, wenn Pingora in Form eines Reverse-Proxys (Ingress-Proxy) verwendet wird, der Benutzeranfragen über die Protokolle HTTP/1.0 oder HTTP/1.1 an Backend-Systeme weiterleitet. Die für das Content Delivery Network Cloudflare verwendete Konfiguration von Pingora ließ keine Ausnutzung von Sicherheitsanfälligkeiten zu, da Pingora im CDN nicht als Ingress-Proxy fungiert, Anfragen nur über das Protokoll HTTP/1.1 umleitet, Anfragen mit ungültigen Content-Length-Werten blockiert, lediglich einen Wert des Headers "Transfer-Encoding: chunked" weiterleitet und bei Anfragen mit dem Header "Upgrade:" den zusätzlichen Header "Connection: close" einfügt, der die Übertragung zusätzlicher Anfragen über dieselbe Verbindung verhindert.
Die dritte Schwachstelle CVE-2026-2836 (Schweregrad 8.4 von 10) führt zu Cache-Vergiftungen (cache poisoning), da der Cache-Schlüssel (CacheKey) nur auf Basis des URI-Pfades generiert wird und den Inhalt des „Host“-Headers ignoriert. Diese unzureichende Implementierung führt zur Bildung identischer Cache-Schlüssel für identische HTTP-Pfade zu unterschiedlichen Hosts. Die Schwachstelle kann verwendet werden, um den Cache-Inhalt bei Verwendung des Caching-Modus für mehrere Hosts zu ersetzen. In Pingora ist Caching eine experimentelle Funktion, die für produktive Implementierungen nicht empfohlen wird.
Quelle: opennet.ru
