PHP2Shell, one week later: who patched, what attackers did, and the third bug

The numbers, one week in

The clearest public measurement comes from Brandefense, which ran a free checker from October 21 to 25. It made 40,849 checks against 30,027 sites, each check a single ordinary homepage request that reads the PHP version from the response headers. No exploit traffic. Only about 12 percent of those sites, 3,532 of them, showed a readable PHP version at all. Of those:

Put the middle two rows together and 59 percent of sites with a readable version were running something older than the fix. The trend is better than the total: the patched share of sites checked on October 21 was 21 percent, and by October 25 it was 50 percent. Of 84 unpatched sites on a supported branch that were checked again on a later day, 55 had patched by their last check. People are moving, but a lot of sites have not moved yet.

Two caveats the researchers make themselves. Visitors chose which sites to check, so this is not a random sample of the web. And a hidden version is not a safe version: 9,411 sites in the sample hid their PHP version entirely, and nobody outside can tell what they run. The wider counts point the same way. VirusTotal counted about 1.1 million servers that disclose a PHP version, roughly 758,000 of them on end-of-life branches, and Check Point counted about 884,000 hosts advertising PHP 8.1 or older in their banners. Those are banner counts, not confirmed vulnerable machines, but a banner that says 8.1 is not reassuring.

What attackers actually did

They did not wait. Amazon reported that its honeypots logged an exploit attempt on October 17, four days before the public disclosure. Once the bugs were public, Cloudflare saw attempts climb from tens of thousands in the first 45 minutes to millions by the early hours of October 22. Sophos and Arctic Wolf both saw attackers trying to use the flaws to install a variant of the Mirai botnet, the same malware family that has been hijacking routers and cameras for a decade.

The better news, as of this writing: Wordfence and other monitoring teams report scanning and probing but no confirmed remote code execution in the wild. Researchers say a reliable exploit has turned out to be harder to build than the proof of concept suggested. That is a reason to patch calmly, not a reason to skip it. Mass scanning is how attackers build their list of targets, and the list is being built now.

A third bug, and why it is not an emergency

On October 23, two days after the emergency releases, PHP published an advisory for a third issue, CVE-2026-115560, another potential remote code execution path through the session upload progress feature. It is not fixed by 8.5.12, 8.4.27, 8.3.36, or 8.2.35. PHP has chosen to fix it in its next routine release rather than ship another emergency build, and it has not yet said which versions are affected or scored the severity. The Hacker News and Infosecurity Magazine both carry the details.

The reason PHP calls it unlikely is the set of conditions an application has to meet, all at once:

• The configuration sets session.serialize_handler to php_binary or php_serialize.
• The application then switches that setting to php at runtime with ini_set().
• It does so before calling session_start().
• Session upload progress is still enabled, which is the default.

Stock WordPress, Drupal, and Joomla do not do this. Most custom applications do not either. But the mitigation costs nothing and is the same setting PHP already recommended on October 21 for one of the original bugs, so there is no reason to leave it on:

session.upload_progress.enabled = 0

If you or your host applied that line last week, you are already covered for the third bug. No exploitation of CVE-2026-115560 has been reported.

What hosts did

Responses ranged from quiet to drastic. Hostinger says its shared, agency, and cPanel plans were covered by its October 21 mitigation, and that customers on a VPS manage PHP themselves, which is the usual split: on shared hosting the host owns the runtime, on a VPS you do. At the other end, Widomaker, a Plesk-based host, took customer sites offline on October 21 until patched PHP builds were available, and brought them back the same day once the updates landed.

The pattern from last week holds. "We have added protection" usually means a firewall rule or a disabled feature. "PHP has been updated to a fixed release" is the sentence you want in writing. If your host has not sent you either, ask.

Meanwhile, the plugin layer kept going

PHP2Shell was the headline, but the ordinary flow of WordPress plugin bugs did not pause for it. A roundup of October 23 and 24 counts 29 CVE records published in those two days alone. The ones worth knowing about:

None of these is reported as exploited yet. The point is not any single plugin. It is that a WordPress site has two layers that need patching on two different schedules by two different people, and last week showed what happens when the layer you cannot touch is the one that breaks. We wrote about that trade-off on day one and nothing since has changed our mind.

What to do this week

1. 1.Check the PHP version again. In WordPress that is Tools, then Site Health, then Info, then Server. If it reads 8.2.35, 8.3.36, 8.4.27, 8.5.12 or higher, the original bugs are fixed. If it reads 8.1 or lower, you are on a branch with no upstream fix and the host has to confirm a backport in writing.
2. 2.Ask the host one more question: is session.upload_progress.enabled set to 0 on the server that serves my site? That closes the third bug until PHP ships the real fix.
3. 3.If the site was exposed between October 17 and the day it was patched, assume scanning reached it. Run a malware scan, look for files you do not recognise in the web root, and rotate the database password, any API keys in the configuration, and the admin passwords. Our day-one guide has the full checklist.
4. 4.Update plugins, and delete the ones that have been closed with no fix. A deactivated plugin still sits on disk.
5. 5.If you are on an end-of-life PHP branch, start the migration plan now. This was not the last PHP bug, and the next one will not have a backport either.

Where we can help

For one site, we check what is really running, get the written confirmation from the host, apply the interim settings, and sweep for compromise, with a short written summary at the end. For an agency with a list of client sites, the same thing runs as a batch under your name through our white-label service. And if the site is on an old PHP branch with a stack of plugins nobody maintains, we will tell you straight whether patching is worth it or whether a rebuild on our process ends the cycle. Start with the contact form or call; the engineer answers, not a queue.