PHP2Shell: The Thirty-Year-Old Foundation Under 70% Of The Web Just Cracked. Again.

On 20 October 2026 the PHP project did something it rarely does: it warned the world a day in advance that a security release was coming, and that it would be bad. On 21 October it shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two critical bugs that allow an unauthenticated stranger to run code on your server. The security industry, never one to waste a naming opportunity, called them PHP2Shell.

If you run WordPress, you run PHP. If you run PHP, you were affected. Not 'possibly'. Not 'in some edge configurations'. According to CISA, the flaws affect all PHP installations serving web requests: Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. That is essentially the entire list of ways anyone has ever run PHP on purpose.

What actually broke

Two bugs, one root cause. CVE-2026-109618 is memory corruption during out-of-memory handling. PHP enforces its memory_limit by abruptly jumping out of whatever it was doing, which is a perfectly normal thing to do in 1995 and a slightly alarming thing to do in 2026. If that jump happens at exactly the wrong moment, PHP leaves half-built internal data lying around and later treats it as real. On Apache with mod_php, an attacker can trigger this before any of your application code even runs. Full remote code execution was demonstrated on default settings.

CVE-2026-109619 is the sequel. A fatal error at the wrong point leaves internal state pointing at memory that belonged to a previous request. The next request handled by the same worker uses freed memory. Use-after-free, memory disclosure, remote code execution. Both rated CVSS 9.2. Then, on 23 October, a third RCE vector arrived (CVE-2026-115560), this one deemed unlikely enough that PHP is handling it in the regular release cycle and asking you to switch off session upload progress in the meantime. Then on 26 October, rebuilt Windows packages for a Brotli out-of-bounds write. Four advisories in six days. Lovely week.

“Organizations that cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated. — CISA, 21 October 2026”

Read that again. The United States' cybersecurity agency told people running old PHP to turn their websites off. Wikimedia disabled its Phabricator instance as a precaution. The European Commission, ENISA, CERT-EU and Europol issued a joint statement. This was not a plugin bug. This was the floor.

Meanwhile, at the BBC: the end of the world, live

Then the mainstream press found out PHP exists. For a language most of the public has never heard of, it went from zero to rolling coverage in about four hours. The BBC ran a live page. A live page. For a memory-handling bug in an interpreter. The headline promised that the scale of the flaw was "unprecedented", quoting a boss at the UK's National Cyber Security Centre, then helpfully added in the same breath that there was "no sign of breaches so far". Apocalypse, but with no casualties. Very British.

The BBC's main report opened with "Websites taken down worldwide as critical cyber-security update issued" and explained that agencies had urged organisations unable to patch in time "to consider taking their sites down, leading bodies such as the Finnish government, Edinburgh council and the BBC to take pages offline." Yes, the BBC reported on websites going dark while some of its own pages were among them. The Guardian ran a photo of a BBC page saying "temporarily unavailable". The media covering itself being down is peak 2026.

• →Finland temporarily shut down the government's public web services. The Dutch cyber-security agency took its own website offline. The people whose job is cybersecurity unplugged their own homepage.
• →In Scotland, at one point "at least seven of Scotland's 32 councils and six of its 14 health boards had taken their websites offline as a precaution", per the BBC.
• →A UK minister said 32 government services were unavailable and four partially unavailable while being fixed.
• →In Chepstow, a garage owner couldn't process MOTs online and went back to "pen and paper". The BBC reported this. Civilisation endures.
• →Japan's Prime Minister, Sanae Takaichi, posted on X urging people to check whether their websites ran on PHP. A head of government doing server inventory on social media.
• →The White House said federal agencies were working with leading AI labs to speed up a fix.

“"Not seen anything like this in a long, long time." — Satya Nadella, Microsoft CEO, as reported by the BBC. "It was a long day and a long night, I know, for all the IT and security folks."”

The Guardian went with "Websites across world hit by millions of attempts to exploit PHP code flaw", describing PHP as the language "which underpins about 70% of the world's websites". Surrey Centre for Cyber Security's Prof Alan Woodward told the BBC the flaw affects "some 30 million websites" and that "an attacker can get their own code on to the webserver and run it". The NSA weighed in on X: "These vulnerabilities often provide a direct path to the server's file system or database." Wiz, who found it, called the bugs the "most severe vulnerabilities ever discovered" by AI and, in its own write-up, ranked them "arguably in software history". Nobody has ever undersold a bug they discovered.

The best quote came from the coalface. UK sysadmin Adam Mudd told the BBC: "It's been relentless". And then the line that should be printed on every hosting invoice: "Sometimes it takes me longer to take a website down than to fix the PHP problem." The BBC itself conceded that "misinformation and panic has made things a lot worse." Quite.

So was it the end of the world? No. Was the hysteria proportionate? Also no. But here's the uncomfortable bit the breathless coverage accidentally got right: a single bug in a 31-year-old language was enough to knock councils, health boards, national governments and a public broadcaster offline in an afternoon. The panic was overblown. The dependency it exposed was not.

Since PHP 5.4. Let that sink in.

The affected range, per the public write-ups, runs from PHP 5.4 to 8.5. PHP 5.4 came out in 2012. These bugs have been sitting in the engine room for roughly fourteen years, through every 'PHP is fast now' keynote, every 'modern PHP is actually good' blog post, every hosting company badge declaring 'secure, optimised WordPress hosting'.

Who found them? Not the decades of human review. Ryan Austin at Calif, working inside OpenAI's 'Patch the Planet' project, and Wiz Research, with Google's Gemini credited for helping find the bug, build the exploit and validate the patch. So, to recap the 2026 state of affairs: AI found a fourteen-year-old hole in the language that runs WordPress, and the WordPress ecosystem's answer to AI is to bolt MCP adapters onto Elementor. You could not write this. Well, you could. We do. Weekly.

In fairness to the elephant

Let's be honest before the PHP faithful arrive with pitchforks. The PHP security team handled this well. Pre-announcement, coordinated disclosure, patches across four supported branches, and, unusually, minimal source backports for the long-dead 7.4, 8.0 and 8.1. The PHP Foundation used the moment to explain how its security work has been professionalised over the past two years, and to ask, politely, for the companies making billions from PHP to actually fund it. That is a reasonable request. It is also a remarkable admission: the runtime under roughly 70% of the web relies on a foundation passing the hat.

Every language has security bugs. Node has them. Python has them. Your favourite shiny framework has them. The question is not 'does it have bugs'. The question is what the architecture makes likely, and how many unpatched copies are lying around the internet waiting to be found.

The problem with a language older than some of your clients

PHP turned 31 this year. It began life as Rasmus Lerdorf's 'Personal Home Page' tools in 1994, a set of C scripts to track visitors to his CV. It was never designed. It accreted. And underneath the modern syntax, the type hints, the JIT and the very nice conference talks, it is still a C engine doing manual memory management, with a request lifecycle where 'abort everything mid-flight with a long jump' is an official control-flow strategy.

That is exactly the class of bug PHP2Shell is. Memory-safety failures are not exotic. They are the predictable tax on large C codebases, which is why governments have spent the last three years begging the industry to move to memory-safe languages. PHP's application layer is memory-safe in the sense that you, the WordPress developer, cannot easily corrupt memory. The engine running your code enjoys no such protection, and the engine is where the attacker went.

• →Old architecture: shared worker processes, global state, abrupt aborts. Precisely the conditions both CVEs exploited.
• →Long tail of versions: PHP 8.1 and earlier get no official fixes. Huge numbers of shared hosts still run them.
• →Invisible dependency: CISA warned that PHP is often a component of other software and 'prevalence may not be directly observable'. You may be running PHP and not know it.
• →Responsibility diffusion: the patch exists, but whether your site gets it depends on your host, your control panel, your distro and whether anyone is awake.

Now add WordPress

Here is where WordPress turns a language problem into a business problem. WordPress famously still supports ancient PHP versions so that nobody's ten-year-old site breaks. That backwards-compatibility religion is noble. It also means a meaningful slice of WordPress sites run on PHP versions nobody patches. Those are the sites CISA said to switch off.

Then there's the bit no host's marketing page mentions. This is the second time this year we've written the word 'shell' next to WordPress. In our wp2shell autopsy, WordPress core handed attackers the keys and made you change the locks. Now PHP itself has done the same, one level further down. Stack your 30 plugins on top, a decent chunk from the 43.8% of the directory that is abandoned, and you have a building with three independently rotting floors and a tenant on each one insisting the structural problem is someone else's.

And remember who fixes this for the average small business site. Not the business owner. Not usually the freelancer who built it in 2019. The shared host. On their timetable. Through a control panel that, for many, still offers PHP 7.4 as a cheerful drop-down option.

So is this another reason to abandon WordPress?

Yes. But let's be precise about why, because 'a bug was found' is not an argument. Bugs get found everywhere. The argument is this: running a WordPress site means owning a live, exposed, server-side PHP runtime, forever, for a brochure that changes twice a year. Every request to your 'About Us' page spins up a 31-year-old interpreter that just turned out to be exploitable before your code runs.

Compare that to a modern static or edge-rendered site. Most pages are pre-built files on a CDN. Where there is server code, it runs in isolated, short-lived sandboxes patched by the platform, not by Dave at the hosting company. There is no persistent worker for a stale pointer to survive in. There is no memory_limit long-jump. There is no plugin directory. The attack surface isn't 'smaller'. For a typical small business site it is a different category.

“The safest PHP server is the one you never had to run.”

Will WordPress vanish next week? No. Neither did Flash, for years after everyone knew. Large organisations with in-house teams, proper patch pipelines and genuine content workflows can run WordPress safely. They patched PHP2Shell within hours. The other 90% of WordPress sites belong to people who learned about it from this article.

The hosting industry's finest hour (it wasn't)

Every budget host on Earth sells 'secure, managed WordPress hosting'. PHP2Shell was the exam. The big platforms passed: Amazon said it had already spotted and blocked malicious scanning, and the major providers pushed patches within hours. Good. That's what you pay them for.

Then there's everyone else. Researchers quoted on the BBC's live coverage estimated that, globally, 90% of systems at risk had not yet applied the fix. Ninety percent. That is not a patching programme. That is a raffle. And the shared-hosting long tail is where most small business WordPress sites live: cPanel boxes with five PHP versions in a drop-down, some of them retired years ago, kept around because a customer's 2017 theme throws a fatal error on anything newer.

Ask yourself a simple question. When was the last time your host emailed you, unprompted, to say 'we patched a critical PHP vulnerability on your server at 14:10 today'? If the answer is 'never', you have no idea whether you were patched on Wednesday, Friday, or not at all. You are trusting a cheap monthly plan with something governments were taking offline.

'But modern PHP is actually great'

We know. We've heard it at every meetup since 2015. PHP 8 is fast. It has types, enums, attributes, readonly properties, a JIT, and Laravel is genuinely lovely to work in. All true. None of it matters here. PHP2Shell wasn't in your code, your framework or your syntax. It was in the C engine underneath, in how it cleans up when a request dies badly. You can write the most elegant, strictly-typed PHP 8.5 in the world and it will still run on that engine.

That's the trap of a thirty-year-old platform. The paint gets refreshed constantly. The foundations get inspected when something falls over. And it took frontier AI models, by Wiz's own account, to chain together an exploit that was 'at the edge of what human researchers could practically achieve'. Which brings us to the bit nobody wants to say out loud.

The AI bug-hunt has only just started

PHP2Shell wasn't found by a lucky human with a fuzzer. It was found by OpenAI's 'Patch the Planet' work and by Wiz using a mix of models, with Google crediting Gemini for helping build the exploit and validate the fix. The good guys got there first this time. Congratulations. Now think about what that means for every other ageing C codebase on the web: older PHP extensions, image libraries, the decompression code that gave us this week's Brotli bonus round.

The economics of bug-hunting just flipped. Old, sprawling, memory-unsafe code, the kind that has 'worked fine for years', is now the cheapest thing on the internet to attack, because the machines read it faster than the maintainers ever could. A platform's age used to suggest it was battle-tested. In 2026 it suggests it's a target-rich environment. WordPress, sitting on PHP, sitting on a pile of C libraries, is three generations of that at once.

The WordPress defence, pre-empted

• →'Lovable and every other platform run on something too.' Yes. The difference is who patches it, how fast, and whether you even have a persistent server to attack. A static page on a CDN has no PHP worker to corrupt.
• →'Security is about good hosting, not the CMS.' Then why does the WordPress ecosystem still sell itself on £3-a-month hosting?
• →'It was patched in a day.' The code was. 90% of exposed systems weren't, according to researchers. Code is not deployments.
• →'No breaches were reported.' Yet. Amazon was already seeing exploitation attempts. Millions of them, per The Guardian. 'Nobody's been burgled' is not a reason to leave the door open.
• →'Moving off WordPress is expensive.' So is a hacked site, a Google malware warning, and explaining to a client why their customer database is on a forum.

What to do on Monday

• →Find out which PHP version your site actually runs. Not what the host's sales page says. Check your control panel or Site Health in WordPress.
• →If it is not 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later (or a vendor-backported build), raise it with your host today. In writing.
• →If you are on PHP 8.1 or older, you are on the list CISA told to go offline. Act like it.
• →Set session.upload_progress.enabled=0 until the next PHP bugfix release if your host lets you.
• →Ask your host when they patched and get a date. If they can't give you one, you've learned something important about your host.
• →Then, honestly, ask whether your site needs a permanently running PHP server at all. For most brochure, portfolio and small business sites, it doesn't.

PHP's maintainers did the decent thing this month. Credit where due. But a well-handled emergency in a thirty-year-old engine is still an emergency in a thirty-year-old engine. You don't keep a vintage car as your daily commute because the recall was handled politely.