PHP2Shell: The PHP Runtime Flaw Your Patch Process Probably Can't See

On October 21, 2026, the PHP project shipped emergency fixes for two critical remote code execution flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell. Both carry a CVSS v4.0 score of 9.2. Both live in the PHP runtime itself, not in a plugin, a theme or your application code.

That last point is the one security leaders need to absorb quickly. Updating WordPress, Drupal, Laravel or Magento does nothing for this. The language runtime underneath them has to be patched, and in many organizations nobody owns a complete list of where that runtime lives.

This post covers what is confirmed, what is still disputed, and what a GRC program should do this week.

What Happened

The two CVEs describe memory-safety problems in how PHP handles failures, especially running out of memory in the middle of a request. In one case PHP can continue cleanup with data that was only partly set up. In the other, internal state from a finished request can survive and be reused by a later request handled by the same worker.

According to the vendor write-ups, the outcomes include leaking memory from other requests (which can hold passwords, tokens and API keys) and unauthenticated remote code execution, triggered by a request that never reaches your application code. Wiz says it demonstrated working exploits against current WordPress, Drupal and Joomla container images during its research.

One important caveat on exposure: the headline claim that this affects 70 percent of the internet reflects PHP's market share, not a measured count of vulnerable servers. Whether a given system can be exploited depends on version, configuration and how PHP is deployed. Apache with mod_php is described as the highest-risk setup.

Timeline

August 19, 2026: Wiz researchers discover the flaws and report them to PHP on August 24.
Separately: AI security firm Calif says it found the bugs independently using an OpenAI model.
October 20: The embargo leaks. Details and a demonstration spread, and watchTowr publicly confirms the flaws are real.
October 21: PHP moves its release up and publishes fixed versions. Cloudflare had already begun rolling out WAF protections hours earlier.

Fixed Versions

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

PHP 8.1 and earlier are out of regular support. The PHP security team published source-level backports for 7.4, 8.0 and 8.1, and Linux distributions and LTS vendors have been shipping their own patched packages, sometimes without changing the visible version number. Reports say every release back to PHP 5.4 may be affected, though PHP has not confirmed a full version range.

After patching, restart Apache, PHP-FPM and any long-running PHP workers. A patched package on disk does not protect you until the running process is replaced.

Is It Being Exploited?

The honest answer on October 21 is that sources disagree, and the picture is moving fast.

watchTowr says it is observing active exploitation attempts. Aikido and Patchstack reportedly say the same.
Cloudflare says it saw attack traffic after the leak, with attackers adjusting payloads to get around its rules.
CISA said it had not observed exploitation and had not added either CVE to its Known Exploited Vulnerabilities catalog at the time of reporting.
Wiz and Imperva said they had not observed in-the-wild exploitation in their own monitoring.
Unverified exploit code is circulating. Treat anything downloaded from forums or social media as untrusted, because fake exploits are a well-known way to deliver malware to defenders.

For risk decisions, the distinction barely matters. A public demonstration, a leaked embargo and a bug that needs no authentication are enough to plan as if exploitation is imminent.

The AI Angle

These flaws are reportedly decades old. What changed is the cost of turning them into working attacks. Wiz argues that frontier AI models lowered the effort needed to chain several bugs and adapt them across PHP versions and memory layouts. That claim comes from the vendor and has not been independently verified, but it matches a pattern we keep seeing: the gap between a long-standing weakness and a weaponized one is shrinking.

It also shows the defender side of the same coin. AI-assisted research is how these bugs were found and reported before attackers used them, which is the better outcome.

Why This Is a GRC Problem

The technical fix is simple: patch and restart. The hard parts are organizational, and they are exactly what auditors and regulators care about.

1. Do you know where PHP runs?

PHP hides inside things that do not look like PHP servers: hosting control panels such as cPanel and Plesk, appliances, bundled vendor products, internal admin tools and forgotten marketing sites. If your asset inventory tracks hosts but not runtimes, you cannot answer the first question leadership will ask: are we exposed?

2. End-of-life runtimes are accepted risk, and now it is due

Researchers estimate hundreds of thousands of internet-facing servers run PHP branches that no longer get regular fixes. If any of yours are among them, this incident is the moment to review whether that risk was ever formally accepted, by whom, and with what compensating controls.

3. Your patch SLA meets a shrinking exploit window

Critical, internet-facing, no authentication required: that profile should trigger your emergency change process, not the monthly cycle. If approvals take days, rehearse the process now rather than during the next incident.

4. Third parties own part of your patching

Shared hosting, managed WordPress and SaaS vendors build their packages after the upstream release. Your third-party risk program should be asking critical vendors for their patch status and timeline, in writing.

5. A WAF is a compensating control, not a fix

Cloudflare, Imperva and others deployed rules quickly, and that buys time. Both Cloudflare and Wiz are clear that it does not replace patching, and rules can miss variants. If you rely on one, document it as a temporary compensating control with an expiry date.

6. Assume memory disclosure is possible

Because some outcomes involve leaking process memory, think about what secrets a PHP worker can reach: database credentials, API keys, cloud roles. Reducing what is stored on the server and what the process can do limits the damage whatever happens next.

Control Mapping

Framework	Relevant control area
NIST CSF 2.0	ID.AM (asset inventory), ID.RA (risk assessment), PR.PS (platform security), DE.CM (continuous monitoring), RS.MA (incident management)
ISO/IEC 27001:2022	A.8.8 Management of technical vulnerabilities, A.8.32 Change management, A.5.19 to A.5.22 Supplier relationships
SOC 2	CC7.1 (vulnerability detection), CC8.1 (change management), CC9.2 (vendor risk)
HIPAA Security Rule	164.308(a)(1)(ii)(A) risk analysis and (B) risk management

Action Plan

Next 24 hours

Build the list of every system running PHP, including containers, appliances and control panels. Start with anything internet-facing.
Patch to a fixed version, or get a vendor backport, and restart all PHP processes. Verify the running version, not just the installed package.
For anything you cannot patch immediately, take it off the public internet, put it behind a VPN or authentication at the edge, or isolate it.
Preserve web and PHP logs before and after patching so you can investigate later.

Next 7 days

Hunt for signs of compromise: PHP or web server processes spawning shells or download tools, new files in web roots, new scheduled tasks or accounts, and unusual outbound connections.
Look for repeated memory-limit errors, unexplained PHP worker crashes and unusually large multipart requests in your logs.
Ask critical third parties for their patch status and keep the responses as evidence.
Rotate credentials and keys that were reachable from any exposed PHP server you suspect was probed.

Next 90 days

Add runtimes and their support status to your asset inventory.
Retire or formally risk-accept every end-of-life PHP branch.
Test your emergency change process against a critical, internet-facing runtime flaw.

Final Thoughts

PHP2Shell is a good stress test because the fix is easy and the visibility is hard. Teams that know what they run, own their runtimes and can push an emergency change in hours will finish this week without drama. Teams that cannot answer where PHP lives will spend the week finding out.

The details are still developing, including exploitation status and the full affected range, so confirm versions and guidance against PHP's own security announcements and your vendors before acting on any single article, including this one.