GHSA-WM3W-8RRP-J577: Host-Only Cookie Scope Exposure in Guzzle Cookie Jar

The PHP HTTP client library guzzlehttp/guzzle provides a comprehensive framework for handling synchronous and asynchronous HTTP requests. A core capability of this library is persistent state management, facilitated by various implementations of the CookieJarInterface. Under default operations, a Cookie Jar intercepts standard response headers, parses cookie definitions, and dynamically injects them into outbound requests targeting matching hosts.

This automatic state management introduces a significant security boundary. The client must strictly isolate cookies based on domain boundaries specified by RFC 6265. When a client library fails to respect these boundaries, it exposes an attack surface where highly sensitive cookies, such as active session identifiers, can be inadvertently transmitted to unauthorized endpoints.

This vulnerability represents a classic class of incorrect privilege assignment and cookie scope widening. By failing to track the structural difference between host-only cookies and domain-scoped cookies, the library systematically bypassed origin separation boundaries designed to restrict cookie visibility.

According to RFC 6265 Section 4.1.2.3, the absence of an explicit Domain attribute in a Set-Cookie header obligates the user agent to treat the cookie as a host-only cookie. A host-only cookie must only be returned to the exact host that originally set it, preventing propagation to any related subdomains. Conversely, if a cookie explicitly defines a domain, it is a domain cookie and is sent to both the target host and all subdomains.

In legacy versions of Guzzle, the extraction logic within CookieJar::extractCookies parsed the cookie and, if the domain was empty, simply backfilled it using the current request's hostname. This backfilling operation permanently erased the structural distinction between an explicitly scoped domain cookie and a host-only cookie. Guzzle did not maintain any state flag indicating that this cookie was originally host-only.

Because Guzzle did not retain the historical state of whether the Domain attribute was originally present, subsequent matching operations executed standard domain suffix matching. This resulted in the cookie being matched against any child subdomains, causing cookie scope widening and leading to information leakage when communicating with non-origin hosts.

To understand the technical mechanics, examine the vulnerable implementation in Guzzle's extraction flow before the patch:

// Legacy logic inside extractCookies()
$sc = SetCookie::fromString($cookie);
$domain = $sc->getDomain();
if ($domain === null || $domain === '') {
    // The domain is assigned the request host, but no flag is set to record its host-only nature
    $sc->setDomain($request->getUri()->getHost());
}

The vulnerability was resolved in commit 7b68220d6543f6f80fe62e633361fc9d4ead14d4. The patch introduces a private boolean $hostOnly state tracker inside the SetCookie class, alongside updated matching rules:

// Patched logic in src/Cookie/SetCookie.php
public function matchesDomain(string $domain): bool
{
    $cookieDomain = $this->getDomain();
    if (null === $cookieDomain) {
        return !$this->getHostOnly();
    }
 
    if ($this->getHostOnly()) {
        // Strict, case-insensitive match for Host-Only cookies
        return Psr7\Utils::asciiToLower($domain) === Psr7\Utils::asciiToLower($cookieDomain);
    }
 
    // Suffix matching logic continues for standard domain cookies
}

Additionally, the extraction logic in CookieJar.php was hardened to explicitly flag host-only cookies during parsing:

// Patched logic in src/Cookie/CookieJar.php
$sc = SetCookie::fromString($cookie);
$domain = $sc->getDomain();
if ($domain === null || $domain === '') {
    $sc->setDomain($request->getUri()->getHost());
    $sc->setHostOnly(true);
} else {
    $sc->setHostOnly(false);
}

To prevent state loss between HTTP client cycles, both JSON-based persistent jars (FileCookieJar and SessionCookieJar) were updated to serialize and deserialize the HostOnly flag. Loading an existing cookie database file or session that lacks this marker now throws a RuntimeException to avoid silent regressions.

An exploitation scenario begins with a client application using a vulnerable version of Guzzle. The application communicates with a secure parent site https://example.com which issues a host-only authentication cookie: Set-Cookie: auth=token123; Secure; HttpOnly. The Guzzle client stores this cookie inside its persistent cookie jar.

If an attacker compromises or establishes control over a subdomain (e.g., https://attacker-controlled.example.com), they can exploit Guzzle's scope widening. When the Guzzle client subsequently sends an HTTP request to the attacker-controlled subdomain, Guzzle automatically appends the host-only cookie to the headers because it evaluates example.com as matching the subdomain under legacy rules.

The target interaction and flow can be structured as follows:

Upon receiving the request, the attacker extracts the auth token from the headers, enabling complete session hijacking of the Guzzle client's session on the parent site. This scenario is highly viable in shared hosting environments or platforms that host user-generated content on subdomains.

A key technical limitation of the fix involves the lack of Public Suffix List (PSL) validation. As noted in Guzzle's patched codebase, Guzzle does not natively validate domains against a Public Suffix List because it avoids pulling in a large external dependency. Consequently, if an attacker operates a service on a public suffix subdomain (such as attacker.github.io), they can set a domain-scoped cookie for github.io which Guzzle will accept and forward to other subdomains under the same suffix.

Additionally, developers must manage the risk of the downgrade migration bypass. When Guzzle's updated persistent cookie jars encounter legacy files lacking the HostOnly key, they immediately throw a RuntimeException. If developers write legacy conversion scripts that blindly set the HostOnly field to false to suppress these errors, they will force-disable host-only protection for those cookies, exposing them to scope widening.

Security teams must also audit custom implementations of CookieJarInterface that may have replicated Guzzle's original flawed logic without adopting the new $hostOnly tracking architecture. Custom engines must be updated to explicitly respect host-only boundaries.

Remediation requires upgrading the Guzzle package to version 7.15.1 or higher. This update introduces the necessary schema definitions and code-level checks to strictly enforce host-only rules. System administrators should verify the installed package version using Composer commands.

Because the patch updates persistent cookie store schemas, developers must handle the transition period carefully. Loading existing cookie files using FileCookieJar or SessionCookieJar will trigger a RuntimeException if they do not contain the newly introduced HostOnly serialization key. To prevent application downtime, security administrators should clear or regenerate existing persistent cookie storage files during the deployment of the patched version.

For temporary workarounds where immediate updates are impossible, developers should avoid making requests to parent domains and subdomains using the same shared Guzzle Cookie Jar instance. Separating Cookie Jars per host boundary prevents cross-origin data exposure.