News · Security · November 12, 2026

PHP2Shell three weeks on: what is proven, what is not

PHP runs about 69% of websites with a known language, not 80%. What the reports prove about the PHP flaws: exposed, scanned, exploited and compromised.

DRIVE 369 DAO · 5 min read

Also in: Русский · 中文

Three weeks after PHP shipped fixes for two critical flaws, the story has split in two: the real, serious technical problem, and a set of claims that are bigger than the evidence. Here is what the reports prove, tier by tier. Everything below was checked on November 12, 2026.

What the flaws are

CVE-2026-109618 and CVE-2026-109619 are memory-safety flaws in PHP's core, both scored 9.2 out of 10 by PHP, that allow unauthenticated remote code execution with the web server's privileges (Rapid7, watchTowr, Unit 42). The first is an out-of-memory bug in request handling that crafted multipart uploads can trigger. The second leaves stale state that the next request on the same worker can reuse. Wiz showed it working on default WordPress, Drupal and Joomla images, and says the bug goes back to PHP 5.4. Exploitation depends on how PHP is run: Apache mod_php is the highest-risk case, and PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also in scope according to CISA, Rapid7 and watchTowr.

Fixed releases: 8.5.12, 8.4.27, 8.3.36 and 8.2.35, published on October 21. PHP 7.4, 8.0 and 8.1 got source-only backports, and cPanel, CloudLinux and Ondrej Sury released packages for older lines. A third, related flaw, CVE-2026-115560, was disclosed on October 23 and needs a non-default configuration (Rapid7 recommends turning off session upload progress until a fix lands in PHP 8.6).

The timeline

• Mid 2026: Calif, working under OpenAI's "Patch the Planet" programme, reports unconditional remote code execution; Wiz reports its own find. The PHP Foundation says it began a coordinated fix in September (PHP Foundation).
• October 17: Amazon's honeypots log the earliest exploitation attempt, four days before disclosure.
• October 20: the CVE numbers leak, and PHP moves its release forward.
• October 21: patches ship, Cloudflare deploys firewall rules for all plans, and exploit attempts begin at scale.
• October 26: CISA adds both flaws to its exploited-vulnerabilities list, with a federal deadline of October 29 (CISA bulletin).

A caution on the "AI found it" story: the PHP Foundation says the out-of-memory root cause was noticed in a 2024 audit but not fixed. AI models made the exploit chain fast to build, which is the real change.

Four tiers of evidence

Is 80% of the internet broken?

No. W3Techs shows PHP on 68.8% of websites whose server-side language it can detect (November 12, 2026), and its own wording is that the figure excludes sites where the language is unknown. Headlines say "about 70%". That is a share of usage. It is not the share that is vulnerable, and certainly not the share that is broken. Many of the offline sites were precautionary shutdowns: the Netherlands, Canada, France, Germany and others took government sites down or restricted them while patching, and Mizuho in Japan halted services. Officials in Germany and the Netherlands said they had seen attacks but no successful use.

The honest summary: the weakness is widespread and serious, exploitation attempts are enormous, and successful compromise is real but small and unquantified. Patching was slow: Bitsight found that only 33.5% of previously vulnerable hosts had updated a week after release, and only 6.4% of those on end-of-life branches.

What to do now

1. Update PHP to a fixed release, or a vendor package that contains both fixes, and restart the workers. Rebuild containers from updated images.
2. Run PHP 8.1 or older? Use a backport from your vendor or take the site offline, as CISA advised.
3. Treat the window as open. Patching does not remove a web shell planted earlier. Preserve logs and backups from October 17 onward and hunt.
4. Reduce the blast radius. Keep management interfaces off the internet (the PAN-OS cases), keep database passwords and API keys out of web roots, and rotate them if you were exposed.
5. Remember it is a stopgap. A firewall rule helps for a day. Only the update fixes it.

Where Ghostdrive stands

Ghostdrive's website is a static build and its nodes run TypeScript, not PHP, so this flaw does not apply to them. The wider point is the one in the first briefing: if the server that holds your files is compromised, the question is what the attacker gets. In Ghostdrive it is sealed blocks, because files are encrypted on your device. That is a limit on the damage, not immunity from other bugs.

Academy: start here · How often are we attacked? · Patch triage in the AI era