Symfony is a widely-used PHP framework for developing web apps and APIs. It provides many reusable PHP components that help developers build robust, scalable applications. One such feature is the Symfony HTTP cache system, which acts like a reverse proxy server by caching whole HTTP responses (including headers), improving web app speed and scalability.

CVE-2022-24894 is a security vulnerability in Symfony's HTTP cache feature. This issue could let attackers steal users' session cookies—a critical flaw that might allow session hijacking. In this post, we'll keep the explanation simple and show you how the vulnerability works, why it's a problem, how it can be exploited, and what you can do to protect your applications.

What is the Symfony HTTP Cache System?

Symfony's HTTP cache system stores complete HTTP responses for later reuse, so repeated requests for the same resource don't force your application to generate the response all over again. However, if responses are cached with sensitive headers—like Set-Cookie—then problems can arise.

Normally, authentication and session cookies are personal to each user. Caching a response that sets or reveals a user's session cookie can be disastrous, because the next user might receive those credentials and hijack the other user's session.

What Went Wrong: Root Cause

A change in Symfony's AbstractSessionListener component resulted in certain responses containing a Set-Cookie header—even when the HTTP cache proxy was enabled. The HTTP cache would then cache these responses, including the Set-Cookie header value (which should never be shared!).

So when another client requested the same resource, the cache could return the cached response, complete with the prior user's session cookie. If an attacker made such a request after a victim, they could steal that victim's session and impersonate them on the site.

Summary:

Victim Logs In

The victim authenticates, and the response includes a Set-Cookie: PHPSESSID=abc123; path=/; HttpOnly.

Caching Occurs

Symfony HTTP cache (enabled via HTTP cache proxy like symfony/http-cache) stores the complete response, including the Set-Cookie header.

Attacker Requests the Same Resource

The attacker visits the same URL (say /profile), and the cached response is served—with the Set-Cookie: PHPSESSID=abc123; header still in place.

Session Hijack

The attacker's browser (or attacker's script) saves the victim’s session cookie and can now interact with the web app as if they were the victim.

Here is a basic PHP sample showing the kind of code that could lead to trouble

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\EventListener\AbstractSessionListener;

// Simulate using the session listener
$request  = Request::createFromGlobals();
$response = new Response('Hello User!');

// Session is started
session_start();
$_SESSION['user'] = 'victim';

// The response gets a Set-Cookie header
if ($request->getSession()) {
    $response->headers->setCookie(new Cookie(session_name(), session_id()));
}

// The response is now cacheable
$response->setCache([
    'public' => true, // BAD: this allows any client to get the response
    'max_age' => 600,
]);

// Send response
$response->send();

In real-world apps the kernel events and session management are more complex, but you see the problem: a cacheable HTTP response is sent with a session Set-Cookie header.

Victim's HTTP Response

HTTP/1.1 200 OK
Cache-Control: public, max-age=600
Set-Cookie: PHPSESSID=abc123; path=/; HttpOnly

Hello, Victim!

Receives

HTTP/1.1 200 OK
Cache-Control: public, max-age=600
Set-Cookie: PHPSESSID=abc123; path=/; HttpOnly

Hello, Victim!


Now the attacker is logged in as the victim.

References & Issue Tracking

- Symfony Security Advisory for CVE-2022-24894
- GitHub Security Advisory (GHSA)
- Mitre CVE record
- Symfony Patch PR

Who is Affected?

Any application using the Symfony HTTP cache system and the affected versions of Symfony is at risk. If you’re using Symfony 4.4.x (before the fix), your users’ sessions could be compromised if:

Fix: How Was It Patched?

The Symfony team changed the HTTP cache system to remove session-related Set-Cookie headers from cached responses. Now, even if a response with a Set-Cookie slips through, it won’t be sent to other users.

Update to Symfony 4.4.41 or higher (or any higher fixed version).

The patch ensures that the HTTP cache removes Set-Cookie and other sensitive headers from cacheable responses.

composer update symfony/http-kernel
composer update symfony/http-foundation

- Extra: Review your cache configuration to double-check that sensitive responses are not marked public or otherwise cacheable.

Update your Symfony version — always use the latest maintenance release.

2. Careful Cache Controls: Don’t return cacheable responses containing personalized data or session cookies.

Sample configuration to not cache authenticated responses

// In controller:
if ($this->getUser()) {
    $response->headers->addCacheControlDirective('private', true);
}


Or use private cache-control header for anything that contains sensitive info.

Conclusion

CVE-2022-24894 is a great example of how even well-built frameworks can have dangerous flaws when complex HTTP behaviors (like caching and session handling) interact. If you use Symfony and the HTTP cache, update right away and always be careful with caching whenever user-specific data is involved.

References

- Symfony official security advisory
- GitHub Advisory
- Symfony Patch Pull Request

Timeline

Published on: 02/03/2023 22:15:00 UTC
Last modified on: 02/14/2023 16:24:00 UTC