PHP2Shell: How to Find and Remediate Vulnerable PHP Runtimes

PHP2Shell is the collective name for two critical PHP runtime vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both can allow unauthenticated remote code execution when a vulnerable PHP installation serves web requests.

The PHP project released fixes on October 21, 2026, in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Its security advisory identifies PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed as exposed runtime models, with the highest stated risk for mod_php. Cloudflare also reported observing attack traffic and changing payloads around the disclosure. This is an inventory and remediation problem now, not a vulnerability to leave for the next routine scan.

This guide explains how to find affected PHP runtimes, prioritize exposed systems, apply fixes, and verify that the vulnerable process state is gone. It complements the complete vulnerability scanning guide. Layer8 Sentinel supports the asset, exposure, and remediation evidence needed to manage this kind of fast-moving vulnerability across a mixed environment.

What PHP2Shell changes operationally

PHP2Shell is not a flaw in one PHP framework, content management system, plugin, or application. The vulnerable behavior is in the PHP runtime itself. Updating WordPress, Magento, Laravel, or an individual plugin does not replace the affected runtime below it.

The two CVEs involve separate failures in request memory handling:

• CVE-2026-109618 can corrupt state when out-of-memory handling interrupts PHP while internal request data is only partially initialized. Cleanup may then use invalid data as if it were valid.
• CVE-2026-109619 can leave request-owned global state pointing to released memory after a fatal error. A later request handled by the same worker may reuse that stale state.

The practical consequences can include process crashes, memory exposure, and remote code execution. An attacker does not need an authenticated application session for the demonstrated attack path.

The NCSC-NL operational repository notes that the risk extends beyond conventional websites. PHP may be embedded in appliances, management interfaces, network products, and vendor applications where the customer cannot update the runtime directly.

Determine whether an asset is in scope

Start with a broad hypothesis: any system that uses PHP to serve HTTP requests may be in scope until current runtime or vendor evidence proves otherwise.

Find PHP from more than one data source

Do not rely on an HTTP response header. Version banners are often disabled, removed by a proxy, or generated by a layer that is not the origin runtime.

Reconcile at least these sources:

• Internet-facing domain and service inventory
• Load balancer, reverse proxy, ingress, and virtual-host configuration
• Host package and process inventory
• Container image manifests and software bills of materials
• Cloud instance and managed-service inventories
• Configuration-management and deployment repositories
• Vendor advisories for appliances and packaged applications
• Application ownership records

The workflow in How to Detect Exposed Services in Your Infrastructure helps establish which listeners are reachable from the internet or another untrusted network. The application-scanning process in How to Scan Web Applications for Security Vulnerabilities provides the complementary route and ownership context.

Inspect the runtime locally

Where credentialed inspection is available, collect evidence from the service context instead of assuming that the interactive shell and web server use the same PHP build.

Useful checks include:

• Installed PHP packages and distribution security status
• Active php-fpm master and worker processes
• Apache module configuration
• CGI or FastCGI handlers
• LiteSpeed or FrankenPHP configuration
• Container image digest and package inventory
• The runtime loaded by each virtual host or application pool
• Process start time relative to the security update
• Vendor package changelog or security notice

The output of php -v can help, but it is not sufficient by itself. A host may contain several PHP branches, a command-line binary may differ from the web SAPI, and a patched package may coexist with workers that have not restarted.

Treat vendor backports correctly

The current upstream fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and older are outside upstream support. The PHP project published minimal source backports for PHP 7.4, 8.0, and 8.1, and operating-system or long-term-support vendors may ship their own corrected packages.

That means a simple greater-than-or-equal version rule will create errors in both directions. For each distribution or product, record:

1. Package source and vendor

2. Installed package release, including vendor revision

3. The vendor advisory or changelog that maps the package to both CVEs

4. Whether the relevant web-serving process loaded the corrected build

5. Whether another unsupported PHP runtime remains on the asset

For appliances and bundled software, do not replace internal PHP components unless the vendor explicitly supports that action. Isolate the interface, reduce reachability, and track the vendor's update while preserving supportability.

Prioritize the response

Every affected runtime needs action, but the execution order should reflect exposure and consequence.

Put these systems first

Prioritize assets with one or more of the following conditions:

• A web-serving PHP runtime is reachable from the internet
• Apache mod_php is active
• The service fronts authentication, payments, administration, or sensitive data
• The PHP worker has broad filesystem, database, or cloud permissions
• The asset is a shared hosting platform or common application tier
• A management interface or appliance embeds PHP
• The owner or runtime version is unknown
• Monitoring shows suspicious failures, memory pressure, worker churn, or requests matching current vendor detections

Do not lower priority merely because the application route normally requires authentication. The PHP advisory states that the demonstrated mod_php path can trigger before application code runs.

Separate vulnerability from incident handling

Patch status and compromise status are different questions. A corrected runtime removes the known vulnerable condition, but it does not prove that the system was not exploited earlier.

Open an incident investigation when telemetry or system state shows credible signs of exploitation. Preserve relevant proxy, WAF, web-server, PHP, process, authentication, and endpoint logs before rotation. Review unexpected child processes, new scheduled tasks, modified web content, unfamiliar accounts or keys, outbound connections, and access to application secrets. Rebuild from a trusted source when integrity cannot be established.

Absence of one published request pattern is not proof of safety. Cloudflare reported that attack payloads were changing while protections were being deployed, so detection should combine current vendor rules with host and workload evidence.

Remediate vulnerable PHP runtimes

Upgrade supported branches

Move supported upstream branches to at least:

| Branch | Fixed upstream release |

|---|---|

| PHP 8.5 | 8.5.12 |

| PHP 8.4 | 8.4.27 |

| PHP 8.3 | 8.3.36 |

| PHP 8.2 | 8.2.35 |

Use the package channel and deployment method already responsible for the runtime. For containers, rebuild from a corrected base image, generate a new immutable digest, scan it, update deployment references, and replace every running replica. Do not retag an old image and treat it as new evidence.

For an unsupported branch, prefer migration to a supported PHP release. If a distribution or product vendor supplies a backport, verify that its advisory explicitly covers CVE-2026-109618 and CVE-2026-109619.

Restart every relevant worker

The update is incomplete until affected processes load the corrected runtime. Restart php-fpm pools, Apache workers using mod_php, CGI services, LiteSpeed, FrankenPHP, containers, or the relevant packaged service according to the architecture.

A package transaction followed by a clean version query does not prove that long-running workers changed. Record process identifiers or container digests before and after the restart, and confirm that no old workers remain behind a load balancer or autoscaling group.

Use mitigations only as temporary controls

When immediate patching is impossible, follow the official PHP guidance for temporary controls. The current advisory includes disabling session.upload_progress, restarting workers, and reviewing memory_limit, post_max_size, and PHP 8.5 fatal_error_backtraces settings.

These controls reduce selected paths; they are not complete fixes. Also consider:

• Restricting the service to required networks
• Removing unused PHP handlers and virtual hosts
• Placing an affected administrative interface behind a VPN or access proxy
• Keeping current WAF protections enabled
• Reducing unnecessary upload functionality and request sizes
• Increasing monitoring for PHP worker failures and abnormal requests

Document each mitigation with an owner, expiration time, and patch dependency. A WAF should remain defense in depth, not closure evidence for the runtime finding.

Verify remediation with current evidence

Use a targeted rescan after the update and restart. The vulnerability remediation verification workflow provides a general structure for turning a remediation claim into a defensible closure decision.

For PHP2Shell, require evidence that answers all of these questions:

1. Did the scan reach the intended asset and web-serving instance?

2. Was the relevant PHP SAPI identified?

3. Does the installed package or image contain a fix for both CVEs?

4. Did every affected worker or container restart onto the corrected build?

5. Were all virtual hosts, pools, replicas, regions, and autoscaling templates covered?

6. Are embedded products tracked through their own vendor advisories?

7. Do external tests confirm that unnecessary exposed services were removed?

8. Was suspicious telemetry reviewed separately from patch verification?

A useful closure record contains the stable asset identifier, application owner, package source, fixed package or image digest, process restart evidence, scan time, scanner perspective, and final analyst decision.

Set a short, risk-based verification target for exposed systems. How to Set Rescan SLAs for Vulnerability Remediation explains how to separate urgency from the mechanics required for a valid scan.

Example response workflow

Consider an organization with public PHP applications, internal administration portals, containerized services, and two appliances with embedded web interfaces.

1. Build the affected population

The security team joins internet-facing service inventory with host packages, container SBOMs, ingress configuration, and appliance records. It identifies public applications first, but keeps internal and embedded runtimes in scope.

2. Validate runtime evidence

Credentialed checks identify each web SAPI and package source. Container findings are tied to immutable image digests. Appliance owners collect vendor advisories instead of attempting unsupported component replacement.

3. Apply risk controls

Public mod_php systems enter the urgent queue. WAF rules remain enabled, unnecessary routes are restricted, and logs are retained. An appliance without a patch is removed from general network reachability.

4. Patch and restart

Supported PHP branches are upgraded. Container images are rebuilt and redeployed. Service owners restart all workers and record the resulting package releases, process start times, and image digests.

5. Rescan and investigate

Targeted credentialed scans confirm package and process state. External scans verify exposure changes. Systems with suspicious worker crashes or unexpected process activity move into incident handling even if the current runtime is patched.

6. Close by asset, not by campaign

Only assets with complete evidence close. Unreachable systems, unpatched appliances, stale replicas, and ambiguous vendor packages remain open with named dependencies and owners.

Common mistakes

Avoid these response failures:

• Updating application code while leaving the PHP runtime unchanged
• Checking only the command-line PHP binary
• Trusting a hidden or absent version banner as evidence of safety
• Ignoring internal interfaces, appliances, or vendor-bundled runtimes
• Treating a vendor-backported package as vulnerable based only on its upstream version string
• Treating a newly installed package as proof that old workers restarted
• Closing a container finding after scanning the registry while old digests still run
• Using WAF coverage as a substitute for the PHP security update
• Closing the vulnerability without assessing credible signs of earlier exploitation
• Waiting for the next monthly scan to verify an exposed critical runtime

Conclusion

PHP2Shell requires fast action, but speed should not weaken evidence. Build the population from network, host, container, and vendor data; prioritize exposed web-serving runtimes; apply supported PHP or vendor fixes; restart every affected process; and verify the running state with a targeted rescan.

Keep temporary mitigations in place while patching, and handle possible compromise as a separate investigation. The response is complete only when every in-scope runtime is either verified on a corrected build or remains explicitly tracked with a compensating control, owner, and deadline.