EUVD-2026-38457
GHSA-cwxw-98qj-8qjx
Severity by source
AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N
Network-delivered attack with no credentials required; scope changes as injected cookies transit to downstream trusted services; integrity impact is limited (cookie injection only, no direct data modification).
Primary rating from Vendor (https://github.com/guzzle/guzzle).
CVSS VectorVendor: https://github.com/guzzle/guzzle
Lifecycle Timeline
2DescriptionCVE.org
Impact
CookieJar incorrectly accepts cookies with a dot-only Domain attribute, such as Domain=., Domain=.., Domain=..., and whitespace-padded variants such as Domain= . . In affected versions, SetCookie::matchesDomain() removes leading dots from the cookie domain, normalizing dot-only values to the empty string; SetCookie::validate() only rejected a strictly empty domain, so these cookies could be stored and the empty normalized domain was treated as matching any request host.
An attacker-controlled origin that an application requests with a shared cookie jar can therefore set a cookie that Guzzle later sends to unrelated hosts using the same jar. This may allow cookie injection or session fixation against downstream services, depending on how those services interpret the injected cookie. Applications are affected when they use Guzzle's cookie support, for example new Client(['cookies' => true]) or an explicit shared CookieJar, and reuse the same jar across attacker-controlled and trusted origins.
Applications that do not use Guzzle's cookie support, or that use separate cookie jars per origin or trust boundary, are not affected. This issue is distinct from public suffix list validation: dot-only domains contain no domain label and should not match unrelated hosts.
Patches
The issue is patched in 7.12.1 and later. Starting in that release, Guzzle rejects dot-only cookie Domain attributes and prevents an empty normalized cookie domain from matching any request host.
Workarounds
If you cannot upgrade immediately, do not reuse the same CookieJar instance across untrusted and trusted origins. Use separate cookie jars per origin or trust boundary, or disable cookie handling for requests to untrusted hosts.
Avoid using new Client(['cookies' => true]) for clients that may contact unrelated hosts with different trust levels, because that option creates one shared jar for the client.
AnalysisAI
Cookie domain validation in guzzlehttp/guzzle before 7.12.1 allows cross-origin cookie injection when a shared CookieJar contacts both attacker-controlled and trusted hosts. The flaw stems from SetCookie::matchesDomain() normalizing dot-only Domain values (e.g., 'Domain=.', 'Domain=..') to an empty string, while SetCookie::validate() only rejected strictly empty domains - meaning normalized-empty domains were stored and silently treated as matching every request host. Any application using new Client(['cookies' => true]) or an explicit shared CookieJar that requests data from an attacker-reachable origin is exposed to session fixation or cookie injection against unrelated downstream services. No public exploit or CISA KEV listing has been identified at time of analysis.
Technical ContextAI
Guzzle (pkg:composer/guzzlehttp/guzzle) is a widely used PHP HTTP client library. The vulnerability resides in two cooperating methods within the SetCookie class: matchesDomain() strips leading dots as part of RFC normalization, which collapses pathological values like '.' or '...' to the empty string '', and validate() only rejects the domain if it was originally empty - never if it became empty after normalization. This is a textbook CWE-346 (Origin Validation Error): the trust boundary between cookie domains and request hosts is broken because the normalization step is applied before the validation guard, creating a bypass. The affected component is the CookieJar subsystem, which is opt-in but enabled by the common idiom new Client(['cookies' => true]). Applications that share one CookieJar across requests to multiple origins - including untrusted third-party APIs - inherit the risk. The flaw is unrelated to Public Suffix List (PSL) validation; dot-only strings contain no domain label at all and should be unconditionally rejected.
RemediationAI
The primary fix is to upgrade guzzlehttp/guzzle to version 7.12.1 or later via Composer (composer require guzzlehttp/guzzle:^7.12.1); this release both rejects dot-only Domain attributes at ingestion time and prevents an empty normalized domain from matching any host. Vendor advisory: https://github.com/guzzle/guzzle/security/advisories/GHSA-cwxw-98qj-8qjx. If an immediate upgrade is not possible, the most effective workaround is to eliminate shared CookieJar instances that span trust boundaries: replace new Client(['cookies' => true]) - which creates one shared jar for the client's lifetime - with per-request or per-origin jars instantiated explicitly, so cookies from untrusted origins are never presented to trusted ones. Alternatively, disable cookie handling entirely for any Guzzle client that contacts untrusted external hosts. Note that these workarounds require code changes and may break existing cookie-relay or session-forwarding logic that relies on the shared jar behavior.
Same weakness CWE-346 – Origin Validation Error
View allSame technique Code Injection
View allShare
External POC / Exploit Code
Leaving vuln.today