FrankenPHP EUVD-2026-98915

Exploitation requires that the running container is built from a FrankenPHP official Debian or Alpine Docker image PRIOR to 1.12.5 AND that the derived image did NOT overwrite the default /app/public/index.php placeholder (which calls phpinfo()). Deployments that follow the documented pattern and supply their own /app/public/index.php are not affected, and any already-built derived image must be rebuilt or given an application index to remove the placeholder. The limiting factor is therefore this specific non-default deployment state: images with a real application entrypoint, or those rebuilt on 1.12.5+, are not exploitable. Where the precondition holds, no authentication, user interaction, or special network position is needed - a single remote unauthenticated HTTP GET to the web root suffices.

Signals are consistent and point to a genuine but moderate-severity information-disclosure issue rather than a critical priority. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, 5.3) describes remote, unauthenticated, no-interaction access with only low confidentiality impact and no integrity or availability impact - matching CWE-200. Exploitation status is 'no public exploit identified at time of analysis': the input provides no CISA KEV listing and no POC flag. No EPSS score was supplied, so exploitation probability cannot be quantified. The critical caveat is that the CVSS vector assumes an already-vulnerable deployment: per the description the flaw only manifests in images DERIVED from the official FrankenPHP Debian/Alpine Docker images that fail to overwrite the default /app/public/index.php placeholder running phpinfo(). Images built with the documented pattern (shipping their own index.php) are not affected. So while CVSS correctly shows no attacker-side prerequisites, real-world exposure is gated by a victim-side misconfiguration, which materially narrows the affected population and suggests opportunistic rather than widespread exploitation. Practical risk rises sharply if an exposed phpinfo() reveals environment variables holding live secrets (DB credentials, API keys); in that case downstream impact can exceed the base C:L rating, so confirmed exposures should be treated as urgent even though the base score is only Medium.

A developer builds a production image on top of the official FrankenPHP Debian or Alpine base but never replaces the stock /app/public/index.php, so the container serves a phpinfo() diagnostics page at the web root. A remote, unauthenticated attacker simply requests the site root over HTTP and reads back environment variables, loaded extensions, PHP directives, software versions, and system paths - potentially harvesting secrets injected via environment. No public exploit is required; it is a direct, low-complexity HTTP request against a misconfigured deployment.