FrankenPHP is a PHP application server. A production service built with FrankenPHP may show a title for the application it serves, not for the runtime underneath it. That makes runtime and page-title inventories fundamentally different.
The November 5, 2026 count comparison showed exactly that split. The app field returned 4,922 matches, the title field returned 75 and the HTTP body field returned 1,299. All observations used sub_type="all", page 1 and pagesize 1.
The observations
app="FrankenPHP": 4,922 at 2026-11-05T17:49:55Z.title="FrankenPHP": 75 at 2026-11-05T17:49:57Z.http.body="FrankenPHP": 1,299 at 2026-11-05T17:49:58Z.
The app count is the strongest runtime-level observation. It can identify services whose headers, behavior or packaged characteristics cause ZoomEye to assign the FrankenPHP application fingerprint. The title count is much smaller because most business applications have their own page titles.
The body count sits between the two. It may include pages that mention the runtime, documentation and some deployments that expose the name in content.
An app match does not show whether the server runs in worker mode. It also does not show how the PHP session extension was compiled.
The vulnerability condition
CVE-2026-82416 is a cross-request PHP session ID leak in FrankenPHP worker mode. It affects builds where the session extension is loaded as a shared module rather than being statically linked. Under concurrency, a request can receive another client's session ID or a stale ID from an earlier request.
The advisory lists affected releases up to 1.12.4 but emphasizes that the build is the real exposure question. Official static binaries and Docker images that statically compile session are described as not affected. Packaged php-zts distributions with a shared session module may be affected even if the release number looks familiar.
This limits what an external runtime count can conclude. The scan can identify FrankenPHP candidates. It cannot establish worker mode, extension linkage or patch state.
Creating an actionable candidate set
Use the app query to build the runtime-level population. Join it with organization and hosting ownership. Then ask the application owner whether the service uses FrankenPHP in worker mode and how the PHP build was produced.
Review container images and package provenance. A Docker image that inherits a base image with a shared session module is not safe merely because an upstream label changed. Record the image digest and the PHP build flags where available.
For each confirmed worker-mode deployment, apply the fix, use a static-session build or implement the documented session_id('') workaround. Test with concurrent sessions and strict mode. Then keep the build metadata in the asset record so a future runtime CVE can be assessed quickly.
Detection in the external view
The small title count can reveal pages dedicated to FrankenPHP, such as project pages or admin dashboards. The app count shows how much runtime-specific fingerprinting is visible. Neither view reports session behavior.
If the team sees a sudden change in the app count, check the scanner's classification and the service headers before declaring a deployment change. The same application can move between fingerprints after a release or a configuration update.
Reporting the result
State that 4,922 indexed assets matched the FrankenPHP app fingerprint at the measurement time. State that 75 pages carried the exact title and 1,299 pages contained the body phrase. Do not combine those numbers into an affected-server total.
The next step is a build inventory. For runtime vulnerabilities, the application name is often less important than the compiler, linked extensions, worker setting and package distribution. ZoomEye can find the runtime footprint. The owner must supply the conditions that determine exposure.