Find every PHP runtime that serves a request

01Does this apply to you?

02Steps

Work from the outside in. Each step produces a record you can defend later; if a step cannot be completed, write down the gap rather than filling it with an assumption.

1. Whoever owns DNS and routing

   Start from every name that answers HTTP

   Pull the hostnames from DNS zones, load balancer listeners, reverse proxy virtual hosts, CDN custom domains and the subject alternative names on your TLS certificates. Include redirects, parked domains and names that only resolve internally.

   Map each name to the service behind it. A name that returns a redirect still has an origin, and that origin may be an old stack nobody has opened this year.

   Mark names you cannot explain. An unexplained name is a finding, not a gap to hide.

   You should see A list of hostnames, each with a service name and the person who can explain it.

   If it fails If no inventory exists, start with the certificate transparency logs and DNS zone exports for your domains. Record the method and the date, because the list will be incomplete.
2. Platform engineer

   Identify the SAPI for each service

   The advisory treats SAPIs differently. Apache mod_php was demonstrated exploitable before application code runs. FPM exits a child when request startup fails, but source analysis still indicates exposure after normal startup. FrankenPHP is described as likely susceptible; LSAPI is a conditional candidate.

   Identify what is actually in front of PHP: an FPM pool behind nginx, mod_proxy_fcgi behind Apache, mod_php inside Apache, FrankenPHP, or a LiteSpeed worker. Do not infer it from the application framework.

   A read-only process check is usually enough to start. Confirm the result against the server configuration.

   Read-only process check (Linux) Copy

   ps -eo pid,ppid,lstart,cmd | grep -E 'php-fpm|httpd|apache2|frankenphp|litespeed' | grep -v grep

   You should see Each service is labelled with a SAPI, and the label is supported by configuration or a process listing.

   If it fails If you cannot establish the SAPI, treat the service as unverified and ask the platform owner. Do not assume FPM because the application documentation mentions it.
3. Platform engineer

   Prove the web runtime version, not the CLI version

   On a host, php -v executes the CLI binary. A server can have a patched CLI and an unpatched FPM binary, or the reverse. Check the binary that the service starts, then check that the running process was started from it.

   For FPM, the pool configuration names the binary or the system service does. Confirm the path and version of that binary. For Apache mod_php, the PHP module is loaded into the Apache process, so the Apache restart matters, not a separate FPM service.

   Do not publish phpinfo() to answer this question. A temporary page readable only from localhost or behind authentication is acceptable if you remove it afterwards and record that you did.

   FPM binary and process start time (example) Copy

   command -v php-fpm && php-fpm -v && ps -eo pid,lstart,cmd | grep '[p]hp-fpm'

   You should see The record shows the binary path, its reported version, and the start time of the running master and workers.

   If it fails If the binary path is a versioned path such as /usr/sbin/php-fpm8.3, record the path as well as the version. Package upgrades can leave an old unit pointing at the old path.
4. System administrator

   Record the package source and exact version

   The fix has to come from the source you actually run. A distribution backport can carry a version string that looks older than the upstream fixed version while containing the patch. Comparing bare version numbers across sources produces false conclusions.

   For Debian or Ubuntu, query the installed package and its version. For RHEL-family systems, query the RPM. For containers, record the image digest, not only the tag, because a tag can be moved.

   If PHP is built from source, record the build commit or the patch set, not only the PHP_VERSION string.

   Debian/Ubuntu package versions Copy

   dpkg-query -W -f='${Package} ${Version}\n' 'php*' 2>/dev/null | sort

   You should see Every service has a package name and version, or an image digest, or a source build reference.

   If it fails If the package source is unknown, the service cannot be verified later. Escalate it as an ownership problem before patching.
5. Service owner

   Add the copies people forget

   Check staging and preview deployments, blue-green or canary nodes still attached to a load balancer, administrative panels on separate hosts, scheduled jobs that run a separate PHP container, and backup restores that are reachable from a network.

   Separate HTTP workers from CLI workers in the inventory. The published advisories address web request handling; CLI is not the same exposure path. It still runs the same code and may hold the same credentials, so do not leave it unowned.

   If a system is genuinely out of scope, write down why. “Probably unused” is not a scope decision.

   You should see The inventory includes the forgotten copies, or states why each is excluded.

   If it fails When a copy has no owner, record the gap and the date by which it will be resolved. Do not silence it by deleting the row.
6. Response lead

   Put one accountable owner on every row

   A team name is not an owner. Record a role or an alias that can answer a question about the system, and keep personal data out of the workbook.

   Open the workbook, add one row per business line or system, and record how many distinct fix items are required. Do not count functions, hosts and packages as if they were the same unit.

   Record the unknown rows explicitly. They will drive the questions in the management update.

   You should see Every row has an owner and a fix count, including rows where the answer is still unknown.

   If it fails If nobody will accept ownership, report that as a governance issue. A patch programme without owners stalls at the first legacy host.

03What usually goes wrong

05Where to go next

06Sources and revision

Every operational claim on this page was checked against the documents below on 23 October 2026. This page was last substantively changed on 23 October 2026.

See the full revision log for what changed on this site.