Not long ago I wrote about all the things that go into maintenance and the things that sit underneath your WordPress install. The things that nobody really sees, that people don’t want to take responsibility for, and that only get their due consideration when something goes wrong.
And wouldn’t you know it, two critical flaws in PHP itself have just been disclosed. Not in a plugin. Not a theme abandoned in 2014. In PHP. The language everything else is written in.
What actually happened
The duo have been named PHP2Shell, and are tracked as CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10 on CVSS v4.0. Both vulnerabilities enable remote code execution without requiring authentication, which is the highest level on the CVSS scale of severity.
Translating that to real-world impact:
- CVE-2026-109618 – if PHP runs out of memory at the wrong moment, it can leave request data half set up, and the cleanup then trusts that garbage as if it were valid.
- CVE-2026-109619 – bits of a request’s internal state can hang around after the memory behind them has been freed. Classic use-after-free.
The researchers also found out Heartbleed-style information leaks of the PHP worker memory. As such, even if the attacker does not gain a shell, they might get access to the memory of the server that the application previously used.
The disclosure did not exactly go as planned. As can be seen, the CVE IDs appeared on Hacker News on 20 October, one day before the coordinated disclosure was scheduled to take place. PHP released the necessary security updates on 21 October at 14:00 UTC.
The bug affects all the PHP-based software that is capable of fulfilling HTTP requests. These include PHP-FPM, mod_php-powered Apache HTTP Server, php-cgi, FrankenPHP and LiteSpeed. Patchstack notes that mod_php configurations are the most dangerous, as the exploitation attempts are already reported. In other words, all the PHP-based CMSes, such as WordPress, Drupal, Magento, Joomla!, Laravel PHP framework and others are at risk.
| Branch | Fixed in |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
The affected range runs from PHP 5.4 all the way to 8.5.11. Pretty much everything from the last decade and a bit.
Who found them? The big bad wolf
And here’s the thing. Who found this stuff? That glorious scourge of the 21st century the world has spent the last two years in a panic over: AI.
A security firm, Calif, found the initial problem earlier this August, assisted by OpenAI’s GPT-5.6 Sol in a PHP source audit funded by OpenAI itself. Wiz Research found the same class of bugs, independently, on the 19th of August, using their Wiz Atlas system, Gemini 4 Argon and GPT-5.6 Sol from Google and OpenAI, and reported to PHP on the 24th of August. The PHP advisory credits Calif, Wiz and OpenAI’s contributions.
Wiz estimates it took one researcher with access to frontier models a week to find a vulnerability that would previously take a room of people months to find.
These aren’t new problems: they’ve been in the code for over a decade, hiding in plain sight, under the eyes of every human who has ever read that code.
This isn’t the first time, either. In July, the wp2shell, a pre-auth RCE chain in WordPress core, was found by Searchlight Cyber using an OpenAI GPT-5.6 Sol model.
When we were promised the end of human existence as we know it, this is not what we were expecting. Instead, we got twenty years of humanity’s work in the field of computer security, pointed at a single codebase, laughing and telling us to go and patch some vulnerabilities because it thinks it sees some. The apocalypse scenario is a very long night for the sysadmins.
To be fair to the humans, it wasn’t all the machines. A write-up by Dead Neurons notes that all the ingredients to PHP2Shell were already present and known, being a combination of existing advisories, a single bug report from 2020, and the source code itself, and that the models needed human help to tie them together. Which is basically what I’ve been arguing for this whole time. Models are great, but can’t replace a pair of experienced hands who know where to look.
The inconvenient truth is that the same tools can be used by the other side, too. OpenAI predicts the AI got there before the attackers did, this time around. And if this really is how it works, then the window between “I’ll update PHP next month” and “now” is closing fast.
The bit nobody reads
Look at that table again. There’s no 8.1. There’s no 7.4. Patches only exist for the supported 8.x branches. If you’re on PHP 8.1 or lower, there is no point release coming to rescue you. Your only fix is to move up a branch.
And how many people is that? According to W3Techs, as of today:
| PHP version | Share of PHP sites |
|---|---|
| 8.x | 65.2% |
| 7.x | 27.0% |
| 5.x | 7.7% |
| 4.x | 0.1% |
So 27% of PHP sites are on version 7, and nearly 8% more are still on 5 or older. Call it roughly a third of all PHP sites on the web running a version that will never be patched. And that’s before you count the 8.0 and 8.1 stragglers hiding inside the “8.x” figure.
PHP runs about 69% of the websites whose server-side language W3Techs can identify. A third of that is not a rounding error. That’s a lot of servers.
Where’s the PHP selector?
So 27% of PHP sites are on version 7, almost 8% are on 5 or lower. So about a third of all PHP sites on the web have versions that won’t be patched. And that’s not even counting the 8.0 and 8.1 stragglers hiding inside the “8.x” figure.
PHP powers around 69% of the websites whose server-side language W3Techs can identify. A third of that is not a rounding error. That’s a ton of servers.
My real question is, the advice is “upgrade PHP”. Fine. How many of the people running those sites know where the PHP selector is?
Lots of these sites were built years ago by someone who’s long since gone. A nephew. A freelancer. An agency that folded. The owner has a WordPress login and a hosting invoice, and that’s the whole extent of their relationship with the stack. They’ve never opened cPanel. Don’t know it has a MultiPHP Manager. Don’t know their site is on PHP at all.
And the ones who do find the dropdown? That’s where the fun starts. Picture it:
- Jump from 7.4 to 8.3 and the site falls over with a fatal error, because a plugin is calling a function that’s been removed years ago.
- The custom theme the nephew wrote throws warnings up the top of every page.
- A shiny new 403, because the hosting’s handler config or an .htaccess rule was written for the old version.
- That one page builder, last updated in 2019, which just will not load.
- A site that was “working fine” for six years, now very much not, and nobody to ring.
This is precisely why I was talking about the layers under WordPress. Nobody budgets for PHP upgrades. Nobody tests against the next version. So when it becomes urgent instead of optional, all those postponed maintenance tasks come due at the same time, on the same afternoon, with the attackers already knocking.
Rather them than me
So somewhere out there tonight, the poor bastards are clicking that dropdown, hitting save, refreshing a white screen. Reading through error logs they never knew had existed. Googling ‘PHP 8 deprecated each()’ at eleven o’clock at night.
And here I am, fresh coffee, feet up, thinking, rather them than me.
If you are one of them, here’s the short version;
- Find out what you’re on. Your hosting panel will say, or a Site Health check in WordPress will (Tools → Site Health → Info → Server).
- On 8.2 to 8.5? Get the point release – 8.2.35, 8.4.27 and so on. On managed hosting, check your host has rolled it out. Don’t assume.
- On 8.1 or lower? There is no patch for you. You need to move branch, so take a backup first and test on staging if you possibly can.
- Update plugins and themes before you switch PHP. Half the breakage is old code, not PHP itself.
- If something breaks, roll back fast, then fix properly. But don’t leave it on the old version for long. Not this time.
And if none of that made any sense to you, that’s fine. That’s what the people underneath the layers are for. Ring one.
Sources
- W3Techs – Usage statistics of PHP for websites
- Patchstack – PHP vulnerable to critical RCE, attacks ongoing
- Help Net Security – PHP2Shell patched, update now
- Google Cloud – Responding to core PHP vulnerabilities
- JFrog – PHP2Shell: all you need to know
- Infosecurity Magazine – Critical PHP vulnerabilities leaked ahead of patch
- Tenable – PHP2Shell FAQ
- Wiz Research – PHP2Shell: AI uncovers critical RCE vulnerabilities
- The Next Web – PHP rushes out emergency patches for bugs AI found first
- CNN – AI helped find a critical security flaw affecting 70% of the internet
- Dead Neurons – PHP2Shell was in the training data
- Wiz – Exploitation in the wild of wp2shell
Comments (0)