On 21 October 2026, the people who make PHP released an emergency fix for two serious security holes. The security world has nicknamed them PHP2Shell. If your website runs on WordPress, WooCommerce, Drupal or Joomla, this is about you.
Most write-ups so far are written for security engineers. This one isn’t. If you’ve ever been told “it’s a use-after-free in the request lifecycle” and nodded politely, you’re in the right place.
The Short Answer
- PHP is the engine underneath around 70% of websites, including every WordPress site. Both holes are in that engine, not in a plugin or theme.
- A stranger could send your website one specially crafted request, with no login and no password, and potentially take control of the server it runs on.
- Nearly every version of PHP from the last ten-plus years is affected.
- The fix is simple: update PHP. The safe versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35 or newer.
- Artificial intelligence played a big part in turning these old, hidden bugs into working attacks. We will see more of this.
If that’s all you needed, skip to what to do today. If you want to actually understand it, read on. No technical knowledge required.
First: What Even Is PHP?
Think of your website as a restaurant.
- Your visitors are the customers.
- WordPress is the menu and the recipes.
- PHP is the kitchen. It’s where every page actually gets cooked before it’s handed to the visitor.
When someone visits your site, PHP takes their order, reads the recipe, gathers the ingredients from your database, cooks the page and sends it out. It does this thousands of times a day without anybody thinking about it.
Most security problems you hear about are a dodgy recipe: one plugin, one theme. Those only affect the restaurants using that recipe. PHP2Shell is a problem with the kitchen itself. It doesn’t matter what’s on the menu. If the kitchen has the fault, the restaurant has the fault.
That’s why this one is a bigger deal than the usual “update your plugins” warning.
The Two Holes, Explained Like You’re Five
There are two separate bugs with two official reference numbers (CVE-2026-109618 and CVE-2026-109619). Both are rated 9.2 out of 10 for severity. Here’s what each one does, in kitchen terms.
Bug one: the half-laid table
A waiter is laying a table. Fork, knife, plate, glass. Halfway through, the restaurant suddenly runs out of space and the waiter is pulled away mid-task.
Later, the cleaner comes round. The cleaner’s job is to clear finished tables, and they assume every table they find was laid properly. So they start clearing this half-laid one as if it were complete, and get muddled, because some of the things they expect to be there aren’t, and some things they find were never meant to be there.
Now imagine a trickster who knows exactly when the waiter will be pulled away. They can arrange what’s left on that half-laid table so that when the cleaner gets confused, the cleaner ends up following the trickster’s instructions instead of their own.
That’s bug one. When PHP runs out of memory while setting up a visitor’s request, it gets interrupted halfway. PHP’s clean-up routine then treats the half-built data as if it were finished, and an attacker who arranges things carefully can use that confusion to make the server run their own commands.
Bug two: the coat peg with someone else’s name
At school, you hang your coat on a peg. At home time you take the coat away, but the name label stays on the peg.
The next morning a new child hangs their coat on that same peg. The teacher glances at the label, sees the old name, and treats the new coat as if it belonged to the first child.
Normally that’s a harmless mix-up. But if someone works out how to hang a coat on that exact peg on purpose, they can get the teacher to treat their coat, with whatever’s in its pockets, as something trusted.
That’s bug two. PHP keeps a “label” pointing at a bit of memory even after that memory has been handed back and reused. The next visitor’s request can sneak something into that memory, and PHP trusts it because the old label is still there. Security people call this a use-after-free: using something after you’ve already let it go.
What “take control of the server” actually means
Both bugs can lead to remote code execution. In plain terms, a stranger on the internet gets to tell your web server what to do, as if they were sitting at its keyboard.
From there, depending on how the server is set up, they could:
- read your passwords, customer details, API keys and database contents
- add hidden spam pages or redirects to your site
- install malware that infects your visitors
- use your server to attack other websites
And the bit that makes this genuinely nasty: they don’t need to log in, and it can happen before WordPress even starts running. No plugin can block it, because the problem is underneath where plugins live. Researchers showed it working against WordPress, Drupal and Joomla, and noted that even a bare “Hello World” page on an affected PHP version could be vulnerable.
How Did a Decade-Old Bug Go Unnoticed?
The faulty code has been sitting in PHP for over ten years. Nobody spotted it because these kinds of bugs are extraordinarily hard to find and even harder to turn into a working attack. The conditions have to be just right: memory laid out in a particular way, on a particular version, with a particular setup. Doing that by hand used to take a specialist months, and most bugs like this were written off as “theoretically bad, practically impossible”.
Then AI changed the maths.
The research team at Wiz, who found and reported the bugs in August 2026, used several AI models during the work, and said Google’s Gemini model “made an invaluable contribution to finding the vulnerability, exploit development, attack detection, and validation of the patch.” Separate researchers working with OpenAI’s Patch the Planet programme, which uses AI to hunt for bugs in widely used open-source software, also revisited older PHP memory findings.
The bugs were already there. AI made them practical to exploit. That’s the whole story in one sentence.
The Timeline (and Why It Went Messy)
These things are normally handled quietly. Researchers tell the software makers, a fix is prepared in secret, and everyone announces it on the same day so website owners can patch before the bad guys know what to look for. This time it didn’t go to plan.
- 19 August 2026: Wiz finds the first bug.
- 24 August: Reported privately to the PHP security team.
- 17 October: Amazon’s network of decoy servers records someone trying to exploit it, four days before it was made public.
- 20 October: Details leak online a day early. The post is removed, but screenshots spread.
- 21 October: PHP releases the fix and the full details go public.
So the usual head start that website owners get was shorter than it should have been. That’s why hosts and security firms have been treating this as urgent.
What You Should Do Today
1. Find out which PHP version your site runs. In WordPress, go to Tools → Site Health → Info → Server. Your hosting control panel will show it too.
2. Check it against this list. You’re safe if you’re on one of these, or newer:
- PHP 8.5: safe from 8.5.12
- PHP 8.4: safe from 8.4.27
- PHP 8.3: safe from 8.3.36
- PHP 8.2: safe from 8.2.35
- PHP 8.1 or older: no official fix. Move up to a supported version.
PHP 8.1 and older are already “end of life”, meaning the PHP team no longer releases updates for them. Because this is so serious, they did publish rough patches for 7.4, 8.0 and 8.1, but those are for people who compile PHP themselves. If you’re on shared or managed hosting, the realistic answer is: upgrade to PHP 8.2 or newer.
3. If you’re not sure, ask your host. Send them one line: “Have you applied the October 2026 PHP security updates (CVE-2026-109618 and CVE-2026-109619) to my server?” Good hosts will have an answer ready. Some, like SiteGround, put protections in place across all their servers before the announcement.
4. Be careful jumping several versions at once. Moving from, say, PHP 7.4 to 8.3 can break old plugins and themes. Take a full backup first, and ideally test on a staging copy of the site. This is the part where people get caught out: they’re right to want to update, but they do it live on a Friday afternoon.
5. Don’t rely on a security plugin for this one. Wordfence and friends are useful, but they run inside WordPress, and this attack can happen before WordPress loads. A firewall in front of your site (Cloudflare, for example, rolled out rules for free accounts too) helps buy time. It isn’t a substitute for the update.
Will We See More of This With AI?
Yes. Almost certainly. Here’s why, still in plain English.
Old locks, new lock-pickers
Imagine every house on your street has had the same lock for twenty years. It’s always had a tiny flaw, but picking it took a master locksmith a month of patient work, so nobody bothered.
Now someone hands out a tool that lets a fairly ordinary person pick it in an afternoon.
The locks haven’t changed. What changed is how hard they are to open. That’s what AI is doing to software. There is a huge amount of old code running the internet, and much of it contains flaws that were always there but were too fiddly to use. AI is very good at fiddly.
It works for the good guys too
This is the important bit, and it’s genuinely encouraging. The same tools that help attackers help defenders. PHP2Shell was found by researchers using AI and reported responsibly, which is how it got fixed. Projects like OpenAI’s Patch the Planet, and similar work from other AI companies, exist specifically to find these holes and fix them before criminals do.
So the likely future isn’t “AI makes everything unsafe”. It’s:
- More security announcements, more often, as AI digs up old bugs.
- Less time between an announcement and real attacks. Days rather than weeks, and sometimes, like here, attacks before the announcement.
- A bigger gap between looked-after websites and abandoned ones. Sites that get updated promptly will mostly be fine. Sites that haven’t been touched in three years will be the easy pickings.
What that means for a small business
The old approach of building a website, launching it and leaving it alone for years is getting riskier every month. It isn’t about being a target. Attacks like this are automated. Bots scan the whole internet for vulnerable servers, and they don’t care whether you’re a multinational or a florist in Falkirk.
The protection is boring, and that’s the good news:
- Keep PHP, WordPress, plugins and themes up to date.
- Use a decent host that patches its servers quickly.
- Keep regular backups stored off the server.
- Have someone responsible for noticing when something like PHP2Shell happens.
None of that needs a security degree. It just needs doing, consistently.
The Bottom Line
PHP2Shell is serious because it sits in the engine room of most of the web, and because AI turned a long-hidden flaw into something people can actually use. But the fix is straightforward: get onto a patched PHP version, and make sure somebody is keeping your site updated from here on.
If you’d rather not be the one checking PHP versions and reading security bulletins, that’s exactly what our website management service covers. We’ll check your site against this issue and keep it patched going forward. Get in touch if you’d like us to take a look.
