How do I identify vulnerable PHP runtimes across web servers?

What you need to identify first

Start with complete PHP runtime inventory, not just package checks on a few hosts. A useful assessment spans bare-metal servers, containers, appliances and managed images, then resolves each instance to the exact runtime, package source and deployment mode so you know whether you are looking at a distro package, a vendor build or a bundled component hidden inside another product.

The practical test is whether you can tie each PHP instance to a specific host, image or service owner, and then verify the version from the runtime itself rather than from a stale CMDB entry or template. That matters because the same web server estate can contain multiple PHP copies with different patch states, especially where application stacks, reverse proxies and container images are maintained separately.

For a broader view of PHP estate hygiene, the PHP and WordPress Security Guide is useful because it ties runtime versioning to hardening choices that often affect what you find during discovery.

How to verify whether a runtime is actually vulnerable

Once you have an inventory, compare the discovered runtime against authoritative lifecycle and vendor support data, then confirm whether the build in service is really the one you think it is. A server can report a modern package name while still running an older binary, so validate at the process, module and image layers where possible.

Check for common hiding places: separate PHP-FPM pools, legacy CLI binaries, distro backports, custom compiled builds, container layers and vendor-managed application bundles. If the web tier, scheduler or admin console all point to different PHP binaries, treat the estate as mixed until each path is proven current.

Unsupported PHP versions helps here because version discovery is only useful when it is paired with lifecycle status, backport awareness and a clear upgrade target.

How to reduce false confidence and close the gap

Do not rely on directory names, package metadata or one-off scans alone. Vulnerable PHP often persists because a fleet contains image drift, shared package managers, or application-specific runtimes that never inherit the host patch cycle. The strongest signal is a repeatable method that maps every serving path to the exact runtime actually executing requests.

When you find a vulnerable runtime, also check for adjacent exposure that would make exploitation easier, such as upload directories, web shell persistence paths or weak file permissions around the application root. If the runtime is embedded in a CMS or framework stack, version evidence from the application layer should be confirmed against the underlying interpreter and module set, not used as a substitute for it.

Where PHP is serving dynamic content, the same discovery work should feed response planning if compromise is suspected, because web shells and post-exploitation scripts commonly hide inside the same estate. The PHP web shells guide is a useful companion when discovery shows an exposed or suspicious runtime path.

Risk and Threat Considerations

Vulnerable PHP runtimes are risky because attackers do not need every server to be exposed, only one forgotten instance with network reach and request handling. Mixed estates also create weak visibility, since a modern package on one host can mask an older interpreter elsewhere in the same application path.

Failure mechanism: Stale PHP builds survive in containers, vendor images, sidecar services or unmanaged hosts, then remain reachable through normal web traffic even after the main fleet has been updated.

Impact: Exposure can lead to remote code execution, web shell placement, application tampering or credential theft, especially when the runtime sits behind a public-facing application or handles uploads and admin functions.

Practitioner Guidance

What to prioritise: Inventory first, then prove execution state. A patch report is not enough if you cannot show which binary, module set or image hash is actually serving requests.

What to verify: Confirm the runtime from the process path, FPM pool, container image digest or appliance build, and reconcile that evidence with the host package manager and application owner records.

Decision rule: If any serving path cannot be tied to a fixed release with current support status, keep it on the vulnerable list until you have runtime-level proof, not just package-level evidence.

Practitioner takeaway: The hardest part of identifying vulnerable PHP is not scanning, it is proving which runtime is truly in use when the estate has drift, bundling and shared deployment layers.

Related resources from NHI Mgmt Group

• Why do vulnerable Java web runtimes create such broad impact?
• How should security teams implement SSL/TLS certificate lifecycle management across web servers?
• What breaks when session and token handling is not aligned across web, mobile, and edge runtimes?
• Why do PHP web shells create such high operational risk on public servers?