PHP has been my main programming language since I was a teenager. You know a bug is serious when companies are shutting down their sites and prime ministers are talking about it.
PHP2Shell was fixed on 21 October. Since [Sockt.com](https://sockt.com) is a tool within [Raq.com](https://raq.com), I thought I'd see how fast people are patching.
My agent wrote the purple parts. I give them a Jeeves voice so it doesn't feel like cheating, as in [How I use agents to do everything](https://vu.co.uk/blog/how-i-use-ai-agents).
Each dot is about 3,200 of the websites Sockt has analysed.
Most of the internet runs on PHP.
Quite so. W3Techs puts it at 69.3% of the websites whose server-side language it can detect. Of the 38,505,248 websites Sockt has analysed, 18,595,911 use PHP, and WordPress alone accounts for 13,682,836 of them.
Of the websites Sockt has analysed use PHP.
The nature of PHP2Shell #
Two memory bugs in PHP itself. One is in how PHP handles running out of memory, the other lets stale data survive from one request to the next. Together, an attacker can run their own code on the server without logging in.
It can be triggered before any WordPress, Drupal or Laravel code runs, so updating WordPress or its plugins does not help. PHP itself must be updated.
It was discovered with AI. Ryan Austin at Calif found it in August with help from GPT-5.6 Sol, a publicly available model, in an audit funded through OpenAI's Patch the Planet programme. OpenAI found a fuller version in September, with its most capable model working on its own. Wiz found it separately with its own tool, using Google's Gemini 4 Argon and GPT-5.6 Sol. Wiz asked the tool for a Drupal bug, then asked it to port that to WordPress. About eight hours later, Wiz says, it came back with: "No, I could not port this bug to WordPress. However, I did find a more generic bug that can be exploited on both WordPress, Drupal, and probably any other PHP application."
The course of events #
Details leaked on 20 October, so PHP brought the fix forward a day, to 14:00 UTC on 21 October. An hour before, Japan's prime minister, Sanae Takaichi, asked everyone to check whether their websites use PHP, and suggested taking a site offline as one way to reduce the risk. The Dutch prime minister, Rob Jetten, posted that afternoon that DigiD and MijnOverheid would come back online once it was safe.
Orange, ANA and the Internet Archive took sites offline as a precaution, and Wikimedia took some of its services down. One Swiss host, Cyon, pulled more than 100,000 sites. In the UK, 32 government services were unavailable.
Matthew Prince, Cloudflare's chief executive, told TBPN that in the hours before the patch "we were seeing thousands of attacks across our network. At this point, we're now seeing millions of attacks per minute."
The same week #
On the same day, Node.js fixed ten flaws of its own. One of them could let an attacker run their own code on a server, and OpenAI's Codex Security team reported it.
That release also stopped trusting eight certificates from eMudhra, an Indian certificate authority that says it has issued more than 60 million certificates. The keys behind them are meant to be random numbers over 100 digits long. eMudhra's were 4, 56, 66, 115, 155, 156, 230 and 237. Anyone with them could make trusted certificates for any website, and anyone could have worked them out from the public certificates at any point in the 17 months since they were made. Scott Helme says Claude recovered them with a single prompt. eMudhra is now leaving the global SSL/TLS business.
Matthew Prince expects more: "I think for the next two years, we're going to basically have kind of a week like this on average almost every week."
A lot of sites tell anyone who visits exactly which version of PHP they're running. You won't see it on the page, but it's sent along with every page for anyone who looks. It's a bit like a shop putting the make and model of its locks in the window. Most security-conscious site admins switch this off, but millions of sites still don't.
PHP's own manual advises hiding it. Sockt can read a version on 6,381,009 PHP sites. 3,175,713 of them are on 8.1 or older, which received no official release. The PHP team did publish minimal source patches for 7.4, 8.0 and 8.1, for those who build PHP themselves. Over 580,000 sites are still on PHP 5 or older.
- 8.2 to 8.5, fixed releases on 21 October: 3,205,296
- 8.1 and older, no official release: 3,175,713
The recheck #
I checked nearly 1 million sites that were showing an older PHP version to see if they've patched. Of the 825,000 still showing a version, 24% have, they now show the fixed version. Another 23% are on Hostinger, which says it added the fix without changing the version number, so they've very likely patched too. The other half you can't tell from the outside without attempting the exploit, which is a legal no-no.
The method: a million sites were picked at random from every site showing a version older than the fix, and 964,653 of them had a full version number to compare. SocktBot, Sockt's crawler, visited each one again on 22 and 23 October, reading the same public pages any visitor sees. 824,947 answered with a full version.
- Patched, now showing a fixed release: 200,568
- Very likely patched, an older number on Hostinger's managed hosting: 192,251
- Can't tell, an older number elsewhere: 432,128
- No version to read, or no answer: 139,706
Each dot is 480 sites.
Some hosts add the fix to the PHP they already run, so the version number does not change. Hostinger says so: "The security fix has been added to the PHP version your website already uses, so the version number does not change." All of them were identified by the header Hostinger's managed hosting adds, seen in the same recheck. Only one Hostinger site in the sample shows a new number.
CloudLinux, used by many cPanel hosts, lists its patched builds as 8.2.34, 8.3.35, 8.4.26 and 8.5.11, the same numbers as before. Of the 256,551 sites on 8.2 to 8.5 still showing an older number, 239,483 show exactly those. Ubuntu, Red Hat and AlmaLinux do likewise.
Where the number does change, the picture is clearer: 94% of the Plesk sites we checked on 8.2 to 8.5 already show the fix.
Some will have patched quietly, but there are likely still a huge number that haven't. So if you know anyone with a website that holds sensitive data and they aren't technical, let them know.
Here are a few high-profile ones that have patched: home.cern, dreamworks.com and vaticanstate.va.
Not everyone realises the severity. Pieter Levels posted this an hour before the fix came out:
Remarks from TBPN and YouTube #
TBPN covered it on both days. A few lines from that and from YouTube:
"Some dude on Twitter could take the patches and run AI against it and post some exploit script... All hell will break loose."
Thai Duong, CEO of Calif, in the Wall Street Journal,read out on TBPN "They can put the patch out there, but they can't push the patch... Not every long tail website in the world is going to be aware this has happened."
Nikesh Arora, CEO of Palo Alto Networks,on TBPN "AI is not the bad guy here, AI is the good guy. AI didn't create these vulnerabilities, AI found them."
Matthew Prince, CEO of Cloudflare,on TBPN "Most site owners don't control their version of PHP. The host does."
Kevin Powell,[This PHP vulnerability is a big deal](https://www.youtube.com/watch?v=cBD1AgkM1VQ)
If you're not sure what your sites are running, [get in touch](https://vu.co.uk/contact) and we'll check.
Big outlets are pretty bad at tech news. The BBC's cyber security correspondent said he hadn't heard of PHP until this week, and it's the language behind most of the web. That's a big part of why shows like TBPN have taken off.