PHP2Shell: Critical PHP RCE Fixes and a QA Verification Checklist

Checked on 22 October 2026. This report covers the PHP2Shell disclosures of 21 October and separates published security evidence from our recommended QA workflow.

What happened?

PHP released emergency updates on 21 October 2026 for two critical vulnerabilities that can permit remote code execution without authentication. Its advisory treats PHP installations serving web requests as at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. A demonstrated mod_php attack can run before application code, so application login alone does not remove the exposure. See the PHP security announcement.

The two issues are collectively called PHP2Shell. Their mechanisms differ:

Which PHP versions contain the fixes?

The first fixed upstream releases are:

Use these releases or subsequent security updates on the appropriate branch. PHP 8.1 and older no longer receive normal upstream updates; some vendors provide backports. PHP says configuration changes only reduce particular attack paths: updating is the complete remedy. Follow the official update and mitigation guidance.

Distribution packages need a different check. Ubuntu lists its PHP 8.3 fix for Ubuntu 24.04 as package revision 8.3.6-0ubuntu0.24.04.13. That illustrates why comparing only the base interpreter version with the upstream table can misclassify a vendor-patched installation. Check the full package revision against the current bulletin for the exact operating-system release. Ubuntu also notes that applications need to use the updated components through an appropriate restart or reboot. See Ubuntu's fix announcement.

What is known about attacks?

AWS reports a PHP2Shell exploitation attempt in its MadPot honeypot telemetry dated 17 October, four days before public disclosure, and further attempts on 21 October. AWS says it is unclear whether the earlier attempts would have succeeded against real-world systems; it also reports broad exploitation after disclosure. This is evidence of attacker activity, not proof that every exposed application has been compromised. See the AWS threat-intelligence report.

The ENISA joint statement urges organisations to identify PHP applications, coordinate with providers and prioritise internet-facing systems. It recommends considering public-network isolation where prompt remediation is impossible. It also highlights products with embedded PHP and points to the NCSC-NL software inventory.

Our recommended QA verification checklist

The checklist below is our editorial workflow for coordinating a patch release. Assign patch deployment and incident assessment to the relevant operations and security owners.

1. Inventory the serving runtime. Record the application, owner, PHP branch, web-server interface, full package revision or image digest, and exposed environments. Include hosted CMS installations and appliances. Checking a developer laptop or command-line interpreter does not establish which build handles web traffic.
2. Verify every deployed instance. Attach vendor patch evidence to the release record, rebuild affected images and follow the service's deployment and worker-replacement procedure. Check that each active replica uses the intended artifact. Keep evidence limited to non-sensitive version and deployment identifiers; avoid publishing diagnostic pages or full configuration dumps.
3. Run bounded regression checks in staging. Cover login, session continuity, logout, permitted uploads, rejected uploads and application error handling. Use synthetic accounts and small fixtures with explicit expected outcomes. This checks whether the patch disrupted business behaviour; it does not reproduce or rule out the underlying memory-safety vulnerabilities.
4. Check request isolation where it matters. In a controlled environment, alternate separate test users through session-sensitive journeys and verify each sees only their own state. Include normal recovery after a handled application error. Record the deployment and test data so unexpected behaviour can be investigated.
5. Keep availability evidence. Compare error rates, worker exits and latency during the rollout with an agreed baseline. Investigate unexpected changes before expanding deployment. Do not turn regression verification into unbounded resource-exhaustion testing on production.
6. Give incident review its own result. Preserve relevant evidence through the organisation's security process and ask responders to assess suspicious process execution, file changes and request patterns. AWS recommends looking back to at least 17 October. Treat that as an investigation starting point, not a guaranteed first-attack date.

What should the release record prove?

Keep three outcomes distinct: the running service has a documented security fix; the selected business journeys still work; and incident responders have assessed possible prior compromise. A green functional suite answers only the selected regression questions. Installing a patch does not by itself establish that an earlier intrusion never happened.

Record who verified each outcome, when, and against which deployment. If a hosting provider owns the runtime, request evidence identifying the fixed package and completed rollout rather than closing the item on a generic “updated” message.

This article reports a developing PHP security event. Recheck the linked vendor advisories before applying operational changes; the checklist does not assert that any particular application has been tested or compromised.