{"id":163792,"date":"2026-03-10T23:11:57","date_gmt":"2026-03-10T21:11:59","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimosti-v-proekte-pingora-pozvolyayushhie-vklinitsya-v-storonnie-zaprosy"},"modified":"2026-03-10T23:11:57","modified_gmt":"2026-03-10T21:11:59","slug":"uyazvimosti-v-proekte-pingora-pozvolyayushhie-vklinitsya-v-storonnie-zaprosy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/uyazvimosti-v-proekte-pingora-pozvolyayushhie-vklinitsya-v-storonnie-zaprosy","title":{"rendered":"Sicherheitsanf\u00e4lligkeiten im Pingora-Projekt, die es erm\u00f6glichen, in externe Anfragen einzudringen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Cloudflare hat die Behebung von drei Schwachstellen im Pingora-Framework angek\u00fcndigt, 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 \u00fcber 40 Millionen Anfragen pro Sekunde. Die Schwachstellen wurden in der Version 0.8.0 von Pingora behoben. <\/p>\n
Zwei der gef\u00e4hrlichsten Sicherheitsanf\u00e4lligkeiten erm\u00f6glichen Angriffe der Klasse \u201eHTTP Request Smuggling\u201c, die es erlauben, Zugriffsbeschr\u00e4nkungen zu umgehen und in die Inhalte der Anfragen anderer Benutzer, die im selben Stream zwischen Frontend und Backend verarbeitet werden, einzudringen (zum Beispiel um sch\u00e4dlichen JavaScript-Code in die Sitzung eines anderen Benutzers mit der Website einzuschleusen). Die Probleme wurden von einem Teilnehmer des Bug Bounty-Programms identifiziert, das Belohnungen f\u00fcr die Entdeckung von Schwachstellen vorsieht. <\/p>\n
In der Architektur, bei der \u00fcber einen Reverse-Proxy auf das Backend zugegriffen wird, nimmt ein zus\u00e4tzlicher Knoten die Anfragen der Kunden entgegen, der eine dauerhaft bestehende TCP-Verbindung zum Backend aufbaut, das die Anfragen direkt verarbeitet. \u00dcber diese gemeinsame Verbindung werden in der Regel die Anfragen verschiedener Benutzer nacheinander \u00fcbertragen, die durch die HTTP-Protokollmittel voneinander getrennt werden. Angriffe der Klasse HTTP Request Smuggling entstehen durch unterschiedliche Interpretationen der HTTP-Header und -Spezifikationen zwischen Frontends und Backends, zum Beispiel wenn das Frontend den HTTP-Header \u201eContent-Length\u201c zur Bestimmung der Anfragel\u00e4nge verwendet, w\u00e4hrend das Backend \u201eTransfer-Encoding: chunked\u201c nutzt. <\/p>\n
Die erste Sicherheitsanf\u00e4lligkeit CVE-2026-2835 tritt im Code zur Analyse von HTTP\/1.0-Anfragen auf und resultiert aus der fehlerhaften Verarbeitung des Headers \u201eTransfer-Encoding\u201c mit mehreren Werten sowie der Verwendung der Verbindungsbeendigung als Indikator f\u00fcr das Ende des Anfragek\u00f6rpers (close-delimited). Pingora pr\u00fcfte nur die Variante \u201eTransfer-Encoding: chunked\u201c und ignorierte diesen Header, wenn mehrere Werte angegeben wurden. In dieser Situation ber\u00fccksichtigte Pingora die Gr\u00f6\u00dfe im Header \u201eContent-Length\u201c nicht und betrachtete alle Daten bis zur Schlie\u00dfung der Verbindung als Teil des Anfragetextes. <\/p>\n
Durch die Angabe mehrerer Werte im Header \u201eTransfer-Encoding\u201c konnte der Angreifer Bedingungen schaffen, unter denen eine Anfrage an das Backend umgeleitet wurde, deren tats\u00e4chliche Gr\u00f6\u00dfe nicht mit der Gr\u00f6\u00dfe der chunked-Kette \u00fcbereinstimmte, die auf der Grundlage des Headers \u201eTransfer-Encoding\u201c berechnet wurde. Pingora leitete alle empfangenen Daten als eine Anfrage weiter, w\u00e4hrend das Backend, zum Beispiel Node.js, die Anfrage basierend auf \u201eTransfer-Encoding: chunked\u201c berechnete und den verbleibenden Rest 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:
<\/center> <\/p>\n
Die zweite Sicherheitsanf\u00e4lligkeit CVE-2026-2833 resultiert aus der fehlerhaften Verarbeitung des HTTP-Headers \u201eUpgrade\u201c in HTTP\/1.1-Anfragen. Sollte im Anfrageheader \u201eUpgrade\u201c vorhanden sein, wurde der Proxy umgehend alle weiteren Anfragedaten, die dem Header \u201eUpgrade\u201c folgen, ohne auf eine Antwort des Backends mit dem Code 101 (Switching Protocols) zu warten, direkt an das Backend weiterleiten. Dies f\u00fchrte dazu, dass die Synchronisation des Streams zwischen Proxy und Backend gest\u00f6rt wurde, wodurch das Backend die nach dem Header \u201eUpgrade\u201c gesendeten Daten als separate Anfrage betrachtete und das Ergebnis der Ausf\u00fchrung dieser Anfrage als Antwort auf die folgende Anfrage eines anderen Benutzers zur\u00fccksendete. GET \/ HTTP\/1.1 Host: example.com Upgrade: foo GET \/admin HTTP\/1.1 Host: example.com
<\/center>
<\/center> <\/p>\n
Die Probleme zeigen sich bei der Verwendung von Pingora als Reverse-Proxy (Ingress-Proxy), der die Benutzeranfragen an die Backends unter Verwendung der Protokolle HTTP\/1.0 oder HTTP\/1.1 \u00fcbertr\u00e4gt. Die in dem Content Delivery Network (CDN) von Cloudflare verwendete Konfiguration von Pingora erlaubte es nicht, die Sicherheitsanf\u00e4lligkeiten auszunutzen, da Pingora im CDN nicht als Ingress-Proxy verwendet wird, Anfragen nur unter Verwendung des HTTP\/1.1-Protokolls weiterleitet, Anfragen mit ung\u00fcltigen Werten im Content-Length-Header blockiert, nur einen Wert f\u00fcr den Header \u201eTransfer-Encoding: chunked\u201c akzeptiert und in Anfragen mit dem Header \u201eUpgrade:\u201c einen zus\u00e4tzlichen Header \u201eConnection: close\u201c einf\u00fcgt, der das \u00dcbertragen zus\u00e4tzlicher Anfragen in derselben Verbindung verhindert. <\/p>\n
Die dritte Sicherheitsanf\u00e4lligkeit CVE-2026-2836 (Schweregrad 8.4 von 10) f\u00fchrt zu Cache Poisoning, da der Schl\u00fcssel f\u00fcr die Cache-Datenplatzierung (CacheKey) ausschlie\u00dflich auf der Grundlage des URI-Pfades erzeugt wird, wobei der Inhalt des Headers \u201eHost\u201c ignoriert wird. Diese Unzul\u00e4nglichkeit f\u00fchrt zur Erzeugung identischer Cache-Schl\u00fcssel f\u00fcr \u00e4hnliche HTTP-Pfade zu verschiedenen Hosts. Die Sicherheitsanf\u00e4lligkeit kann zur Manipulation der Cache-Inhalte genutzt werden, wenn der Cache-Modus f\u00fcr mehrere Hosts verwendet wird. In Pingora ist Caching eine experimentelle Funktion, die nicht f\u00fcr den produktiven Einsatz empfohlen wird. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Sicherheitsanf\u00e4lligkeiten](\"\/wp-content\/uploads\/2026\/03\/6a4654a05c9ff8c64cc4cb4773bf4ec9.png\")
<\/center> <\/p>\n![\"Sicherheitsanf\u00e4lligkeiten](\"\/wp-content\/uploads\/2026\/03\/f86f840431a9be00c4cfd74cc6b4c89b.png\")
<\/center> ![\"Sicherheitsanf\u00e4lligkeiten](\"\/wp-content\/uploads\/2026\/03\/8b23d0642fc0b783c2027b91078607e4.png\")
<\/center> <\/p>\n