An attacker who can influence a URL your app fetches with Guzzle can reach a host your app meant to block, such as the server itself, and read the response. This is a kind of server-side request forgery (SSRF): getting your server to make requests on the attacker's behalf.

Guzzle checked the host as written, but the network layer could read an oddly written host as a different one. The same mismatch could also send Authorization and Cookie headers, or proxy decisions, the wrong way.

Who is affected

Apps on guzzlehttp/guzzle before 7.15.2, or 8.0.0, that build a request URL from untrusted input and check the host before sending it. The Guzzle advisory says denylists, private address checks and IP checks are the ones at risk. An exact allowlist of host names usually fails safe. Apps that only fetch URLs they build themselves aren't affected.

What to do

Update to 7.15.2, or to 8.0.1 on 8.x. The fix rejects hosts with escapes and other odd characters before any request goes out. If you can't update yet, the advisory shows how to check the host yourself, on every redirect.

Guzzle says it doesn't offer SSRF protection, and numeric spellings like 127.1 are still accepted after the fix. Where the destination matters, resolve the host and check the addresses it points to.

Reported by bilguunbicktivism.