PHP2Shell: two critical RCEs shipped in PHP since 5.4 force an immediate engine patch

October 20, 2026, 15:00 UTC. Two CVE identifiers begin circulating on forums, carrying a wrong CVSS score of 10.0 and a wrong patch date. October 21, 2026, 03:02 UTC. Cloudflare switches on WAF rules against the exploit by default, roughly nine hours ahead of public disclosure. October 21, 2026, 14:00 UTC. The PHP project ships 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix CVE-2026-109618 and CVE-2026-109619, collectively named PHP2Shell. Why it matters: these two unauthenticated remote code execution flaws live in the PHP engine itself and date back to version 5.4 — patching WordPress or your plugins is not enough; the interpreter itself has to be fixed.

Two flaws in the engine core, not in your application

What sets PHP2Shell apart is where it sits. The two vulnerabilities do not touch an application, a framework or a plugin: they live in PHP’s memory management and fatal error handling, paths that nearly every request crosses.

CVE-2026-109618 is out-of-memory corruption. If a request hits PHP’s memory_limit at exactly the wrong moment, the interpreter interrupts its work before some internal structures are fully initialized, then treats that half-built data as valid during cleanup. On Apache with mod_php, an unauthenticated request can trigger the condition before any application code runs — Wiz demonstrated full RCE with default settings. The vector was also confirmed on PHP-FPM through application-level paths.

CVE-2026-109619 is RCE via stale state. A fatal error at the wrong point leaves internal references pointing at memory that belonged to a previous request. A later request handled by the same worker can follow those references into freed memory — a confirmed use-after-free, with worker crash and code execution demonstrated against a real application running on Apache mod_php.

Wiz researchers assembled these primitives into a single exploit script, php2shell, and demonstrated pre-authentication RCE against up-to-date deployments of WordPress, Drupal and Joomla (wordpress:latest, drupal:latest, joomla:latest). Separately, they proved an attacker could read the PHP process’s memory — passwords, tokens and API keys — without even achieving code execution.

Historic reach: 70% of the web

PHP powers roughly 70% of websites, per the W3Techs figures cited by Cloudflare. It underpins WordPress, Drupal, MediaWiki (the software behind Wikipedia) and most hosted CMS platforms. A flaw in the engine core therefore propagates across that entire ecosystem, even when the application code on top is clean.

Wiz draws an explicit parallel with Heartbleed (2014) and Log4Shell (2021): vulnerabilities that overturned a foundational assumption about shared infrastructure. The official score is 9.2 on the CVSS v4.0 scale — critical, but below the 10.0 that leaked on October 20. In the United States, CISA and CERT-EU are tracking the pair through their vulnerability advisory channels; CERT-EU maintains an operational repository for the two CVEs.

A coordinated disclosure, then an embargo break

The timeline matters because it explains why the right move is now, not “in a few days.”

• August 2026. Calif (on the 11th, by researcher Ryan A), OpenAI (the same day), then Wiz (on the 24th) report the flaws to the PHP security team. Quarkslab had already spotted the first signs of the OOM problem back in 2024, during PHP’s first external audit funded by the Sovereign Tech Agency.
• October 20, 2026, 15:00 UTC. The two CVEs leak on forums with a wrong score and a wrong date. No technical details circulate yet.
• October 20, 2026, 19:30 UTC. PHP publishes a pre-announcement and moves the release forward from October 22 to October 21, 14:00 UTC.
• October 21, 2026, 03:02 UTC. Cloudflare switches on its WAF rules by default, including for free accounts, using a new full transaction detection capability that correlates the request with the origin response.
• October 21, 2026, 07:41 UTC. Chainguard unilaterally breaks the embargo by publishing images that already contain the fix — six hours early, handing any attacker a binary diff of the patch while everyone else was still waiting.

The net result: PoCs circulated and were accelerated by a video that Calif mistakenly published around 20:00 UTC on October 20. The PHP security team says it identified no functional exploit at the moment of disclosure, but the gap between “leak” and “patch” is precisely the window where temporary defenses — a WAF — earn their keep.

AI made the exploit practical

The least intuitive part of PHP2Shell is the role of frontier models. The underlying memory bugs had been present for over a decade, but turning them into working exploits required chaining several primitives and adapting each target to its own memory layout — slow, specialist work.

Wiz says it used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol throughout the research, and credits Gemini 4 Argon with an “invaluable” contribution to discovery, exploit development and patch validation. The conclusion is blunt: frontier models lower the barrier between a theoretical flaw and an exploitable one, shrinking the work of adapting an exploit to a new target from days to hours. That is a change in economics, not just a technical advance.

What to do

The instruction is simple, and it cannot be delegated to a plugin.

1. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 — or the fixed build supplied by your distribution. The 8.1 and earlier series have reached end of life and will not receive a patch: they must be migrated.
2. Distributions and hosts. If a hosting provider manages PHP for you, require them to apply the update — Ubuntu, Debian and the vendors’ LTS channels have shipped their packages.
3. Keep the WAF on while patching. Cloudflare, AWS, Fastly and Imperva rules are defense-in-depth, not a substitute for the fix.
4. Shrink the surface while waiting: limit upload sizes and disable unnecessary uploads — these measures reduce exposure without replacing the patch.

One practical check before patching: confirm the PHP version actually serving traffic, not a stale CLI binary. On shared hosting, the web-facing PHP is often newer than php -v suggests, so verify through phpinfo() or the host’s dashboard rather than the shell.

Check your versions with php -v, and if you run containers, rebuild your images: the base image often pins the vulnerable version.

php -v
# If the version is older than 8.2.35, 8.3.36, 8.4.27 or 8.5.12, update.

Verdict

If you expose PHP to the internet, patch today, not this week. Both flaws sit in the engine, not in an application: the only boundary that counts is the interpreter’s version. If you sit behind a managed WAF, treat it as a cushion that buys you a few hours of breathing room, not a fix — the October 20 leak and Chainguard’s embargo break already put the patch in binary form in attackers’ hands. And for teams that assumed a ten-year-old flaw with no public exploit would stay theoretical: PHP2Shell is the proof that AI has moved that line.

References

• PHP Foundation — Today’s PHP Security Release
• Wiz — PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet
• Cloudflare — Cloudflare deploys protections against php2shell vulnerability
• Phoronix — PHP Updates Released For Two Critical Code Execution Vulnerabilities
• PHP.net — security announcements, October 21, 2026