PHP2Shell: Two Flaws in PHP Itself, and What to Patch Now

Patching your WordPress plugins won’t save you this time. The two flaws behind PHP2Shell live in the PHP engine itself, below your framework, below your application code, below anything your last code review ever touched.

What happened

On October 21, the PHP project shipped emergency releases: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0 by the PHP security team, and both capable of unauthenticated remote code execution.

The bugs share a root cause. When a request dies abnormally, typically by hitting the memory limit at exactly the wrong moment, PHP can leave half-initialized or stale internal state behind. A later request handled by the same worker trusts that state. An attacker who has shaped the heap gets memory corruption, then code execution. The PHP team rates the risk highest for Apache’s mod_php, where one unauthenticated request can trigger the attack before any application code runs. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are affected as well.

Wiz Research, which reported its findings to PHP on August 24, demonstrated pre-authentication RCE against the latest container images of WordPress, Drupal and Joomla. It also showed that the memory-disclosure variant can leak passwords, tokens and API keys from worker memory without achieving code execution. Wiz says even a bare “Hello World” script on an affected version can be vulnerable. Its headline claim that this touches 70 percent of the web is a vendor’s round number, but PHP’s footprint is large enough that the exact figure hardly matters.

Treat it as exploited

Disclosure did not go cleanly. The CVE IDs leaked on October 20 with a wrong severity score and a wrong release date, so PHP pulled its release forward a day. Calif, one of the reporting firms, then published a proof-of-concept video by mistake, according to the PHP Foundation. The foundation also says Chainguard published patched images about six hours before the coordinated release, breaking the embargo.

The PHP team saw no functional exploits at the time of release. watchTowr says its honeypots have since caught exploitation in the wild as of October 21. Reports citing Amazon telemetry push the first attempt back to October 17, though we have not seen Amazon’s own write-up. Our reading: public proof-of-concepts exist, so plan as if scanning is already underway.

Who is stuck

Official fixes exist only for PHP 8.2 through 8.5. Version 8.1 and older are end of life. Wiz says every release back to 5.4 is affected, and Laravel’s Forge advisory says the bugs date to 2004. Some distributions and vendors are backporting fixes to 7.4, 8.0 and 8.1, so check yours. If you are on 7.x in late 2026, this is the invoice for every upgrade you postponed. That is our opinion, but it is a well-supported one.

What to do now

1. Inventory. Find every PHP runtime you own: production, staging, shared hosting, forgotten containers.
2. Update to a fixed version. Confirm your package manager actually offers it before assuming you are covered. Some repositories lag the release.
3. Rebuild images. A patched host does nothing for a stale container image still running 8.3.34.
4. Don’t count on workarounds. PHP states there are no complete mitigations and updating is the only safe choice. WAF rules from Cloudflare, Fastly and others buy time, not safety.
5. Hunt for signs. Wiz points to unusual multipart requests followed by memory-limit errors or repeated HTTP 500s, oversized or malformed PHPSESSID cookies in responses, and unexplained worker churn. Application logs may show little.
6. Rotate secrets. This one is our advice, not an official requirement. Memory disclosure works without code execution and leaves a thin trail, so we would rotate credentials on any internet-facing PHP host that ran unpatched.

The part nobody wants to discuss

Wiz credits AI models, including Gemini 4 Argon and GPT-5.6 Sol, with finding the flaws and building working exploits, and claims one researcher did in a week what once took a top team months. Wiz sells security products, so weigh that accordingly.

The PHP Foundation’s numbers back up the pressure, though. The security team has published 15 CVEs since July 1 and worked through more than 100 reports that were invalid, duplicates or not reproducible.

The more uncomfortable detail is the foundation’s own admission. Early signs of the memory problem surfaced during a 2024 external audit. Every candidate fix carried trade-offs, from compatibility breaks to changes across third-party extensions, and work stalled for months. The foundation calls that delay a structural failure of its decision process and resources. It took proven exploits from Calif, OpenAI and Wiz to make it a top priority.

Our take: AI is not the story. A known class of memory-safety problem sat in a project run by a few funded developers and some volunteers until someone proved it was exploitable. Tools now find bugs faster for attackers and defenders alike. Deciding on the right fix still takes engineers who know the whole engine, and there are too few of them.

Patch first. Argue about funding afterward.

Source: Wiz Research, The PHP Foundation, PHP 8.5.12 release notes, Laravel Forge advisory, watchTowr