CVE-2026-24894
Session Data Leakage in FrankenPHP Worker Mode Before
Publication date: 2026-02-12
Last updated on: 2026-02-20
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| php | frankenphp | to 1.11.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-613 | According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization." |
| CWE-269 | The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor. |
| CWE-384 | Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'CVE-2026-24894 is a vulnerability in FrankenPHP versions prior to 1.11.2 when running in worker mode. The issue is that the $_SESSION superglobal is not properly reset between HTTP requests handled by the same worker process.'}, {'type': 'paragraph', 'content': "Unlike standard PHP where the environment is fully torn down after each request, FrankenPHP's worker mode keeps the application in memory and manually resets superglobals. However, the reset logic fails to explicitly remove $_SESSION from the PHP engine's symbol table, causing session data from a previous request to persist and be accessible in subsequent requests before session_start() is called."}, {'type': 'paragraph', 'content': "This means that one client's session data can leak to another client if they are served by the same worker, potentially exposing sensitive information such as authentication tokens, user IDs, or other session data."}, {'type': 'paragraph', 'content': 'The vulnerability was fixed in version 1.11.2 by explicitly deleting $_SESSION from the symbol table during the superglobal reset process, ensuring session data isolation between requests.'}] [1, 3]
How can this vulnerability impact me? :
This vulnerability can lead to session data leakage between different users sharing the same worker process in FrankenPHP. As a result, sensitive session information such as authentication tokens, user identifiers, or personally identifiable information (PII) may be exposed to unauthorized users.
Such leakage can allow attackers or other users to impersonate others, escalate privileges, or access private data unintentionally.
Applications relying on $_SESSION being empty or unset to detect guest users may be bypassed, leading to security logic failures.
Overall, this can compromise user privacy, application security, and trustworthiness.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by testing whether session data leaks between requests handled by the same FrankenPHP worker process. A practical approach is to use a PHP script that sets session data in one client request and then attempts to read that data in subsequent requests from different clients or requests without session cookies.
Specifically, the provided testing method involves a PHP script (e.g., session-leak.php) with actions to set, get, and check session data:
- Use a client (Client A) to send a request that sets session variables (e.g., secret and client_id) and closes the session.
- Use another client (Client B) without a session cookie to send a request that checks if the session is empty without calling session_start(). If session data from Client A is visible, the vulnerability exists.
- Optionally, test abrupt worker exits by setting session data and exiting immediately without closing the session, then verifying subsequent requests do not leak data.
While no specific command-line commands are provided, this testing can be automated using HTTP clients like curl or tools such as Postman to simulate multiple clients and requests to the vulnerable FrankenPHP server running in worker mode.
What immediate steps should I take to mitigate this vulnerability?
The primary and immediate mitigation step is to upgrade FrankenPHP to version 1.11.2 or later, where this vulnerability is fixed.
If upgrading immediately is not possible, workarounds include:
- Ensure that session_start() is called immediately at the start of every request to overwrite any residual session data.
- Manually unset or delete the $_SESSION superglobal at the beginning of the worker loop before processing requests to prevent data leakage.
These steps help prevent session data from leaking between requests handled by the same worker process until the official fix can be applied.