Key points
- CVE-2026-82416 affects FrankenPHP versions 1.12.4 and earlier when the session extension is loaded as a shared module.
- The issue causes cross-user session exposure and intermittent logouts due to stale or foreign session IDs being processed.
- Version 1.12.5 patches the vulnerability, but only builds with statically linked session extensions were originally unaffected.
FrankenPHP version 1.12.5 resolves a high-severity vulnerability that allows session data to leak between concurrent user requests. The flaw, tracked as CVE-2026-82416, impacts systems running worker mode where the PHP session extension is not statically compiled into the binary. Teams using packaged distributions must verify their build configuration to determine exposure.
In plain English
When FrankenPHP handles multiple requests simultaneously, it can mistakenly assign one user’s session identifier to another user’s active session. This occurs if the PHP session extension is loaded as a separate shared module rather than being built directly into the FrankenPHP executable. As a result, a user might see another person’s data or be logged out unexpectedly because the system reads a stale or incorrect session ID from the previous request handled by that worker thread.
The background
The root cause lies in how FrankenPHP resets session state between requests. The function responsible for clearing the previous session ID is only compiled if the session extension is visible at compile time. If the extension is loaded dynamically via an ini file, this reset code is absent. According to the GitHub advisory, this means RPM and Debian packages often ship with the vulnerability, while official static binaries and Docker images remain safe because they include the reset code.
What changes now
Version 1.12.5 provides a fix for this issue. The advisory clarifies that the underlying C code for session resetting has not changed recently, meaning the problem is strictly a build configuration issue rather than a regression in the source code. Observations of the bug appearing in specific minor versions reflect differences in how those packages were compiled, not changes in the FrankenPHP source itself.
Who needs to act first
Teams should prioritize updating systems exposed to the internet, particularly those handling authenticated user sessions. Check whether your deployment uses shared PHP modules, as these are the primary targets. Roll out the update to a small subset of servers first to verify stability before a full deployment. Ensure backups exist before applying changes to production environments. Monitor logs for unusual session behavior during the transition to confirm the fix resolves the mixing of identifiers.
What to do and how to stay safe: FrankenPHP
- Verify if your FrankenPHP installation loads the session extension as a shared module or if it is statically linked.
- Upgrade to FrankenPHP version 1.12.5 or later once the vendor provides the update to all supported platforms.
- Monitor application logs for concurrent session anomalies or unexpected user logouts as indicators of exploitation.
- Restrict access to sensitive endpoints until the patch is confirmed working in your specific build environment.
Step-by-step guide: 7 Configuration Errors That Expose Systems to Zero-Day Exploits
General security guidance from the Vuln Post newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Does this affect all FrankenPHP installations?
No, only builds where the session extension is loaded as a shared module are affected; static builds are safe.
Is there a confirmed fix available?
Yes, version 1.12.5 patches the vulnerability for affected configurations.
Why did some 1.12.x versions work while others failed?
Differences in package compilation, not source code changes, determined whether the reset code was included.
