Source: guzzle Version: 7.15.1-1 Severity: important Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for guzzle. CVE-2026-69245[0]: | Guzzle is an extensible PHP HTTP client. Prior to 7.15.2 and 8.0.1, | SetCookie::matchesDomain() gives every subdomain of a cookie Domain | that cookie unless SetCookie::matchesDomain() recognizes the Domain | as an IP literal or a numeric host, and the decision comes from the | domain's own text, so two spellings a transport reads as an address | keep subdomain scope. Hexadecimal and mixed-base forms such as | 0x7f000001 and 0177.0.0.0x1 go unrecognized while libcurl 8.21.0 | reads both as 127.0.0.1. A percent-escaped Domain keeps that scope | on both branches because percent-decoding sits above numeric | parsing, so 192.168.0.%31 and 127.0.0.1%2e are registered names in | the URI grammar rather than address literals, and no numeric rule in | any base classifies them, while libcurl decodes the host before | resolving and reads them as 192.168.0.1 and 127.0.0.1. A cookie | stored for Domain=0x7f000001 is placed in the Cookie header of a | request to evil.0x7f000001, disclosing a session identifier or token | to a host that is not that address, and a response from | evil.0x7f000001 setting Domain=0x7f000001 is accepted into the jar | and replayed to the address, so a server answering for the look- | alike name can fix a session or set application state. Exploitation | requires the application to enable cookie support, address an origin | by one of these spellings, and contact a host whose name ends in | that spelling. This issue is fixed in versions 7.15.2 and 8.0.1. CVE-2026-69246[1]: | Guzzle is an extensible PHP HTTP client. Prior to 7.15.2 and 8.0.1, | Guzzle gives a transport the request URI as text and supplies the | Host header separately. The cURL handlers set CURLOPT_URL to the URI | exactly as written and push that Host into CURLOPT_HTTPHEADER; | StreamHandler does the same through fopen(). libcurl then parses the | authority itself, percent-decoding it and, on an IDN-capable build, | applying IDNA mapping, and uses the result to resolve, connect, name | the TLS peer and address a proxy CONNECT, while the supplied Host | suppresses the aligned one libcurl would have generated. For a URI | host written as 127.0.0.%31, filter_var() rejects the host as an IP | literal, yet libcurl decodes it to 127.0.0.1 and reaches loopback | with no DNS lookup while the server receives Host: 127.0.0.%31. An | attacker who influences a fetched URI can therefore reach a host the | application's checks excluded and read whatever the host exposes of | the response. The same divergence moves Guzzle's own decisions onto | a spelling the transport does not use: no_proxy selects proxy | routing from the literal host, and RedirectMiddleware decides from | it whether to strip Authorization and Cookie. Exploitation requires | the application to build a request URI from untrusted input and to | make a host decision before handing it to Guzzle. This issue is | fixed in versions 7.15.2 and 8.0.1. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-69245 https://www.cve.org/CVERecord?id=CVE-2026-69245 [1] https://security-tracker.debian.org/tracker/CVE-2026-69246 https://www.cve.org/CVERecord?id=CVE-2026-69246 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
