Vulnerability · CVE-2026-82416
FrankenPHP: Cross-request PHP session ID leak in worker mode when the session extension is a shared module
Published Oct 15, 2026 · catalog updated Oct 15, 2026 · FrankenPHP: Cross-request PHP session
Check if you run it
No confirmed exploitation is on record for CVE-2026-82416. EPSS is 0.23%. Act only if a listed version of FrankenPHP: Cross-request PHP session is installed.
Gaps on this record
- The stored product name is a package slug. The name on this page is taken from the title (FrankenPHP: Cross-request PHP session).
- No vendor fix or required action is stored. Compare the linked advisory before you change production.
- Severity
- High7.7
- Known exploitation
- Not in CISA/VulnCheck KEV
- EPSS
- 0.23%
- Remediation
- Version ranges on file
- Affected products
- go github.com/dunglas/frankenphp · golang github.com
## Summary In worker mode under concurrency, FrankenPHP can hand a PHP session id from one request to another when PHP's extension is loaded as a shared module instead of being statically linked into the FrankenPHP binary. A request presenting can have resolve to (a different concurrent client's id) or to a stale id from a previous request served by the same worker thread. ## Impact - **Security:** cross-user session exposure / session hijacking in worker mode. Same impact class as CVE-2026-24894. - **Functional:** users are intermittently logged out; their cookie's session is ignored and they receive a foreign or empty session. ## Affected / not affected Exposure is determined by how the extension is linked in the PHP build FrankenPHP is compiled against, **not** by the FrankenPHP release: - **Affected:** any build where the extension is not visible to FrankenPHP at compile time, i.e. loaded as a shared / out-of-tree module ( in an ini). This includes the RPM and Debian packages and other packaged distributions that ship as a shared extension under . - **Not affected:** builds where is statically compiled into the PHP that FrankenPHP links against, such as the official static binaries and Docker images. There, the reset code below is compiled in and clears the id every request. The C session-reset code is unchanged across 1.11.x-1.12.x, so this is not a code regression between releases. A "1.12.2 works / 1.12.3 leaks" observation on the same host reflects two differently-built packages, not a source change. The persistent-zval helpers (#2366) are compiled only under and are unrelated. ## Root cause FrankenPHP resets per-request session state in , which releases so the next re-reads the request cookie. That whole function is guarded by , a macro defined only when the session extension headers are present at FrankenPHP compile time (session statically enabled in the PHP build). When is a shared module, is undefined, the reset is compiled out, and survives the request
Are you affected?
Enter the version you run. The result uses only the ranges stored on this record.
The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.
- go github.com/dunglas/frankenphp<= 1.12.4
- golang github.comversion unspecified
How to fix CVE-2026-82416
Recommended remediation
Affected version ranges suggest a fixed boundary. Verify against the vendor advisory for your release.
Official advisories
What to do
Three questions, each answered from this record only. Confirm the vendor advisory before you patch.
Should you patch?
No confirmed exploitation is on record for CVE-2026-82416. EPSS is 0.23%. Act only if a listed version of FrankenPHP: Cross-request PHP session is installed.
Which versions are affected?
Compare what you have installed with <= 1.12.4. Compare the installed version with the linked vendor advisory before you change production.
What should an analyst verify?
CWE-362: Race Condition; CWE-488. EPSS 0.23%. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.
Code
The project this record applies to. Exploit listings stay in References.
Timeline
Detection, updates, and resolution for this record.
Oct 15, 2026 · GitLab Advisory Database
Detected
In worker mode under concurrency, FrankenPHP can hand a PHP session id from one request to another when PHP's session extension is loaded as a shared module instead of being statically linked into the FrankenPHP binary. A request presenting Cookie: session=A can have session_id() resolve to B (a different concurrent client's id) or to a stale id from a previous request served by the same worker th
Oct 15, 2026 · GitHub Advisory Database
Updated
## Summary In worker mode under concurrency, FrankenPHP can hand a PHP session id from one request to another when PHP's extension is loaded as a shared module instead of being statically linked into the FrankenPHP binary. A request presenting can have resolve to (a different concurrent client's id) or to a stale id from a previous request served by the same worker thread. ## Impact - **Security:*
Sources
- CVE.orgVulnerability recordCVE-2026-82416
Official CVE identifier
cve.org - FIRST EPSSExploitation probabilityCVE-2026-82416
30-day exploitation probability 0.2%
first.org - GitHub Advisory DatabasePackage advisoryGHSA-v3ph-cgqh-r8p5
FrankenPHP: Cross-request PHP session ID leak in worker mode when the session extension is a shared module
github.com - GitLab Advisory DatabasePackage advisoryCVE-2026-82416
In worker mode under concurrency, FrankenPHP can hand a PHP session id from one request to another when PHP's session extension is loaded as a shared module instead of being statically linked into the FrankenPHP binary. A request presenting Cookie: session=A can have session_id() resolve to B (a different concurrent client's id) or to a stale id from a previous request served by the same worker th
advisories.gitlab.com
References
Freshness
Last verified in this catalog Oct 18, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.