CVE-2026-55767: Guzzle Cookie Domain Validation Flaw – PHP HTTP Client Injection

Technical summary

The vulnerability stems from insufficient validation in SetCookie::validate(). The method removes leading dots from domain attributes via SetCookie::matchesDomain(), which converts dot-only values to empty strings. However, validate() only rejects strictly empty domains, leaving whitespace-padded and post-normalization-empty domains undetected. These malformed cookies bypass storage checks, and because the normalized empty domain matches any request host, Guzzle applies the cookie to all downstream requests made through the same jar. An attacker can exploit this by hosting an endpoint that a vulnerable application requests, injecting a specially crafted Set-Cookie header to compromise cookie integrity and isolation.

Business impact

Applications using Guzzle with shared cookie jars across multiple upstream and downstream services face injection attacks. A compromised third-party endpoint or attacker-controlled origin can inject cookies that propagate to unrelated services, potentially stealing sessions, escalating privileges, or bypassing authentication controls. The impact depends on how downstream services interpret injected cookies and the trust model of the application architecture.

Affected systems

Guzzle versions prior to 7.12.1 are affected. Applications that instantiate a single CookieJar and reuse it across multiple HTTP requests to different hosts—a common pattern for connection pooling and efficiency—face the highest risk. PHP applications relying on Guzzle for HTTP operations are directly vulnerable.

Exploitability

Exploitation requires network access to an endpoint that the vulnerable application will request. The attacker controls the HTTP response headers from that endpoint and injects a malformed Set-Cookie header. No authentication, user interaction, or victim-side complexity is required; the vulnerability triggers automatically when Guzzle processes the response. The CVSS score of 5.8 reflects the network-accessible nature and lack of prerequisites, though integrity impact is limited to cookie scope rather than broader data compromise.

Remediation

Upgrade Guzzle to version 7.12.1 or later, which includes corrected validation logic in SetCookie::validate() to reject empty and whitespace-padded domain attributes. For applications unable to patch immediately, consider using separate cookie jar instances per upstream host or disabling cookie persistence for untrusted origins.

Patch guidance

Update the guzzlephp/guzzle package to 7.12.1 or newer. Verify the fix in vendor advisory documentation to confirm version alignment with your codebase. If using a dependency manager such as Composer, run `composer update guzzlephp/guzzle` to pull the patched version, then test integration with downstream services to ensure cookie handling remains correct.

Detection guidance

Monitor logs for Set-Cookie headers with empty or whitespace-only domain attributes originating from external endpoints. Inspect cookie jar contents at runtime to identify cookies with missing or malformed domain fields. Code review should flag any HTTP responses from third-party or user-controlled origins that are processed by Guzzle instances using shared jar objects. Security scanning tools should verify that installed Guzzle versions match 7.12.1 or later.

Why prioritize this

Although the CVSS score is medium (5.8), the vulnerability should be prioritized based on deployment scope: applications that request multiple external services using a shared cookie jar are at immediate risk. Cookie injection attacks can have cascading effects in microservice or API-gateway architectures. The fix is straightforward and non-breaking, making rapid remediation low-risk.

Risk score, explained

The CVSS 3.1 score of 5.8 (Medium severity) reflects a network-accessible attack vector with low complexity, no privileges or user interaction required, but limited to integrity impact within cookie scope. The vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N indicates scope change because the attack can affect downstream services beyond the immediate Guzzle consumer. Confidentiality and availability are not directly impacted by the cookie injection itself.

Frequently asked questions