Guzzle HTTP Client CVE-2026-67355

Exploitation requires all four of the following conditions simultaneously: (1) the application must enable Guzzle's built-in cookie support by passing a CookieJar (CookieJar, FileCookieJar, or SessionCookieJar) to the Guzzle client - applications that do not use Guzzle's cookie support are entirely unaffected; (2) the application must reuse the same CookieJar instance across requests to both a parent host (e.g., example.com) and at least one of its subdomains (e.g., child.example.com); (3) the parent host must set a cookie without a Domain attribute or with an empty Domain attribute, making it host-only; (4) the attacker must control or be able to observe traffic to the child subdomain. Exploitation is further limited by the cookie's own restrictions - path must match, Secure cookies are only sent over TLS, and expired cookies are not forwarded. Applications using a separate jar per host or trust boundary, applications that never request a less-trusted subdomain with the same jar, and applications whose servers only set cookies with an explicit non-empty Domain attribute are not affected.

The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N) scores 8.2 but the AC:H and AT:P metrics are critical context: exploitation requires a specific, non-default application architecture - a shared CookieJar reused across a trust boundary involving a subdomain the attacker controls or observes. In practice, many Guzzle deployments use per-request or per-session jars, or do not request subdomains from the same jar, which eliminates the attack surface entirely. There is no CISA KEV listing and no public proof-of-concept code, meaning this is not being opportunistically exploited at scale. EPSS data is absent from the provided intelligence. The real-world priority is medium-high for applications that aggregate API calls across multiple subdomains under the same origin using a shared persistent jar - a pattern seen in microservice or multi-tenant architectures. For single-host API clients, practical risk is near zero. The high CVSS score is technically defensible but overstates operational urgency for most deployments.

An attacker registers or compromises child.example.com. A PHP backend using Guzzle authenticates to example.com, which responds with a host-only Set-Cookie: sid=secret (no Domain attribute). The application later makes a Guzzle request to child.example.com using the same CookieJar - Guzzle forwards the sid=secret cookie to the attacker-controlled host, which captures the session token and replays it against example.com to impersonate the PHP backend. No public proof-of-concept exists at time of analysis.