PHP2Shell: the PHP flaw that exposes your site even when your code is perfect

On October 21, 2026, the PHP project shipped emergency fixes for two critical flaws in the language engine itself. The nickname that stuck is PHP2Shell: under certain conditions, an attacker with no login, no password and no knowledge of your system can run code on your server.

The detail that changes everything is where the flaw lives. It isn't in a plugin, a theme or a badly written form. It's in PHP. Your code can be spotless and the site is still exposed. And PHP runs underneath a large share of the web — WordPress, WooCommerce, Magento, Moodle, Laravel and most cPanel shared hosting.

This piece explains what happened, what the sources still disagree on, what to do this week — and why PHP2Shell is the third chapter of a story that already ran through 2021 and 2024.

What PHP2Shell is

Two vulnerabilities, both rated 9.2 (critical) under CVSS v4.0:

CVE-2026-109618 — memory corruption on out-of-memory. When PHP hits its memory limit mid-request, it aborts processing abruptly. If that happens while internal structures are still being built, they're left half-initialized — and an attacker can trigger that state on purpose.
CVE-2026-109619 — stale global state between requests. Data that belonged to one request survives after its memory has been freed, and the next request uses what's left over. A textbook use-after-free.

Both end the same way: remote code execution with the web worker's privileges. In practice that means reading the database, stealing credentials, planting a backdoor or turning the server into a launchpad for further attacks.

Discovery is credited independently to Calif and Wiz. Wiz says every PHP version released in the last decade is affected by at least one of the flaws, going back to 5.4 — and that AI tools played a role in the research. Hold on to that; I'll come back to it at the end.

Who's exposed

The advisories name PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. mod_php is rated highest risk, because exploitation can happen before the application code even runs.

The fixed versions are:

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

There's no official release for 8.1, 8.0 or 7.4: the project published source-level backports, and anyone on those versions depends on their Linux distribution or vendor package. For 7.3 and older — including the PHP 5 that still turns up on more servers than it should — there is no fix. The only way out is upgrading.

Is it being exploited or not?

The sources don't agree here, and I think showing the disagreement is more useful than picking a side:

watchTowr reports active exploitation attempts against both flaws.
AWS said on October 21 that the vulnerability was "now being broadly exploited in the wild" and identified an attempt dated October 17 — before public disclosure.
Cloudflare reported signs of exploitation before the fixes were published.
Rapid7 has not observed successful in-the-wild exploitation and says the public proofs of concept only work against specific combinations of operating system, PHP version and web server.
As of October 22, CISA had not added either CVE to its Known Exploited Vulnerabilities (KEV) catalog.

The honest reading: people are trying, public exploits exist, and it's not yet clear how many break-ins have succeeded. If you run a server, that uncertainty doesn't change the decision. Patching costs a maintenance window. Waiting to see costs, in the worst case, the server.

This isn't the first time

PHP2Shell stands out for its reach, but the PHP ecosystem has been through two recent episodes that help explain the pattern.

2024: CVE-2024-4577, PHP-CGI on Windows

In June 2024, PHP fixed an argument injection flaw in PHP-CGI on Windows, rated 9.8. It bypassed the protection for a 2012 bug (CVE-2012-1823) by abusing the way Windows converts certain characters — the "Best Fit" feature. XAMPP installations were squarely in the blast radius.

The gap between fix and attack was two days. Imperva recorded exploitation from June 8, delivering TellYouThePass ransomware. In January 2025, GreyNoise counted 1,089 unique IPs attempting exploitation, and Cisco Talos tied the CVE to a campaign against Japanese organizations involving credential theft and Cobalt Strike. The flaw landed in CISA's KEV catalog.

The lesson of 2024 is about time: attackers read the same security bulletin you do, only faster.

2021: the backdoor in PHP's source code

On March 28, 2021, someone broke into the project's official Git server (git.php.net) and pushed two commits into PHP's source — one under the name of Rasmus Lerdorf, the language's creator, and one under Nikita Popov, a core maintainer. The commit message was an innocent "Fix typo". The added code executed any command sent in a specific HTTP header, and it referenced Zerodium, the well-known zero-day broker, which denied any involvement.

The maintainers caught it and reverted it before the code reached an official release. The project abandoned its own server and made GitHub the canonical repository.

The lesson of 2021 is about trust: even the origin of the software can be attacked.

What to do this week

If you have anything running on PHP — a WordPress company site, an online store, an internal system, a hosting control panel — this is the order I'd follow:

Find out the version. On the server, php -v. On shared hosting, the control panel (cPanel, Plesk, hPanel) shows the version per domain. In WordPress, go to Tools → Site Health → Info → Server.
Update to the fixed release for your branch. 8.2.35, 8.3.36, 8.4.27 or 8.5.12. If it's a Linux server you manage, distribution packages arrived before disclosure; run your system update and check the version again.
Restart the PHP processes. Updating the package without restarting PHP-FPM or Apache leaves the old version running in memory.
On 8.1 or older? Ask your provider whether they applied the backports. If the answer is vague, treat it as unpatched and plan the version migration now, not next quarter.
On shared hosting, push your provider. The fix is in their hands. Ask for written confirmation that PHP2Shell has been patched on the servers your site runs on.

Until the update lands

Rapid7 lists temporary measures that shrink the attack surface. They have to be applied at the server level (php.ini, FPM pool or Apache config) — ini_set() inside the application or .user.ini come too late:

session.upload_progress.enabled=0
fatal_error_backtraces=0 (PHP 8.5)
cap post_max_size and upload_max_filesize, and bound request sizes at the proxy or CDN
restart every worker after the change

Two important caveats. Hiding errors (display_errors, error_reporting, @) does not protect against either flaw. And the absence of suspicious log entries doesn't prove you weren't hit. PHP's own maintainers said there is no complete mitigation: updating is the only safe path.

What this says about the moment

Three episodes, three different vectors. In 2021, the attack hit the origin of the software. In 2024, a specific configuration everyone assumed was niche. In 2026, the core that runs on practically every install.

And there's a new fourth element. Wiz credits AI tools with part of the PHP2Shell discovery. That's good news — bugs that slept for ten years are being found and fixed. But the same capability is available to attackers. The gap between a flaw's disclosure and the first exploitation attempt, which was two days in 2024, is shrinking. In 2026, according to AWS, the attempt came before the disclosure.

For anyone running a business on the web, the practical takeaway is less technical than it looks: someone has to own your server updates, with a name and a deadline. Not the security plugin, not the hope that your host will sort it out. A person who, on the day a bulletin like this drops, knows which version you're on and how long the fix takes.

If you can't say today which PHP version your site runs on, that's this week's first task.

If you'd like help auditing your site's infrastructure — versions, hosting, security headers and what could take you down — it's part of the work I do. Get in touch.

References

PHP2Shell (CVE-2026-109618 and CVE-2026-109619)

CVE-2024-4577 (PHP-CGI on Windows)

git.php.net backdoor (2021)

— views— likes