CVE-2026-59883: Guzzle Cookie Domain Validation Flaw Enables Session Hijacking

Technical summary

The vulnerability resides in the SetCookie::matchesDomain() method, which handles cookie domain validation. For IP-address-scoped cookies (IPv4, IPv6, or bare numeric domains), the method applies suffix-matching logic designed for traditional domain names. This is incorrect because IP addresses and numeric identifiers do not support domain suffix relationships—192.168.0.1 should never match 192.168.0.2, and [::1] should never match [::2]. The suffix-matching logic allows a cookie set by one IP to be reused when communicating with a different IP, or allows an attacker to inject a cookie into requests sent to an unintended host. The fix, introduced in version 7.12.3, enforces exact-match validation for IP-address and bare-numeric domain values, while preserving suffix-matching for traditional domain names. The issue is classified under CWE-346 (Origin Validation Error) and CWE-384 (Session Fixation).

Business impact

Organizations relying on Guzzle in multi-tenant or sensitive-credential environments face three primary risks: (1) unauthorized cross-host cookie leakage, where session tokens or authentication cookies meant for one service are disclosed to another; (2) session fixation attacks, where an attacker injects a known session cookie into a victim's requests; (3) credential compromise in scenarios where cookies store authentication material or sensitive tokens. The impact is heightened in microservices architectures, API gateways, and cloud-native environments where multiple hosts with IP-based routing are common. Affected organizations should prioritize patching if they use Guzzle to communicate with multiple IP-based endpoints or services that rely on cookie-based authentication.

Affected systems

The vulnerability affects Guzzle versions prior to 7.12.3. Any PHP application or library that depends on Guzzle for HTTP requests and uses cookie handling is potentially at risk. This includes web applications, API clients, webhooks, and middleware that authenticate or maintain session state via cookies. The risk is amplified if the application communicates with multiple hosts identified by IP address rather than domain names, or if cookies are scoped to bare numeric or IP-address values in the application's cookie policies.

Exploitability

Exploitation requires user interaction (a victim must visit or interact with an attacker-controlled page or service), making this a medium-complexity attack. However, the bar for user interaction is low—simply visiting a crafted webpage or clicking a link can trigger the vulnerability. An attacker does not need elevated privileges or network access to the target system; they only need to host a malicious page that causes the victim's browser to make requests to multiple IP-based hosts. Once exploited, the attacker can steal cookies or inject malicious session identifiers into requests, leading to account takeover or privilege escalation. The vulnerability is not currently listed in the CISA KEV catalog, indicating it has not yet been observed in active exploitation in the wild.

Remediation

Organizations using Guzzle should upgrade to version 7.12.3 or later as soon as possible. This version includes the fix to enforce exact-match validation for IP-address and bare-numeric domains. Before upgrading, audit your application's Guzzle usage and identify which services or endpoints are contacted via IP address. Verify that your application's cookie policies correctly scope cookies to the intended hosts. If you cannot upgrade immediately, consider implementing network-level mitigations such as restricting Guzzle's ability to communicate with untrusted IP ranges or disabling cookie persistence for IP-based endpoints if not strictly necessary for your use case.

Patch guidance

Update Guzzle to version 7.12.3 or a later version through your package manager (Composer for PHP). Run 'composer update guzzlehttp/guzzle' to pull the patched version. After updating, test your application's HTTP client functionality, particularly any flows that use cookie-based authentication across multiple hosts or IP-based endpoints. Verify that session tokens and authentication cookies are correctly scoped and not leaked across unintended hosts. If your application pins Guzzle to a specific version, update your composer.json to allow version 7.12.3 or higher, then run 'composer update'. Check that any custom cookie jar implementations or cookie handling logic also enforces exact-match validation for IP-address domains.

Detection guidance

Monitor application logs and HTTP traffic for anomalous cookie usage patterns, such as cookies being sent to hosts or IPs other than their intended recipients. Network-level detection is difficult, but application-level monitoring can flag cases where cookies scoped to one IP are being sent in requests to different IPs. Inspect Guzzle's CookieJar configuration in your codebase—look for any custom cookie handling or cookie jar implementations that may not correctly validate IP-address domains. Review request logs to identify any unexpected cross-host cookie sharing or repeated session fixation attempts. Consider instrumenting your HTTP client to log cookie domain validation decisions, enabling faster detection if a vulnerable version is compromised.

Why prioritize this

This vulnerability merits immediate attention for organizations in sensitive domains (finance, healthcare, e-commerce) or those with multi-host, IP-based service architectures. The CVSS score of 4.7 (MEDIUM) reflects the required user interaction, but the practical impact—session hijacking, credential theft, and unauthorized access—can be severe. The absence from the CISA KEV catalog suggests it is not yet weaponized, providing a window to patch before exploitation becomes common. Prioritize patching for internet-facing applications and those that authenticate users via cookies across multiple IP-based services.

Risk score, explained

The CVSS 3.1 score of 4.7 (MEDIUM severity) balances a network-accessible attack vector with the requirement for user interaction and limited confidentiality/integrity impact. The score does not account for availability impact; the vulnerability cannot directly cause a denial of service. The score reflects a scenario where a user must visit or interact with an attacker-controlled resource to trigger exploitation, making widespread, worm-like propagation unlikely. However, in targeted attacks against organizations with sensitive authentication schemes, the practical risk is higher than the base score suggests. Organizations with IP-based multi-host architectures should weigh the reputational and compliance costs of session theft above the base CVSS rating.

Frequently asked questions