PHP2Shell Vulnerability: Two Critical PHP Flaws Let Attackers Run Code Without Logging In

What PHP2Shell is

On October 21, the PHP project shipped an emergency release fixing the PHP2Shell vulnerability: two critical flaws, CVE-2026-109618 and CVE-2026-109619, nicknamed after a leaked exploit tool. Both score 9.2 under CVSS v4.0, and both allow unauthenticated remote code execution as the PHP process user. No login required, no user interaction needed. An attacker sends a request; the server runs their code.

The first flaw sits in PHP's memory management: an out-of-memory condition that corrupts memory, triggerable on Apache mod_php before application code even runs. The second is a use-after-free in PHP's internal state handling. Every common way of serving PHP is affected: PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed. EU CERT warns the flaws could reach all the way back to PHP 5, released in 2004.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. If you are still on PHP 8.1 or older, you get only minimal source backports. The message from the project is blunt: upgrade.

How bad is it, really?

Wiz estimates roughly 70% of the internet is affected, which is a vendor estimate and should be read as one, but the direction is not in dispute. Bitsight's scans show only about a third of detectable PHP instances are on branches covered by the fix, and PHP 7.4, long past support, remains the most commonly observed branch with over 2 million instances.

The exploit situation is already moving. A leaked proof-of-concept video was published and then deleted. One security firm reproduced the first flaw in its lab before the patch. Bitsight reports early evidence of exploitation in the wild, and Cloudflare CTO Dane Knecht told the BBC he was seeing early attacks emerge. The PHP Foundation said it had found no functional exploits at release time, which is the kind of statement with a short shelf life.

The government response tells you how seriously this is being taken. The US NSA issued a rare public warning, telling administrators to take systems offline if patching is impossible. The UK NCSC published a formal alert. Germany's digital ministry shut down some government websites, France's interior ministry deactivated local administrative offices, and Belgium, the Netherlands, Finland, and the Czech Republic took similar steps. Japan's prime minister publicly urged people to check whether their websites run on PHP. The Wikimedia Foundation took systems down as a precaution, briefly leaving parts of Wikipedia unreachable. When Wikipedia goes dark voluntarily, pay attention.

The PHP2Shell vulnerability had a messy road to disclosure

The flaws were reported on August 11 by a researcher at security firm Calif, and OpenAI independently reported the same root cause the same day. Wiz reported further attack vectors on August 24 through OpenAI's Patch the Planet program. Here is the uncomfortable part: a PHP core developer had noticed the bug back in 2024, but the fix stalled. The PHP Foundation called that delay "a structural failure."

Then the disclosure itself leaked twice. The CVE IDs circulated on forums on October 20, two days early and with a wrong 10.0 severity score attached. Chainguard published fixed container images at 07:41 UTC on October 21, about six hours before the coordinated release, forcing the schedule forward from October 22.

There is an irony worth noting: AI systems helped find these bugs. The discovery credits include AI-assisted research, and the "structural failure" was human process, not machine capability. The machines found the flaw; the humans sat on it for two years.

What to do right now

There is no generic workaround. Updating is the only complete mitigation, full stop.

• Patch to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 immediately. If you are on 8.1 or older, upgrade; the backports are minimal.
• If you cannot patch, the NSA's advice is to take affected systems offline. That is not typical guidance, and it tells you everything about the risk calculus.
• After patching, assume the worst about the window before the patch: review logs for unusual requests, especially anything probing memory-handling behavior.
• Inventory where PHP actually runs in your environment. The reason old PHP persists is that nobody remembers all the places it lives: legacy admin panels, forgotten WordPress installs, internal tools.

This is the second major infrastructure scare in a month of heavy breach news, from the October breach wave to supply-chain attacks. If your incident response plan is a vague document nobody has opened since 2024, this is the week to open it. Our post-breach checklist covers the first 72 hours. Patch first, investigate second, and do not assume you are too small to be a target: automated exploitation does not check company size.