PHP2Shell: A 9.2 PHP Flaw Lets Unauthenticated Attackers Run Code on 70% of the Web, and WAFs Are Not a Fix

PHP just shipped one of the most urgent security releases in its history. Versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical remote code execution flaws that can be triggered without authentication.

Cloudflare calls the pair php2shell. It says the flaws affect PHP 5.4 and later and that PHP is used by almost 70% of websites. The PHP project is blunter: every PHP installation serving web requests is at risk, and updating is the only complete fix.

The catch is in the fine print. A web application firewall can block known attack traffic, but it cannot repair the PHP runtime underneath WordPress, Magento, Laravel or a custom API. The patch has to land on the server.

What PHP actually fixed

The first flaw, CVE-2026-109618, is an out-of-memory corruption bug. If a request hits PHP’s memory limit at the wrong moment, PHP can leave partially initialized internal data behind. Cleanup then treats that invalid data as valid.

The second, CVE-2026-109619, is a stale global state bug. A fatal error can leave request-owned state pointing at memory that has already been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.

Both sit in memory management and error handling, parts of the engine that nearly every request touches. That is what makes them serious, and what made them hard to fix without breaking compatibility or performance.

The worst case is Apache with mod_php. The PHP project says it demonstrated an unauthenticated request that triggers the attack before any application code runs. Remote code execution was also confirmed on PHP-FPM through application-level code paths.

The advisory lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed among the affected setups. The CVSS score is 9.2, not the 10.0 that circulated in a leak before release.

Who is exposed

The answer is anyone running an affected PHP version in front of the internet. That includes WordPress sites, Magento stores, Laravel apps, APIs, internal tools and appliances with a PHP web interface.

PHP 8.1 and older no longer receive normal updates from the PHP project. The team published minimal source backports for PHP 7.4, 8.0 and 8.1, but distributions and long-term support vendors have to package them. If a host pins an old branch, the host has to move or the site has to migrate.

Cloudflare says the flaws affect PHP 5.4 and later. Treat any internet-facing PHP runtime below the fixed releases as exposed.

The patch matrix

PHP branch	Fixed release	Project support	What to do
PHP 8.5	8.5.12	Supported	Update immediately and restart PHP workers
PHP 8.4	8.4.27	Supported	Update immediately and restart PHP workers
PHP 8.3	8.3.36	Supported	Update immediately and restart PHP workers
PHP 8.2	8.2.35	Supported	Update immediately and restart PHP workers
PHP 8.1 and older	No standard release	End of life	Use a vendor backport or upgrade to a supported branch

That last row is the dangerous one. A site can look patched at the WordPress level and still run an unpatched PHP runtime. Updating plugins does not fix this bug.

Confirmed vs not confirmed

Claim	Status	Evidence
Two unauthenticated RCE flaws exist in PHP	Confirmed	PHP advisory and two CVE IDs
Attack can run before application code on mod_php	Confirmed	PHP project demonstrated it
PHP-FPM can be exploited through application paths	Confirmed	PHP Foundation says RCE was confirmed
Cloudflare WAF blocked attack traffic	Confirmed	Cloudflare says it observed mutations and attacks
Mass exploitation of every WordPress site	Not confirmed	No evidence every site is compromised
A working public exploit existed at release	Not confirmed	PHP says it found no functional exploits at disclosure

The disclosure got messy

The coordinated release did not stay coordinated. On October 20 at around 15:00 UTC, the two CVE IDs began circulating on forums and social media. They came with a wrong release time and a wrong CVSS score of 10.0. The actual score is 9.2.

The PHP project brought its pre-announcement forward and moved the release from October 22 to October 21 at 14:00 UTC. Then Chainguard published built images containing the fix at 07:41 UTC on October 21, more than six hours before the coordinated release. Attackers could study the binary fix while many users were still waiting for packages.

Cloudflare had already deployed WAF rules at 03:02 UTC, about nine hours before public disclosure. It says the rules were live for free and paid WAF customers by default, and that it saw attackers mutating payloads to evade detection.

That is useful defense in depth, not a substitute for patching. Cloudflare says customers should still patch their PHP repositories.

Why AI is part of this story

The PHP Foundation says it worked with Alpha-Omega to scan PHP with Anthropic’s Claude Mythos earlier this year. It later added OpenAI’s Daybreak Red for validating reports and exploits, alongside sanitizer builds and reproduction environments.

The actual reports came from people and firms. Researcher Ryan A at Calif reported an unconditional RCE on August 11. OpenAI independently reported the same root cause the same day, followed by more vectors from OpenAI on September 18 and Wiz on August 24.

AI helped with scanning and validation, but humans confirmed the impact and wrote the patch. The Foundation says AI now generates far more reports, including invalid ones, and people still make every call.

The deeper problem is funding. PHP runs banks, stores and government services, but its security work depends on a small group of foundation-funded developers and volunteers. The OOM bug was first spotted in 2024 and only became the top priority in August 2026. That is a structural failure.

What it means for Indian developers

India has a large base of WordPress agencies, Laravel shops, Drupal vendors and shared-hosting resellers. Many client sites run on PHP versions chosen in cPanel or a host control panel, not by the developer. That makes the runtime version someone else’s job until it becomes yours.

Ask the host which PHP version the site is running and whether the patched package is available. Do not accept “we will update soon” without a date. If the host caps PHP at 8.1 or older, ask for a vendor backport or move the site to a supported branch.

Check the parts that are easy to forget: Docker base images, CI runners, staging servers, cron containers and internal admin tools. A patched production server with an unpatched staging box still gives an attacker a way in if staging is reachable.

For agencies, this is also a client communication problem. Send a short note with the CVE IDs, the fixed versions and the action taken. Do not tell clients that a WAF or a WordPress plugin update solved it. Neither touches the PHP engine.

The same lesson applies to AI coding workflows. An AI agent can help find a bug or write a patch, but it cannot decide whether a change breaks a decade of extensions. Those calls still need engineers who understand the runtime. The Anthropic OSS scanner story shows the same pattern: more reports, not automatically more fixes.

What to do now

First, identify the runtime. Run php -v on the server, check the FPM pool configuration and confirm the version from a phpinfo() page that is not public. Then update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

Restart PHP-FPM and the web server after the package update. A new binary on disk does not help workers that are still running the old code. In containers, rebuild the image and redeploy, then confirm the running container reports the fixed version.

If you cannot patch immediately, PHP lists temporary settings such as a low post_max_size and disabled session.upload_progress. They are not complete mitigations. Treat them as a bridge, not a destination.

Keep the WAF on. Cloudflare’s rules are useful while you patch, and the company says it is still updating them as new variants appear. But the origin still needs the fix.

Finally, check for signs of exploitation if the site was exposed before patching. Look for new files in web roots, unexplained outbound connections and unusual PHP worker crashes. If you find evidence, treat it as an incident rather than a patching task.

Bottom line

PHP2Shell is not a WordPress plugin bug, a theme bug or a hosting-panel bug. It is a flaw in the PHP runtime that can allow unauthenticated code execution before an application even loads. The fixed releases are available.

The web has spent years treating PHP as boring infrastructure. This week, boring infrastructure became the emergency. Patch the runtime, restart the workers and verify the version. A WAF buys time, but it does not close the hole.

FAQ

What is PHP2Shell?

PHP2Shell is the name Cloudflare uses for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both can lead to remote code execution.

Which PHP versions are affected?

Cloudflare says PHP 5.4 and later are affected. The PHP project says all installations serving web requests are at risk. Fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Does updating WordPress fix it?

No. WordPress runs on PHP, but the vulnerability is in the PHP runtime. Updating WordPress or its plugins does not patch the engine underneath.

Is a web application firewall enough?

No. A WAF can block known attack patterns and reduce exposure, but PHP says updating is the only complete fix. Cloudflare also tells customers to patch.

Was PHP2Shell found by AI?

Partly. The PHP Foundation used AI-assisted scanning and validation tools, but human researchers at Calif, OpenAI and Wiz reported the vulnerabilities, and PHP developers wrote and reviewed the patches.