PHP2Shell: affected PHP versions, patches, and validation

Sources checked: 29 October 2026. This article contains FailSafe's analysis and proposed validation workflow; linked sources support the reported facts.

PHP2Shell is the name used for two critical PHP vulnerabilities that can allow unauthenticated remote code execution. PHP released fixes on October 21, 2026. Owners need to establish which deployed runtimes are affected, update them, and investigate the period before patching. PHP's popularity does not mean every PHP website is equally exposed.

Which PHP versions contain the fixes?

The PHP team identifies PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as security releases for CVE-2026-109618 and CVE-2026-109619. It says configuration changes do not completely mitigate both issues. Distribution and hosting packages may use backported fixes with different version strings: check the vendor's advisory for the actual installed package. Source: PHP security release announcements.

What does the exploitation evidence establish?

Amazon Threat Intelligence reported an attempt against its MadPot sensors on October 17, four days before disclosure, followed by wider attempts. AWS explicitly distinguishes those observations from proof that each attempt would succeed on a real deployment. An attempted request is an investigation lead, not a confirmed compromise. Source: AWS MadPot analysis.

A response checklist for application owners

1. Build an exposure inventory. Include public applications, administrative interfaces, staging environments, containers, scheduled workers, and appliances that bundle PHP. Record the owner, runtime source, network exposure, and patch decision for each asset.
2. Update what serves traffic. A changed container tag or package manifest does not prove the replacement reached every replica. Compare the deployed image or package evidence across workers and nodes, then restart services as required by the vendor.
3. Preserve evidence before destructive cleanup. Retain relevant access logs, process telemetry, deployment records, and file-integrity alerts. If compromise is suspected, involve incident responders before overwriting the host or losing short-lived logs.
4. Review the full exposure window. Record when the vulnerable service became reachable and when the last vulnerable instance stopped serving. Correlate suspicious requests with process execution and unexpected file changes instead of relying on a request signature alone.

What should post-patch validation prove?

Use three evidence layers: the running software contains the fix; required application behavior still works; and the controls around the application limit unauthorized actions. Test authentication, upload workflows, role boundaries, and error handling using synthetic data in an approved environment. Agree request budgets and stop conditions before active testing.

A dependency inventory answers where vulnerable code may exist. An authorized web application and API penetration test addresses a different question: which reachable behaviors expose the business to risk? Keep the package evidence and the application findings together so remediation owners can distinguish a patched runtime from an unresolved application defect.

Evidence to retain for security reviews

Keep the affected asset list, vendor advisory, change approval, deployment timestamp, running-version evidence, regression results, and unresolved investigation questions. These records can support a security program's SOC 2 or ISO 27001 evidence process; they do not establish that an earlier intrusion never occurred.

For repeatable testing between releases, see how to evaluate agentic pentesting. Businesses evaluating FailSafe on an agreed scope can review the first pentest offer. Emergency patching and incident containment should proceed independently of purchasing an assessment.