Proxy-Passwort durch HTTP-Client geleakt: CVE in curl, libsoup und requests

Das Passwort für den Proxy wird normalerweise vor anderen Personen geheim gehalten: es wird nicht in Screenshots angezeigt, nicht in Git eingecheckt und in Umgebungsvariablen aufbewahrt. Doch im Jahr 2026 stellte sich heraus, dass es vom HTTP-Client selbst preisgegeben werden kann. Von April bis Juli traten mehrere Sicherheitsanfälligkeiten in curl, libcurl und libsoup auf, bei denen der Header Proxy-Authorization nicht an den richtigen Proxy, sondern direkt an die Zielwebsite gesendet wird. Im Folgenden wird erläutert, unter welchen Bedingungen dies geschieht, und eine schrittweise Überprüfung des eigenen Stacks.

Was passiert ist: vier Lecks in vier Monaten

Alle diese Bugs funktionieren gleich: Der Client speichert den Benutzernamen und das Passwort eines Proxys und sendet sie versehentlich weiter in der Kette.

• CVE-2026-6253 (curl und libcurl 7.14.1–8.19.0). Wenn für http:// und https:// unterschiedliche Proxys konfiguriert sind, der erste ein Passwort erfordert und der zweite nicht, dann sendet curl bei einer Umleitung aufgrund des Wechsels des Schemas die Anmeldedaten des ersten Proxys an den zweiten. Die Daten werden in base64 gesendet, also faktisch im Klartext. Behebt in curl 8.20.0, veröffentlicht am 29. April 2026. Auch die Konsolenversion von curl ist betroffen, nicht nur die Bibliothek.
• CVE-2026-8927 (libcurl 7.12.0–8.20.0). Die Anwendung verwendet einen Handle für mehrere Anfragen, Proxys werden aus Umgebungsvariablen entnommen, und die Authentifizierung erfolgt über Digest. In diesem Fall wird der Header Proxy-Authorization für Proxy A an Proxy B gesendet, der ihn wiederholen kann, um sich als Sie auszugeben. Behebt in curl 8.21.0 vom 24. Juni 2026. Die Konsolenversion von curl ist nicht betroffen. Ein fast identischer Bug wird in CVE-2026-7168 beschrieben, der einzige Unterschied besteht darin, wie der Proxy ausgewählt wird.
• CVE-2026-12547 (libsoup, SoupAuthManager). libsoup speichert die Anmeldedaten des Proxys im Cache, ohne sie an die Adresse host:port zu binden. Wenn die Proxy-Einstellungen geändert werden (Systemparameter, WPAD), wird der alte Header an den neuen Proxy gesendet. Veröffentlicht am 21. Juli 2026, Bewertung niedrig.
• CVE-2026-66339 (libsoup, CONNECT-Tunnel). Nach der Einrichtung eines CONNECT-Tunnels über einen HTTP-Proxy fügt libsoup den Header Proxy-Authorization zu den folgenden HTTPS-Anfragen innerhalb des Tunnels hinzu. Der Header wird bereits vom Zielserver gesehen. CVSS 6.5, veröffentlicht am 24. Juli 2026.

Die Geschichte ist nicht neu. In der Python-Bibliothek requests wurde der Header Proxy-Authorization bei einer Umleitung auf HTTPS von Version 2.3.0 bis 2.31.0 (CVE-2023-32681) an den Zielserver gesendet, wenn Benutzername und Passwort direkt in die URL des Proxys eingegeben wurden. In urllib3 bis 1.26.19 und 2.2.2 (CVE-2024-37891) wurde der manuell gesetzte Header, der nicht über die integrierte Proxy-Unterstützung gesetzt wurde, bei einer Umleitung auf eine fremde Domain nicht entfernt.

Warum das gerade für die Arbeit mit Proxys wichtig ist

Bei einem kostenpflichtigen Proxy entspricht das Passwort Geld. Wer es hat, verbraucht Ihren Traffic, bis Sie den Zugang ändern. Bei der Bezahlung für Gigabytes ist das eine direkte Rechnung, und bei einem gemeinsamen Zugang für das gesamte Team sind es auch die Aktionen anderer von Ihrer IP.

Die anfälligsten Szenarien sehen so aus:

• Parser und Monitoring-Tools, die automatisch durch Umleitungen navigieren. Die Zielwebsite oder eine Zwischenumleitung kann die Anfrage an eine Domain weiterleiten, die Header sammelt.
• Skripte mit mehreren Proxys: unterschiedliche Proxys für unterschiedliche Protokolle, Wechsel des Proxys zwischen Anfragen über eine Verbindung, Vermischung von „Passwort-Proxy“ und „Passwortlosen Proxys“.
• Langfristige Prozesse auf Linux-Servern, bei denen libcurl und libsoup mit den Systempaketen geliefert werden und zusammen mit der Distribution aktualisiert werden, nicht mit Ihrem Code.
• Unternehmensnetzwerke mit WPAD und PAC-Dateien: Der Proxy ändert sich ohne Beteiligung der Anwendung, und genau dieser Fall wird in CVE-2026-12547 beschrieben.

Wie man seinen Stack überprüft: Schritt für Schritt

1. Ermitteln Sie die tatsächliche Version von libcurl, nicht nur die von der Konsolenversion von curl. Der Befehl curl -V zeigt beide an, aber die Anwendung kann mit ihrer eigenen Kopie der Bibliothek gebaut worden sein. Für Python mit pycurl führen Sie python -c "import pycurl; print(pycurl.version)" aus, für PHP rufen Sie curl_version() auf. Sichere Grenze: 8.21.0 und neuer oder die behobenen Versionen 8.20.1+, 8.16.1+ und 8.14.2+.
2. Überprüfen Sie die Python-Abhängigkeiten. Führen Sie pip show requests urllib3 aus. Benötigt werden requests nicht unter 2.31.0 und urllib3 nicht unter 1.26.19 (Branch 1.x) oder 2.2.2 (Branch 2.x). Wenn die Abhängigkeit transitiv kommt, schauen Sie sich pip list innerhalb derselben Umgebung an, in der der Parser läuft.
3. Überprüfen Sie libsoup auf Linux. Dies betrifft GNOME-Anwendungen, WebKitGTK und alles, was auf diesem Stack gebaut ist. Aktualisieren Sie das Paket über den Paketmanager Ihrer Distribution und vergleichen Sie es mit dem Sicherheitshinweis Ihrer Distribution: In den Karten dieser CVE bei Red Hat sind RHEL 6–10 als betroffen aufgeführt.
4. Finden Sie im Code die manuelle Setzung des Headers. Suchen Sie nach Proxy-Authorization im gesamten Repository. Wenn der Header manuell gesetzt wird und nicht über den Standardmechanismus des Proxy-Clients (proxies= in requests, ProxyManager in urllib3, CURLOPT_PROXYUSERPWD in libcurl), ist dies ein Kandidat für ein Leck bei einer Umleitung.
5. Finden Sie die Wiederverwendung von Verbindungen beim Wechsel des Proxys. Ein Handle von libcurl, eine Sitzung von requests oder ein HTTP-Agent, über die nacheinander Anfragen mit unterschiedlichen Proxys gesendet werden. Die einfachste Lösung: eine separate Sitzung für jeden Proxy.
6. Deaktivieren Sie automatische Umleitungen, wo sie nicht benötigt werden. In requests ist das allow_redirects=False, in urllib3 redirect=False, in curl setzen Sie nicht -L und CURLOPT_FOLLOWLOCATION. Dann werden 3xx manuell verarbeitet, und Sie entscheiden selbst, wohin es weitergeht. Genau diesen Umgehungsweg bieten die Autoren von requests und urllib3.
7. Führen Sie einen Live-Test auf ein Leck durch. Richten Sie einen einfachen HTTP-Server ein, der alle eingehenden Header ausgibt, und machen Sie eine Umleitung zu einem zweiten solchen Server. Führen Sie mit Ihrem Parser und Proxy ein reales Szenario durch, einschließlich des Wechsels des Schemas von http auf https. Wenn einer der Server den Proxy-Authorization-Header gesehen hat, ist das Leck in Ihrem Code bestätigt und nicht nur theoretisch.

Fallstricke

• Docker-Images leben ihr eigenes Leben. Sie haben curl auf dem Host aktualisiert, aber der Parser läuft in einem Container mit einem alten Basis-Image. Überprüfen Sie innerhalb des Containers: docker exec <container> curl -V.
• Die Konsolenversion von curl und libcurl werden unterschiedlich aktualisiert. CVE-2026-8927 betrifft nicht die Konsolenversion von curl, während CVE-2026-6253 sie betrifft. Ein frisches curl -V im Terminal sagt nichts über die Bibliothek aus, mit der Ihr PHP oder Python gebaut wurde.
• Digest schützt nicht. Ja, bei Digest wird das Passwort nicht im Klartext gesendet. Aber in CVE-2026-8927 benötigt der Angreifer kein Passwort: Der abgefangene Header wird wiederholt, solange der nonce gültig ist.
• Das Passwort in der URL ist bequem, aber gefährlich. Das Leck in requests trat genau dann auf, wenn die Anmeldedaten in die Proxy-Adresse im Format user:pass@host:port eingegeben wurden. Das ist kein Grund, auf das Format zu verzichten, aber ein Grund, die Bibliotheken aktuell zu halten.
• Die Umleitung kann nicht vom Ziel kommen. Captcha-Seiten, Zustimmung-Banner, Linkverkürzer und CDNs antworten ebenfalls mit 3xx. Je mehr „Linkfolgen“ im Crawler vorhanden sind, desto größer ist die Angriffsfläche.

Wie man den Schaden begrenzen kann, wenn das Passwort doch verloren geht

Ein vollständiges Ausschließen eines Lecks ist nicht möglich: Morgen wird die nächste CVE veröffentlicht. Daher ist es wichtig, wie viel ein einzelnes Leck kostet.

• Ein Projekt, ein Zugang. Halten Sie keinen gemeinsamen Benutzernamen für alle Parser. In ProxyCove erhält jeder gekaufte Proxy ein separates Paar von Benutzername und Passwort, sodass der verlorene Zugang eines Skripts nicht den Traffic der anderen öffnet.
• Halten Sie auf einem Zugang nicht mehr Traffic als nötig. Füllen Sie nach und nach für die Aufgabe auf, nicht für ein halbes Jahr im Voraus.
• Überwachen Sie den Verbrauch. Ein plötzlicher Anstieg des Traffics ohne Anstieg der Anzahl der Aufgaben ist das erste Zeichen dafür, dass jemand anderes Ihren Zugang nutzt.
• Ändern Sie das Passwort sofort bei Verdacht und nach einem Zeitplan. Wie man das ohne Ausfallzeiten umsetzt, wird im Leitfaden zur Passwortrotation für Proxys erläutert.

Welchen Proxy-Typ wählen und was hat er damit zu tun

Ein Leck hängt nicht vom Proxy-Typ ab: Der Bug liegt im Client. Der Preis eines Lecks hingegen hängt davon ab. Rechenzentrums-Proxys sind günstiger pro Gigabyte, und für das Parsen einfacher Websites mit häufigen Umleitungen ist es sinnvoll, sie getrennt von teurem Traffic zu halten. Residential-Proxys sollten für Aufgaben verwendet werden, wo sie wirklich benötigt werden, und dafür sollten separate Zugänge mit deaktivierten automatischen Umleitungen eingerichtet werden. Mobile Proxys, die teuersten pro Gigabyte, sollten im Code mit minimalen externen Abhängigkeiten gehalten werden und unbedingt mit einer Überprüfung der Bibliotheksversionen bei jedem Build.

Fazit

Das Passwort für den Proxy kann ohne Hacking, ohne Virus und ohne menschlichen Fehler verloren gehen: ein veraltetes libcurl, eine Umleitung zu einer fremden Domain und eine wiederverwendete Verbindung reichen aus. Die Checkliste ist kurz: curl und libcurl ab 8.21.0, requests ab 2.31.0, urllib3 ab 1.26.19 oder 2.2.2, aktuelles libsoup, separate Sitzung für jeden Proxy, Umleitungen unter Kontrolle und ein Live-Test auf ein Leck. Plus ein separater Zugang für jedes Projekt, damit ein Leck nur einen Skript kostet und nicht das gesamte Guthaben.