Guzzle CookieJar host-only domain isolation bypass vulnerability

Vulnerability Overview Vulnerability Name: Host-only cookie scope is not preserved in guzzlehttp/guzzle Vulnerability Description: In affected versions, does not preserve whether response cookies are set as host-only when they lack a attribute or have an empty value. In current cookie handling logic, a cookie without a value is considered host-only and must only be returned to the exact matching cookie host. However, Guzzle incorrectly stores the request host in the cookie's field and applies standard domain matching when the server does not provide a valid domain. For example, a host-only cookie might be sent to , even though it should only be sent to (assuming is the subdomain and the cookie is host-only for the parent). Both and also save affected cookies without recording their host-only status. Attacker Exploitation: An attacker who can control or observe a subdomain may receive cookies that were originally intended to be sent only to the parent domain. If an application enables Guzzle's cookie support, an attacker can leverage the built-in cookie jar to receive host-only cookies from the parent domain and send matching requests to the trusted subdomain. Other Guzzle restrictions still apply: the path must match, cookies are only sent over secure connections, and expired cookies are not affected. Affected Applications: Applications that do not use Guzzle's cookie support are unaffected. Applications are also unaffected if they use a valid, non-empty attribute or only store cookies with a valid attribute. The erroneous behavior occurs between valid parent hosts and their subdomains. Scope of Impact Affected Versions: <7.15.1 Fixed Versions: 7.15.1 and higher Remediation Patch: This issue is fixed in version 7.15.1 and higher. Starting with this version, Guzzle records whether a response cookie is host-only and matches it only with the exact host. The host-only flag is part of the cookie identity, used for replacement and response-driven deletion. Cookies with a valid, non-empty attribute retain their existing domain matching behavior. Host-only cookies can coexist with explicit domain cookies that have the same name, domain string, and path. Improvements to Built-in Persistent Jars: The new persistent jars now write a boolean flag for each stored cookie. They reject records that lack this flag or are not boolean values, and validate all records before loading an old jar. Persistent cookie records written by older versions are therefore rejected rather than silently interpreted in an insecure manner. Data is deleted, regenerated, or correctly annotated when loading an invalid file missing this flag. Versions prior to 7.15.1 are affected. Workaround: If an immediate upgrade is not possible, do not reuse a single instance across parent and child hosts. Use separate cookie jars for each host or trust boundary, disable cookie processing for trusted hosts, or route requests to a client configuration via a shared jar. Specifically, avoid using to create a client that can share cookies across parent and child hosts. Considerations During Upgrade: When upgrading, delete or rotate and data that contains cookie records without the flag. Records can be manually annotated to indicate the original presence or absence of the cookie's attribute. The stored domain string alone is insufficient to infer this securely. References https://www.rfc-editor.org/rfc/rfc1035.html#section-4.1.2 https://www.rfc-editor.org/rfc/rfc1035.html#section-5.2 https://www.rfc-editor.org/rfc/rfc1035.html#section-5.8.3

Goal Reached Thanks to every supporter — we hit 100%!

Guzzle CookieJar host-only domain isolation bypass vulnerability

More from this source