Am I affected by PHP2Shell?

What PHP2Shell exposure actually means

The question is not whether PHP2Shell exists in the abstract, but whether your runtime matches the vulnerable PHP branches and server interfaces it can reach. That means checking the PHP version first, then confirming whether the affected code is present in a live web execution path, especially on exposed web-facing services rather than unused installations or development images.

For PHP2Shell, exposure is a deployment question as much as a version question. A host can be vulnerable on paper and still be lower priority if the affected SAPI is not in use, but a container, appliance or bundled product that quietly ships the affected PHP build should be treated as in-scope until you verify otherwise.

If you need a practical starting point, treat the PHP build, the SAPI, and the packaging source as the minimum triage set. That gives you the fastest answer on whether the issue is present in production, in a replica environment, or only in an installed component that never handles requests.

Where the vulnerable path tends to exist

PHP2Shell is only relevant where PHP is actually processing requests through one of the affected interfaces. The direct answer already names PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, so the key operational task is to map those interfaces to real application entry points rather than assuming every PHP installation is equally exposed.

That mapping matters because many environments contain more than one PHP execution path. A host may have hardened one path while a different pool, virtual host, sidecar or appliance component still serves user traffic with the vulnerable runtime, which is why a version check alone is not enough.

Packaged products deserve special attention because they often hide the underlying PHP dependency from the operator. In those cases, the useful question is not just “What does my server say?”, but “Which product bundle, image layer, or appliance update channel actually controls the PHP build in service?”

How to decide if you should treat the system as affected

The safest decision rule is simple: if you run one of the listed PHP branches in the named SAPIs and you have not confirmed the fixed build or a backported distribution patch, treat the system as affected. That is the right default for internet-facing applications, shared hosting, staging systems that mirror production, and packaged services that may inherit the same runtime.

For older end-of-life branches, the burden shifts to the distribution or vendor. If your platform no longer receives fixes from the PHP project, you need explicit confirmation of a backported patch before you can call the system remediated.

If patching is delayed, the exposure decision should include the full blast radius, not only the web application itself. A vulnerable PHP runtime in a container, appliance or third-party product may still expose administrative consoles, internal workflows, or automation hooks that were never meant to be reachable from the public internet.

Risk and Threat Considerations

Unpatched PHP execution paths create direct remote-code-execution risk, which means compromise can move from a single request to application takeover quickly. The practical danger is highest where the same runtime also handles authentication, session state, file uploads or administrative functions, because those paths expand what an attacker can reach after initial exploitation.

Failure mechanism: The vulnerable PHP build is still reachable through an active SAPI or bundled product, so an attacker can trigger the flaw before defenders notice that the runtime is outdated or inherited from a package rather than installed directly.

Impact: Successful exploitation can lead to code execution in the application context, follow-on access to local secrets or service credentials, and broader compromise if the host shares trust with other services or deployment environments.

Practitioner Guidance

What to verify: Confirm the exact PHP version, the active SAPI, and whether the runtime comes from an OS package, container base image or vendor bundle. Then compare that inventory against the vendor advisory and the NIST National Vulnerability Database record for corroborated version and product data.

Decision rule: If you cannot prove that the affected runtime is fixed or backported, treat it as exposed and prioritise remediation over further tuning. For packaged products, the owner of the bundle, not the app team alone, is usually the party that can confirm the patch status.

What to do if patching must wait: Reduce exposure by removing unnecessary internet reachability, isolating the affected service, and reviewing whether the runtime has access to secrets, session stores or privileged local resources that would increase the value of exploitation.

Practitioner takeaway: The fastest safe answer is not “Is PHP installed?”, but “Is this exact PHP build reachable in a live request path, and do I have proof that the bundle or distribution has already fixed it?”

Related resources from NHI Mgmt Group

• Guide: PHP2Shell
• How should organisations govern access when identity controls are spread across IGA, AM, and PAM?
• How do security teams prioritise Linux kernel fixes when multiple distributions are affected?
• Why do support environments matter to identity governance if production was not affected?
• Who is accountable for DDoS resilience when identity and access services are affected?