CVE-2026-69246 in Guzzle
Zusammenfassung
von VulDB • 04.08.2026
Guzzle ist ein erweiterbarer PHP HTTP-Client. Vor den Versionen 7.15.2 und 8.0.1 übergibt Guzzle die Request-URI als Text an das Transportmedium und stellt den Host-Header separat bereit. Die cURL-Handler setzen CURLOPT_URL auf die URI genau so, wie sie geschrieben ist, und fügen diesen Host in CURLOPT_HTTPHEADER ein; der StreamHandler tut dasselbe über fopen(). libcurl analysiert dann die Autorität selbst, dekodiert diese mit Prozentdekodierung und wendet bei einer IDN-fähigen Build-Konfiguration IDNA-Mapping an. Es verwendet das Ergebnis zur Auflösung, zum Herstellen der Verbindung, zur Benennung des TLS-Peers sowie zur Adressierung eines Proxy-CONNECTs, während der übergebene Host den von libcurl generierten, abgestimmten Header unterdrückt. Für eine URI-Host-Schreibweise wie 127.0.0.%31 lehnt filter_var() den Host als IP-Literal ab, doch libcurl dekodiert ihn zu 127.0.0.1 und stellt die Verbindung zum Loopback her, ohne DNS-Auflösung durchzuführen, während der Server Host: 127.0.0.%31 empfängt. Ein Angreifer, der eine abzurufende URI beeinflusst, kann daher einen Host erreichen, den die Prüfungen der Anwendung ausgeschlossen haben, und alle Daten lesen, die dieser Host in der Antwort offenlegt. Dieselbe Diskrepanz führt dazu, dass Guzzle eigene Entscheidungen auf einer Schreibweise trifft, die das Transportmedium nicht verwendet: no_proxy wählt die Proxy-Routing basierend auf dem Literal-Host aus, und RedirectMiddleware entscheidet daraufhin, ob Authorization- und Cookie-Header entfernt werden sollen. Die Ausnutzung erfordert, dass die Anwendung eine Request-URI aus nicht vertrauenswürdigen Eingaben erstellt und vor der Übergabe an Guzzle eine Host-Entscheidung trifft. Dieses Problem wurde in den Versionen 7.15.2 und 8.0.1 behoben.
VulDB is the best source for vulnerability data and more expert information about this specific topic.