GHSA-F283-GHQC-FG79: Partial fix review for Guzzle cookie jar DoS

Vulnerability

GHSA-F283-GHQC-FG79 describes a denial-of-service condition where a malicious server can cause a client-side cookie jar to accumulate excessive cookie state, eventually producing oversized Cookie request headers that downstream servers reject with HTTP 431/400. The core security property required by the fix is bounded resource consumption: limits on cookie count, size, scope, persistence, or outbound header construction.

The provided patch set from PR #3901 does not show such controls. The visible changes fall into two different areas: redirect Referer sanitization and cookie host-only semantics/persistence correctness. Neither area introduces explicit caps on cookie jar growth or outbound cookie header size.

// Redirect change shown in the patch set
$uri = $request->getUri()->withUserInfo('')->withFragment('');

// Cookie identity change shown in the patch set
private function removeCookie(SetCookie $cookie): void
{
    $this->cookies = \array_filter(
        $this->cookies,
        static function (SetCookie $stored) use ($cookie): bool {
            return !($stored->getName() === $cookie->getName()
                && $stored->getPath() === $cookie->getPath()
                && $stored->getDomain() === $cookie->getDomain()
                && $stored->getHostOnly() === $cookie->getHostOnly());
        }
    );
}

Based on the supplied sources, the patch does not demonstrate mitigation of the advisory’s stated root cause: unbounded cookie storage and header emission.

Patch

The patch content in the referenced pull request contains three substantive themes:

• Redirect Referer hardening: RedirectMiddleware now strips URI fragments in addition to user info before generating a Referer header, and documentation/tests were updated accordingly.
• Cookie host-only identity preservation: SetCookie gains a HostOnly boolean, cookie matching logic distinguishes host-only cookies from domain cookies, and CookieJar removal logic now keys on name + path + domain + hostOnly instead of collapsing those identities.
• Persistent jar format validation: FileCookieJar and SessionCookieJar now persist an explicit HostOnly marker and reject legacy/nonconforming records lacking that boolean.

These changes are technically coherent for cookie correctness and persistence safety. The new tests verify coexistence of host-only and domain cookies with the same name, exact deletion behavior, and persistence/load validation. However, the patch excerpts do not show any of the controls expected for a resource-exhaustion fix, such as:

• maximum cookies per jar or per domain,
• maximum individual cookie size,
• maximum aggregate outbound Cookie header size,
• eviction policy for excess cookies,
• refusal to store attacker-supplied cookies beyond configured thresholds.

Review

Pros

• The cookie model is more RFC-aligned: host-only cookies are now represented explicitly and no longer conflated with domain cookies.
• Deletion semantics are more precise because removeCookie() includes HostOnly in the identity comparison.
• Persistence is safer and less ambiguous: FileCookieJar and SessionCookieJar reject records missing the explicit HostOnly marker, preventing silent reinterpretation of stored cookie scope.
• Tests are strong for the behavior actually changed, especially coexistence and exact deletion of host-only versus domain cookies.
• The redirect fragment stripping change is a legitimate security improvement, as reflected in the updated docs and tests in PR #3901.

Cons

• The patch does not appear to implement any resource bounds relevant to the advisory summary in the GHSA.
• No visible logic limits cookie accumulation in memory, on disk, or in session persistence.
• No visible logic constrains the size of the generated Cookie request header before sending requests.
• The changelog snippets shown are partly unrelated to the stated DoS issue, which makes traceability from advisory to fix weak.
• Rejecting older persisted cookie data without migration may be operationally disruptive, while still not addressing the described denial-of-service vector.

Verdict

Partial fix.

The supplied patch improves cookie correctness and persistence integrity, but it does not, from the provided diffs, remediate the stated denial-of-service mechanism of unbounded cookie jar resource exhaustion. If the vulnerability is accurately summarized by the report and the advisory, then the root cause remains unaddressed unless additional unshown commits add hard limits or eviction behavior.

For a complete fix, engineers should expect explicit enforcement points in cookie ingestion and request emission paths: cap cookie count per origin and globally, cap aggregate header size, reject or evict excess cookies deterministically, and add regression tests that simulate attacker-controlled Set-Cookie floods leading to oversized outbound headers.