Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 sessionid() resolve to B (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 session extension is linked in the PHP build FrankenPHP is compiled against, not by the FrankenPHP release: - Affected: any build where the session extension is not visible to FrankenPHP at compile time, i.e. loaded as a shared / out-of-tree module (extension=session in an…
Recommended action: Upgrade to 1.12.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/dunglas/frankenphp >= 1.11.2, <= 1.12.2
Fixed in
1.12.3· Vendor fix available
Issue
The splitPos() function in cgi.go misuses golang.org/x/text/search with search.IgnoreCase when the request path contains a non-ASCII byte. Two distinct flaws in that fallback let an attacker mislead FrankenPHP into treating a non-.php file as a .php script. In any deployment where the attacker can place content into a file served by FrankenPHP (uploads, file storage, etc.), this can be escalated to remote code execution by crafting a URL whose path triggers either flaw. This advisory consolidates two independent reports against the same function (the duplicate, GHSA-v4h7-cj44-8fc8, has been closed). Both were reported by @KC1zs4. Details Flaw 1 — Control-flow: stale match after inner non-ASCII fallback In the inner for j loop, when a byte satisfies c = utf8.RuneSelf and splitSearchNonASCII.IndexString(...) returns -1, the loop breaks without setting match = false. The outer code then evaluates if match { return i + splitLen } with match still true, returning a position as if…
Recommended action: Upgrade to 1.12.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
FrankenPHP’s CGI path splitting logic improperly handles Unicode characters during case conversion. The logic computes the split index (for finding .php) on a lowercased copy of the request path but applies that byte index to the original path. Because strings.ToLower() in Go can increase the byte length of certain UTF-8 characters (e.g., Ⱥ expands when lowercased), the computed index may not align with the correct position in the original string. This results in an incorrect SCRIPTNAME and SCRIPTFILENAME, potentially causing FrankenPHP to execute a file other than the one intended by the URI. Details The vulnerability resides in the splitPos() function and its usage within splitCgiPath(). The logic attempts to find the script extension (e.g., .php) in a case-insensitive manner by lowercasing the path: The issue is that the returned idx represents a byte offset within lowerPath. However, splitCgiPath() uses this index to slice the original path: This logic relies on the…
Recommended action: Upgrade to 1.11.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When running FrankenPHP in worker mode, the $SESSION superglobal is not correctly reset between requests. This allows a subsequent request processed by the same worker to access the $SESSION data of the previous request (potentially belonging to a different user) before sessionstart() is called. Details In standard PHP execution, the environment is torn down completely after every request. In FrankenPHP's worker mode, the application stays in memory, and superglobals are manually reset between requests. The vulnerability exists because $SESSION is stored in the Zend Engine's symbol table (EG(symboltable)). While the standard PHP request shutdown (RSHUTDOWN) decrements the reference count of the session data, it does not remove the $SESSION variable itself from the symbol table. FrankenPHP's reset logic (frankenphpresetsuperglobals) previously cleared other superglobals but failed to explicitly delete $SESSION. Consequently, until sessionstart() is called in the new request…
Recommended action: Upgrade to 1.11.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Delayed propagation of security fixes in upstream base images Summary Vulnerability in base Docker images (PHP, Go, and Alpine) not automatically propagating to FrankenPHP images. FrankenPHP's container images were previously built only when specific version tags were updated or when manual triggers were initiated. This meant that if an upstream base image (such as Alpine Linux or official PHP/Go images) received a security patch under an existing tag, the FrankenPHP image would remain on the older, vulnerable version of those base layers. Impact Users pulling FrankenPHP images may have been running environments with known vulnerabilities in underlying system libraries (e.g., libcrypto3) even if they were using the "latest" version of a specific FrankenPHP tag. Specifically, this includes vulnerabilities recently patched in Alpine 3.20.9, 3.21.6, 3.22.3, and 3.23.3, such as CVE-2025-15467 (Remote Code Execution in libcrypto3). Details The issue was a lack of automated "staleness"…
Recommended action: Upgrade to 1.1.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.