GHSA-wm3w-8rrp-j577

Impact

In affected versions, CookieJar does not preserve whether a response cookie was set without a Domain attribute or with an empty one. A cookie without Domain is host-only and must be returned only to the exact host that set it. Under current cookie processing rules, an empty Domain value is also host-only. Guzzle instead stores the request host in the cookie's Domain field and later applies ordinary domain matching, as though the server had supplied a valid domain. For example, a host-only sid=secret cookie set by example.com can subsequently be sent to child.example.com. FileCookieJar and SessionCookieJar also persist the request host without recording the host-only state, so reloading a jar preserves the widened scope.

An attacker who controls or can observe a child host can therefore receive cookies that were intended only for its parent host. Depending on the cookie, this can disclose session identifiers, authorization tokens, or other sensitive state. Exploitation requires the application to enable Guzzle's cookie support, reuse the same built-in cookie jar, receive a host-only cookie from a parent host, and later make a matching request to a less-trusted child host. The cookie's other restrictions still apply. Its path must match, a Secure cookie is sent only over a secure connection, and an expired cookie is not sent.

Applications that do not use Guzzle's cookie support are not affected. Applications are also not affected by this disclosure if they use a separate jar for every host or trust boundary, never request a less-trusted subdomain with the same jar, or only store cookies carrying a valid, non-empty Domain attribute. The incorrect behavior occurs between an otherwise valid parent host and its subdomains.

Patches

The issue is patched in 7.15.1 and later. Starting in that release, Guzzle records whether a response cookie is host-only and matches it only against the exact host. The host-only flag is part of...