php2shell: why your PHP version mattered more than your CMS

The week PHP had to patch its own engine

On October 21, 2026, the PHP project shipped PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The releases fix two critical bugs, now known as php2shell, that can let an attacker run code on a server without logging in. If you run a Craft site and haven't updated PHP yet, stop reading and do that first.

Security updates in the Craft world are usually about a plugin or a new Craft release. php2shell is different because the bug is in PHP itself, so Craft sites were hit just as hard as WordPress or Laravel sites on the same server. Nothing in a Craft project could have prevented it. What counted was which PHP version the server was running.

This piece covers what the two bugs are, why the disclosure turned into a scramble, and what all of it means for Craft sites in particular.

Two bugs in the code every request runs through

Both bugs are rated 9.2 out of 10 under CVSS 4.0, and an attacker doesn't need to log in to use them. They sit in PHP's memory management and error handling, code that runs on almost every request.

CVE-2026-109618: corruption at the memory limit. Every PHP request runs under a memory_limit. If a request hit that limit at exactly the wrong moment, PHP could leave half-built internal data behind and later treat it as valid. On Apache with mod_php, an attacker could trigger this before any application code ran, and full remote code execution was shown with default settings. On PHP-FPM it was confirmed through application code paths.

CVE-2026-109619: leftovers from the previous request. A fatal error at the wrong point could leave PHP holding a pointer to memory that belonged to an earlier request. The next request on the same worker could then use that freed memory, a classic use-after-free. The reporter showed code execution against a real application on Apache with mod_php.

Because this code sits at the center of PHP, the fix was hard. It had to avoid breaking compatibility, slowing PHP down, or forcing changes on a large ecosystem of third-party extensions. There is also no complete workaround in configuration. The PHP team says updating is the only safe option.

Why the fix took two years

The memory limit bug was not new. In 2024, PHP went through its first external security audit in years. Germany's Sovereign Tech Agency paid for it, OSTIF organized it, and Quarkslab did the work. While fixing one of Quarkslab's findings, a core developer contracted by the PHP Foundation noticed the first signs of the problem. A possible exploit was theorized at the time, but nobody found a concrete way in.

The security team then built several competing fixes. Each one came with a price: a backward compatibility break, a new denial-of-service risk, or changes to many third-party extensions that nobody could realistically coordinate. Every decision needed the whole team to agree, and they couldn't. For months, the work stalled and restarted. In its own post, the Foundation calls this a structural failure caused by its decision process and a lack of resources. 

The pressure came back this summer. On July 30, 2026, security firm Calif started an audit of PHP through OpenAI's Patch the Planet program. On August 11, Calif researcher Ryan Austin reported an unconditional remote code execution with the same root cause. OpenAI found the same thing independently, the cloud security company Wiz added attack vectors on August 24, and OpenAI added more on September 18. From August 11 on, the fix was the top priority for everyone at the Foundation working on security, eventually around the clock.

AI tools played a role on both sides. The PHP project scanned its code with Anthropic's Claude Mythos through Alpha-Omega and uses OpenAI tooling to validate reports. Since July 1, the security team has published 15 CVEs and worked through more than 100 reports that turned out to be invalid, duplicates, or not reproducible. Craft is seeing the same wave. In a post on the Craft blog from October 17, Brad explains that the jump in Craft security advisories comes from AI-assisted research, not from Craft getting worse.

Much of this week's coverage told a simpler story. The Associated Press ran its explainer under a headline calling php2shell an "AI-detected security bug", even though the article itself says humans found the vulnerabilities first. The BBC opened its explainer by saying AI brought the flaws to light. In Germany, a widely syndicated dpa report suggested the bugs were probably found through massive use of AI, since they had been overlooked for decades. The same piece quotes a member of the Bundestag who says AI now turns flaws once thought hard to exploit into real entry points.

The official timeline is less dramatic. A human found the root cause during a traditional audit in 2024. AI-assisted research in 2026 showed how serious it really was and forced the fix. A researcher quoted further down in the BBC piece sums it up better than its opening line: 

What sped up the exploits after that was a leak and a deleted video, not a model. 

A leak, a deleted video, and a broken embargo

The coordinated disclosure held until two days before the planned release on October 22. Then it came apart. All times are UTC.

Why not release right away? Linux distributions were still packaging the fix. Shipping immediately would have left many people without an easy way to update, so moving the release by one day was the compromise.

The early images mattered because a patch can be reverse-engineered. Once Chainguard's binaries were public, anyone could study what changed while others were still waiting. The PHP team says it saw no working exploits at the time of release. Craft's post adds that there is evidence the bugs were being exploited before the updates landed. According to the BBC, Cloudflare saw thousands of exploit attempts on its network in the ten hours before the announcement and millions afterward, though no successful attack had been reported by Friday morning. Several sites went fully offline in the meantime, and Wired ran the story under a "this is not a drill" headline.

Who is still exposed

The official fix only exists for PHP 8.2 and newer. PHP 8.1 and everything older are end of life and got no regular releases. The security team did publish minimal source backports for 7.4, 8.0, and 8.1, and some distributions and long-term support vendors ship their own. AWS notes that no fix exists for CVE-2026-109618 on end-of-life branches at all. CISA advises taking systems offline until they are patched if they can't be updated or run 8.1 or older.

That is a big group. Qualys counts about 110 million PHP installations, 71 percent of those it sees, on versions between 5.4 and 8.1. Only about 199,000 were patched in the first twelve hours.

For Craft sites, the major version tells you a lot:

One more date to keep in mind: PHP 8.2 itself reaches end of life on December 31, 2026. A Craft 5 site on 8.2 is fine today, but the next PHP security release may not include it.

How Craft Cloud handled it, and what that means for your own hosting

Craft Cloud sites were covered before the patch even existed. OpenAI coordinated with Cloudflare ahead of the disclosure, and Cloudflare rolled out emergency firewall rules across its whole network. Pixel & Tonic says those rules protected Cloud-hosted sites, with no known successful attacks. Once PHP shipped, Matthieu Napoli built new images for Bref, the PHP runtime behind Craft Cloud, in just over an hour. The Cloud team rolled them out to every project. Apart from a handful of sites with existing build problems, all Cloud environments now run the patched images.

Sites elsewhere had a harder day. Between the leak and the release, there was nothing to install, so the real question was how much risk to accept for a few hours. What made sense depended on where a site runs:

• Managed Craft hosting: find out what the host has in place and pass that on to clients. Most of the work happens on the host's side.
• Platforms with a maintenance mode: turning it on keeps requests away from PHP entirely, removing the attack surface until the patch lands.
• Your own server or VPS: lock the site down at the firewall or web server so only you can reach it, then patch and reopen.

Taking a client site offline is never a popular call. With a bug that needs no login and CVE IDs already circulating, a few hours of downtime is still cheaper than cleaning up a compromised server. It also matches CISA's advice for systems that can't be patched yet.

The lesson for anyone looking after Craft sites is less about Craft and more about inventory. You need to know, for every client, where the site runs and who patches PHP. On a managed platform, that is your host. On a VPS, that is you.

Where Craft helps, and where it can't

No CMS protects you from a bug in the PHP engine. If the interpreter is broken, the code running on top of it doesn't get a vote. What Craft does well is make it more likely that you are on a PHP version that gets fixed, and that you hear about problems early.

It doesn't let you drift onto old PHP. Craft 5 requires PHP 8.2. When Craft 5 came out in 2024, that looked like a routine requirement bump. This week, it meant no Craft 5 site could stay on a PHP branch without a fix. For comparison, WordPress 7.0, released in May 2026, still officially runs on PHP 7.4. 

Its support windows are written down. Pixel & Tonic publishes exact dates for active support and security support on every major version. Craft 5 gets security fixes until the end of 2031. When a client asks how long their site is safe, you can point to a page instead of guessing.

It tells you about problems. Craft runs a vulnerability disclosure program, publishes GitHub security advisories, and keeps a Critical Releases feed. Patched releases come first, with full details 30 days later so site owners can update before anyone can read the advisory. The control panel also shows update notices.

It has more locks on the front door. Craft 5 ships with built-in two-factor authentication and passkeys. That does nothing against php2shell, which needs no login, but it closes off the more common way into a CMS.

Its first-party hosting reacted within hours. Craft Cloud combined Cloudflare's network in front with a runtime it rebuilt and rolled out the same afternoon. For a small team without someone on call, that is a real argument.

And a lot of a Craft project's security comes from how it is maintained. Pixel & Tonic's advice in this week's posts boils down to two points: stay on a supported version, and make updates routine instead of exceptional. A current site can take an emergency patch in an afternoon. A site twelve months behind may need dependency and plugin work first.

The part that isn't a patch

The most important paragraph in the PHP Foundation's post isn't technical. PHP runs government services, shops, banks, and a large share of the web, and its security work still rests on a small group of Foundation-funded developers plus some volunteers. Tools now find bugs faster than ever. Deciding how to fix a design decision buried in the engine still takes experienced people who know the whole codebase, and there are too few of them.

The Foundation is asking companies that build on PHP, hosting providers, and public institutions to fund that work. Many of us earn our living building Craft sites. Some of that could reasonably flow back to the language underneath. If your agency or company can, sponsor the PHP Foundation.

Sources

• Today's PHP security release, and how we're strengthening PHP security, The PHP Foundation
• Craft Cloud and php2shell, Craft CMS blog
• Why Craft is publishing more security advisories, Craft CMS blog
• Supported versions, Craft CMS knowledge base
• PHP 8.2.35 release notes, php-src on GitHub
• Security advisory 2026-018, CERT-EU
• PHP security bulletin, AWS
• PHP2Shell: find, mitigate, and patch now, Qualys
• PHP2Shell remediation guide, SecurityScorecard
• Was Sie zur PHP-Sicherheitslücke wissen müssen, dpa via Tagesspiegel (German)
• What to know about the AI-detected security bug impacting wide swaths of the internet, Associated Press
• What is PHP and why did it spark a global cyber-security scramble?, BBC News