On Wednesday we wrote that the PHP2Shell flaws had to be fixed by whoever runs your server, not from your WordPress or Drupal dashboard. Two days later, three things have changed what we would tell an association that has not finished.
Amazon's threat intelligence team says attacks began four days before the fix existed. WordPress.org has told some site owners to consider taking their servers offline. And Google has said how to do that without damaging your search rankings.
Where this comes from. Amazon's security blog post, the WordPress.org announcement, the PHP project's advisory, Google's own crawling documentation and John Mueller's public post, all read directly.
The Attacks Started on October 17
Amazon Threat Intelligence published on October 21 that its MadPot honeypot network recorded a PHP2Shell exploitation attempt dated October 17, four days before the PHP project released fixes. More attempts followed on the 21st, from several sources, using varied payloads.
Amazon is careful about the claim. Amazon says it is unclear whether any of those attempts would have succeeded against real systems. What it does not hedge on is where an investigation should start: from October 17, not from the disclosure date.
What that means for you. If your PHP was patched on the 21st or 22nd, that is good, and it is not the end of the job. A patched server can still carry something placed before the patch arrived. Ask your host or your IT provider to review web server logs and file changes from October 17 forward, not from the 21st.
WordPress.org Said What Most Hosts Have Not
WordPress.org published its own notice on October 21. It says the issue is not specific to WordPress and that no WordPress update is required or planned for it. It tells site owners to update PHP immediately and to check with their host, which may already be applying updates or firewall rules.
And for older PHP, it went further. For anyone running PHP older than 8.2 on hosting they manage themselves, WordPress.org says to consider taking the server offline while upgrading, citing guidance from the UK's National Cyber Security Centre. Those versions no longer get updates from the PHP project, so there is no patch to wait for.
Why a Maintenance Mode Plugin Does Not Help
The natural instinct is to switch on a maintenance mode plugin and patch behind it. For this vulnerability, that does nothing.
The PHP project's advisory describes a demonstrated exploit in which a single unauthenticated request triggers the attack before any application code runs. A maintenance mode plugin is application code. By the time WordPress loads to show the maintenance page, PHP has already processed the request that matters. Taking a site down for this means stopping requests before they reach PHP at all: at your CDN, at the web server, or by pointing DNS somewhere else.
If You Take It Down, Serve a 503
Google's John Mueller posted on October 21 that sites taking PHP down to deal with unplanned updates should serve an HTTP 503 rather than letting requests time out or return a 404 or a 500, and that this can be done outside PHP, at the DNS or CDN level.
The difference matters. Google's crawling documentation says server errors make its crawlers slow down and that already indexed pages are kept for a while. A 404 tells Google the content does not exist, and previously indexed pages get removed. One is a pause. The other is a delete.
Keep it short. The same documentation says pages that persistently return server errors are eventually dropped from the index. It does not give a timeline. A planned outage of hours is fine. An outage of weeks is how a fix for a security problem becomes a search problem.
Where Pantheon Stands
Our own site runs on Pantheon, so we have been watching. As of Friday morning, October 23, Pantheon's release notes show no PHP security update since September 25. They do show a change on October 20 making PHP 8.3 the default for its Drupal upstream. Our own environments, though, now report PHP 8.4.27, the patched release. Pantheon patched without publishing a note, which is exactly why silence in the release notes is not proof either way. It is a reason to ask, and to ask for the version number in writing.
What to Do Now
- Confirm the exact PHP version. 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or later. In WordPress it is under Tools, Site Health, Info, Server. In Drupal, the status report. Every environment, not just live.
- Check from the right date. Ask for log and file reviews starting October 17, the date Amazon recorded the first attempt.
- If you must take a site offline, do it upstream. Stop traffic before it reaches PHP, at the CDN, web server or DNS, and serve a 503. Not a maintenance plugin, not a 404.
- Treat old PHP as an emergency. If any environment is on PHP 8.1 or older, the PHP project will not fix it. That upgrade is now this week's work, not next quarter's.