Guzzle HTTP Client CVE-2026-55767

Exploitation requires three concurrent conditions: (1) the application uses Guzzle's cookie support, either via new Client(['cookies' => true]) or by passing an explicit CookieJar instance to the client constructor; (2) the same CookieJar instance is reused across HTTP requests to both an attacker-reachable origin (a server the attacker controls or can respond from) and at least one trusted origin that will accept the injected cookie; (3) the attacker-controlled server issues a Set-Cookie header with a dot-only Domain attribute such as Domain=., Domain=.., or a whitespace-padded variant like Domain= . . Applications that do not use Guzzle cookie support, use separate jars per origin, or restrict Guzzle to a single trusted host per client instance are not affected. The CVSS PR:N metric confirms no attacker privilege on the vulnerable system is required - the attacker's leverage comes from operating the malicious server being contacted, not from any foothold on the PHP application itself.

The NVD-assigned CVSS 5.8 (AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N) reflects a network-reachable, low-complexity attack with scope change into downstream systems, producing limited integrity impact via cookie injection. The Scope:Changed designation is accurate and important - the vulnerable Guzzle client becomes a conduit that injects attacker-supplied cookies into requests to entirely separate, trusted services. No EPSS score was supplied in the input; the absence of KEV listing and POC suggests this has not been observed in broad exploitation at time of analysis. However, the exploitable pattern - a shared CookieJar contacting mixed-trust origins - is common in PHP microservice backends and API aggregators, so the realistic exposure is broader than a low CVSS might suggest. The key limiting factor is architectural: applications using separate jars per origin or not using Guzzle cookie support at all are fully unaffected. The attack complexity is low from the attacker's perspective once the application is in the vulnerable configuration, though triggering the condition requires the attacker to operate or compromise a server that the target application requests.

A PHP application aggregates data from multiple third-party REST APIs using a single Guzzle client configured with new Client(['cookies' => true]). An attacker who controls one of those third-party endpoints - or who can compromise or spoof one - responds with Set-Cookie: authtoken=attacker_value; Domain=. in an HTTP response. Guzzle stores this cookie with an empty normalized domain and subsequently includes it in every outgoing request from the same jar, including requests to the application's own internal authentication service, injecting the attacker-controlled authtoken and potentially achieving session fixation.