php2shell, the evening after: what happened today and what is left to do

Written at 20:15 UTC on Wednesday 21 October, at the end of a long day. For the full detail, site owners have what it means for your WordPress website, and technicians have the working checklist.

The day in short

All times are UTC.

• Tuesday 20 October. Details of two critical flaws in PHP leaked a day before the planned fix. PHP announced an emergency release for 14:00 the next day.
• Wednesday, early. Cloudflare switched on emergency firewall rules for every plan, the free one included.
• Mid-morning. Cloudflare and the security company Patchstack reported the first attacks. Others, including Huntress, had seen none.
• Late morning. The PHP Foundation warned that Remi's repository, which many Red Hat-style servers rely on, would have no update today.
• Just before 14:00. PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with a security advisory. For 8.1 and older there is no release, only raw source repairs for 7.4, 8.0 and 8.1.
• Afternoon. Ubuntu published fixed packages. Ondřej Surý's widely used Debian and Ubuntu repository shipped fixes for every branch it carries, back to PHP 5.6. watchTowr reported exploitation attempts against both flaws on the decoy servers it runs to catch attackers.

As we write, nobody has publicly confirmed a successful break-in, and the US government's list of known exploited flaws (CISA's KEV) doesn't include either one. That is no reason to relax. Attempts are being made, and a break-in is not something people announce.

Where the flaws came from

They weren't found by accident. According to Wiz, whose researchers found them with the help of AI models:

19 August	The first flaw is found.
20 and 21 August	Wiz takes over a Drupal site, then a WordPress site, without logging in.
24 August	The flaws are reported to PHP's security team.
21 September	PHP acknowledges them and starts on a fix.
21 October	The fix is released, and the research is published.

A team at Calif found the same flaws independently, also with AI help. Wiz demonstrated them against the latest WordPress, Drupal and Joomla. It points out that none of those is needed: a one-line "Hello World" page on an affected PHP is enough.

So the leak cost the world one day's notice, not two months. Most of that time went where it should: on a fix, with Linux distributions given it in advance.

What is left to do

The fix being out is not the same as the fix being on your site. Before anyone calls today done:

1. Check it is running, not just installed. PHP keeps the old code in memory until it restarts. Look for 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. On Debian, Ubuntu and Red Hat packages, which keep their own version numbers, look for the two CVEs in the package changelog. Then check that PHP has restarted since.
2. Deal with old PHP. 8.1 and older will get nothing more from PHP itself. Surý's packages, cPanel and some paid support vendors have repairs, which buy time. Moving to a supported version is the only lasting answer, and the clock on 8.2 runs out on 31 December.
3. Remi users, PHP's advice still stands: switch to your distribution's packages, or build from source.
4. Look for signs of a break-in. Wiz suggests looking for oversized or malformed PHPSESSID cookies, odd file-upload requests followed by memory-limit errors or a run of 500 errors, and PHP workers crashing and restarting for no clear reason. None of those proves anything on its own, and a clean log doesn't prove you are safe. Section 5 of the checklist has more signs of a break-in to look for.
5. Change secrets on any server you have doubts about. Wiz showed that these flaws can also be used to read a server's memory, without taking it over. That memory can hold database passwords, API keys and login tokens. If a server was exposed for long and you can't rule it out, rotate them.
6. Leave upload progress off if nothing uses it. PHP suggests keeping session.upload_progress.enabled = 0 even after patching.

What today tells us

This is the second "2shell" of the year to reach WordPress sites. In July it was wp2shell, in WordPress itself, also found with AI help. Today it was the language underneath. The tools that found these flaws are getting better, and they read old code fast. There will be more days like this one, and they will come closer together.

Each of them lands hardest on the same kind of site: one that runs a program on every visit, to put together pages that are the same for everybody. A site saved as plain files gives today's flaws nothing to reach. There is no PHP on the server to attack, and nothing to restart at 14:00 on a Wednesday.

That is what Offramp is for. It moves a WordPress site to plain files and a simple editor, keeping the site exactly as it looks today. It doesn't replace tonight's patching, and nothing does. Make sure the fix is running first. Then, when the dust has settled, it is worth asking how many more days like today you want to have.