What is PHP2Shell?
Two critical remote code execution vulnerabilities have been found in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS v4.0 score of 9.2 and allow unauthenticated remote code execution. An attacker can run their own code on an exposed web server without logging in.
Both flaws sit in PHP's core request handling. CVE-2026-109618 is triggered when PHP runs out of memory in the middle of a request and leaves internal data in a corrupted state. CVE-2026-109619 lets stale data from one request survive and be reused by a later request on the same worker. In the worst case, a single unauthenticated request is enough, and the attack succeeds before any application code runs. Secure application code offers no protection.
Is PHP2Shell being exploited in the wild?
Details leaked ahead of the planned disclosure, so the PHP security team published an advance notice on 20 October and brought the patch release forward to 21 October. Exploitation attempts have already been observed in the wild.
PHP underpins a large share of websites, including CMS platforms, e-commerce shops, customer portals and internal tools. Because many of these systems are built or operated by third parties, organisations may be exposed through assets they do not manage directly.
Which PHP versions and server configurations are affected?
Every PHP installation that serves web requests should be treated as affected, regardless of version. Servers running Apache with mod_php face the highest risk, because a working exploit has been demonstrated against this setup. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also affected and must be patched.
The PHP project has released fixed versions for its supported branches, 8.2 to 8.5. Because of the severity, the PHP security team has also published minimal source backports for PHP 7.4, 8.0 and 8.1, intended for organisations that build PHP from source. Earlier versions, including PHP 5 and older PHP 7 releases, receive no fix. Some Linux distributions and long-term support vendors offer backported patches for older versions. Otherwise, upgrading is the only route.
How do you fix and mitigate PHP2Shell?
Find and prioritise. Identify every PHP installation across your estate, not just outdated versions. Include shadow IT, marketing microsites and PHP embedded in appliances. Start with internet-facing systems, and within those, servers running Apache with mod_php.
Which PHP versions contain the PHP2Shell security fix?
Patch immediately. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install the patched packages from your Linux distribution or long-term support vendor. Not every third-party or volunteer-maintained package repository has published fixes yet, so confirm that yours has. Rebuild container images rather than patching running containers, and update PHP bundled in appliances and hosted platforms.
Restart and verify. Restart all web servers and PHP worker processes after updating, because the vulnerable code keeps running until you do. Then rescan to confirm that every system runs a fixed version.
Isolate what you cannot patch. Take internet-facing systems on unsupported PHP versions, or systems you can't update today, offline or behind strict access restrictions. PHP has published temporary configuration mitigations, and WAF rules for the known exploit paths are available. These only block known attack paths, must be set in the server configuration rather than by the application, and require a restart of every worker. They are not a substitute for patching: PHP itself calls updating the only safe choice.
Ask your suppliers. Get written confirmation from hosting providers, agencies and SaaS vendors that the systems they run for you are patched.
How should organisations investigate potential PHP2Shell compromise?
Assume compromise and hunt. After patching, look back over the past several months for signs of compromise. Check for web shells, unexpected or modified PHP files, new admin accounts and unusual outbound connections.
Rotate secrets. On any system that may have been compromised, rotate everything the PHP application could access, including database passwords, API keys, tokens and certificates.
Check your reporting obligations. If you are a NIS2-regulated entity or a DORA-regulated financial entity, confirmed exploitation may start incident reporting deadlines measured in hours.
Plan beyond the patch. PHP 8.2 reaches the end of security support on 31 December 2026. Systems patched to 8.2.35 today need an upgrade plan.
How can PwC help with PHP2Shell response?
- Rapid exposure assessment (24 to 72 hours)
We discover your external attack surface, including third-party and hosted assets, and identify PHP-based services and their versions. You get a prioritized list of what is exposed and what to fix first. We will leverage Frontier AI models to conduct this assessment as most attackers do. - Compromise assessment and threat hunting
Our Cyber Defense team hunts for signs of exploitation across your web servers and logs. We look for web shells, persistence, unusual processes launched by PHP, and data exfiltration. We deliver ready-to-deploy detection content for Splunk, Microsoft Sentinel and Google SecOps. - Security Operations Center (SOC) and 24/7 monitoring
Our SOC watches your PHP estate around the clock and acts on suspicious activity as soon as it appears. We onboard your web server, WAF and endpoint telemetry within very short turnaround time. We deploy PHP2Shell-specific detections and escalate confirmed threats directly to your team or our incident responders. If you already run a SOC, we can add surge capacity and detection content for the critical weeks after disclosure. If you don't, short-term emergency monitoring can be the bridge into a long-term managed service. - Incident response
If we find signs of compromise, our IR team contains the incident, investigates it forensically and supports recovery. This includes communication with regulators and stakeholders. - Enhance your resilience and emergency remediation support
PwC can support in enhancing your Operational Resilience by validating Business- and IT-Continuity plans, patch rollout, compensating controls and isolation for systems you can't patch. We also plan secure migration paths for unsupported PHP versions. - Regulatory support
We assess whether NIS2, DORA or GDPR reporting obligations apply, and help you prepare notifications on time. - Beyond this incident: continuous exposure management
PHP2Shell will not be the last critical flaw in a widely used component. We help you build adaptive vulnerability and exposure management, so next time you know within hours where you're affected.
The availability and scope of our services are subject to prior independence and conflict checks. PwC does not assume management responsibility; all decisions, approvals, and responsibility for controls, systems, and regulatory notifications remain with the client. Services for audit clients may be restricted or unavailable.
Affected?
Call our 24/7 emergency hotline: +49 69 9585 9992 or
Follow us
Contact us
