PHP2Shell Explained: The Bug Under Most of the Web
Written on 23 October 2026. Security news moves fast: check the PHP advisory for the latest.
On Wednesday 21 October, a lot of websites had a bad morning. In the Netherlands, some switched themselves off. Even the parliament's. Even the national cyber security centre's. On purpose.
The reason has a name: PHP2Shell.
Prefer to watch? This post is also a short video.
What PHP2Shell is
If you've never heard of PHP, that's fine. You've used it. It's the language behind about seven in ten websites. WordPress, Magento, Drupal, Nextcloud. All PHP.
PHP2Shell is two bugs in PHP itself, CVE-2026-109618 and CVE-2026-109619. Not in a plugin. Not in someone's sloppy code. In the engine underneath all of it. A stranger, with no password and no account, can run their own code on your server. Both bugs scored 9.2 out of 10.
And on one of the most common setups, Apache with mod_php, PHP's own team says the attack can fire before any of your code runs. So you can write perfect code and still be open. Your code doesn't even get a vote.
How old is this? Every PHP version back to 5.4. More than a decade. More than a decade of the best developers and auditors in the world, reading this exact code.
It was found with AI
Here's the part I can't stop thinking about. It was found with AI.
In August, a security firm called Calif was auditing PHP with one of OpenAI's models. Generally available models. No special tools. They said knowing PHP's history mattered more than the model. Fair. But the model was there.
Then, weeks later, a second team, Wiz, found the same bugs on its own, with AI too. Wiz says one researcher did in a week what used to take a world-class team months.
More than a decade of nobody. Then two teams in a month.
And if AI makes an old bug findable in days, it's findable by everyone. Not just the people who report it.
The leak
The fix was being made quietly, the normal way: find it, report it, patch it, then tell the world. On 20 October, the details got out before the patch did. PHP rushed the release out the next day. Cloudflare says it saw attacks hours before the patch shipped. Amazon says it saw an attempt four days before that.
So for a while, the attack existed, and the fix didn't.
Finding is fast. Fixing isn't.
Which leaves me with one question. If AI finds bugs in days, can we fix them in days?
Because finding is fast now. Fixing isn't. PHP got the first report on 11 August. The fix came out on 21 October. Ten weeks. For a project this size, that's not slow. That's normal. And the leak still beat it. Then every server owner on Earth has to install it themselves. It doesn't happen on its own.
To be fair, this might not be the end of the internet. Sansec, who watch online stores, now think mass attacks are less likely than they feared: the public exploits don't work on a default install. watchTowr says its traps caught it being used anyway. The honest answer is, nobody knows yet.
What to do
If your site runs on PHP, update to one of these:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
On 8.1 or older, PHP isn't shipping a fix at all. Ask your host, or move up. And no setting makes you safe. In PHP's own words: "There are no complete mitigations, updating is the only safe choice."
AI just found a decade-old hole under most of the web. It'll find the next one too. The question was never whether AI can find bugs. It's who it finds them for first.