Cookie Injection Risk in Guzzle PHP HTTP Client

Compliance Impact

This vulnerability allows an attacker to inject cookies or perform session fixation attacks by exploiting how Guzzle's CookieJar accepts cookies with dot-only Domain attributes. Such attacks can lead to unauthorized access or manipulation of user sessions.

Depending on how downstream services interpret the injected cookies, this could result in unauthorized data access or session hijacking, potentially violating data protection requirements under standards like GDPR or HIPAA that mandate strict controls over user data and session integrity.

Applications using Guzzle's cookie support and sharing cookie jars across trusted and untrusted origins are at risk, which may impact compliance by exposing sensitive data or user sessions to attackers.

Mitigations include upgrading to Guzzle 7.12.1 or later, avoiding reuse of the same CookieJar across trust boundaries, or disabling cookie handling for untrusted hosts, which help maintain compliance by preventing unauthorized cookie injection.

Useful 0 Not Useful 0

Executive Summary

This vulnerability exists in Guzzle, a PHP HTTP client, in versions prior to 7.12.1. The issue is that the CookieJar component incorrectly accepts cookies with a domain attribute consisting only of dots (e.g., Domain=., Domain=..), or with whitespace-padded variants. Internally, the domain matching function removes leading dots, turning these dot-only domains into an empty string. However, the validation function only rejects strictly empty domains, so these cookies are accepted and stored.

Because the normalized domain is empty, the cookie is treated as matching any request host. This means an attacker controlling an origin that an application requests with a shared cookie jar can set a cookie that Guzzle later sends to unrelated hosts using the same jar. This can lead to cookie injection or session fixation attacks against downstream services, depending on how those services interpret the injected cookie.

The vulnerability is fixed in Guzzle version 7.12.1, where dot-only cookie domains are rejected to prevent empty normalized domains from matching any request host.

Useful 0 Not Useful 0

Impact Analysis

If your application uses Guzzle's cookie support and shares the same CookieJar across both trusted and untrusted origins, an attacker can exploit this vulnerability to inject cookies from an untrusted origin.

This can lead to cookie injection or session fixation attacks against downstream services. Specifically, the attacker can cause Guzzle to send malicious cookies to unrelated trusted hosts, potentially hijacking sessions or manipulating user state.

Applications that do not use cookie support or that isolate cookie jars per origin are not affected.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability occurs when Guzzle's CookieJar accepts cookies with a dot-only Domain attribute or whitespace-padded variants, which are then normalized to an empty string domain and sent to unrelated hosts. To detect this on your system, you should inspect HTTP traffic for cookies with suspicious Domain attributes such as Domain=., Domain=.., Domain=..., or those with whitespace padding.

You can monitor network traffic using tools like tcpdump or Wireshark to capture HTTP headers and look for such cookie domains.

• Use tcpdump to capture HTTP traffic: tcpdump -i <interface> -A 'tcp port 80 or tcp port 443'
• Filter captured traffic for Set-Cookie headers containing dot-only or whitespace-padded Domain attributes.
• If you have access to application logs or debugging output, check for cookies being set or sent with unusual Domain attributes.

Additionally, review your application's use of Guzzle to see if it uses a shared CookieJar across trusted and untrusted origins, which is a key condition for this vulnerability.

Useful 0 Not Useful 0

Mitigation Strategies

To mitigate this vulnerability immediately, upgrade Guzzle to version 7.12.1 or later, where the issue with dot-only cookie domains is fixed.

If upgrading is not immediately possible, apply the following workarounds:

• Avoid reusing the same CookieJar instance across untrusted and trusted origins.
• Use separate CookieJar instances per trust boundary to prevent cookie injection across domains.
• Disable cookie handling for requests to untrusted hosts by configuring Guzzle clients accordingly.

Useful 0 Not Useful 0