PHP2Shell: if your site runs on WordPress, update PHP, not the plugins

On 21 October the PHP project released emergency fixes for two bugs that now have a name, PHP2Shell: CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10. The release was planned for the 22nd and was moved up a day because the CVE numbers leaked on the 20th. Within hours there were public exploits, and attack attempts against honeypots.

If you have a website on WordPress, WooCommerce, Joomla, Drupal, Magento or PrestaShop, it runs on PHP. So this one is about you, even if you never typed a line of code.

Why this one is different

Most WordPress scares are about one plugin. You update the plugin, done. This is not that.

• The bug is in PHP itself, the engine under the site. A request can trigger it before WordPress or the shop code even runs, with no login.
• Updated plugins and themes do not protect you. Only a fixed PHP version does.
• Researchers have confirmed remote code execution without a login against specific versions of WordPress, Drupal, Joomla and Magento.
• It affects every common setup: Apache with mod_php (the highest risk), PHP-FPM behind nginx, php-cgi, FrankenPHP and LiteSpeed.

Is anyone actually attacking?

Yes, attempts are happening. How many succeed is not clear yet, and I would rather tell you that than guess.

• Amazon saw a PHP2Shell attempt against its honeypots on 17 October, four days before the fix, and says it is "now being broadly exploited in the wild". It also says it is unclear whether those attempts would have worked on real systems.
• watchTowr and Cloudflare report attempts too.
• Sansec thinks mass exploitation is less likely than it first feared, because the public exploits do not work against a default PHP install.
• It is not yet in CISA's list of known exploited vulnerabilities.

Attempts within hours, from more than one group, is enough for me. Treat it as urgent.

Which versions are safe

• Safe: PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer.
• PHP 7.4 to 8.1: no official release, only minimal source patches from the PHP team. If your host still runs these, ask what they are doing about it, today.
• PHP 5.4 to 7.3: no fix at all.
• PHP 8.2 reaches end of life on 31 December. If you are updating anyway, go to 8.3 or newer.

The five-minute check

1. Ask your host or check the panel. cPanel, Plesk and most hosting panels show the PHP version per site. If it is older than the list above, open a ticket.
2. If you run your own server, check the version PHP actually serves: php -v shows the command-line PHP, which is not always the same one the website uses. A quick phpinfo() page (delete it afterwards) or php-fpm8.3 -v tells you the real one.
3. On Debian, Ubuntu or RHEL, the distribution often patches the old version number instead of moving to the new one. Check your distribution's security notice for the PHP package, not just the number. Then apt upgrade or dnf upgrade.
4. Restart PHP after the update (systemctl restart php8.3-fpm, or Apache for mod_php). The old workers keep running the old code until you do.
5. If you have an agency or a web person, send them one line: "Is our site on a PHP version fixed for PHP2Shell?" If they cannot answer today, that is your answer.

If you cannot update today

The PHP team lists settings that make it harder (memory_limit=-1 that the application cannot override, session.upload_progress.enabled=0) and says plainly that they do not make an installation safe. Updating is the only complete fix. Cloudflare has firewall rules for the known attack paths, which it calls a stopgap.

The same month: nginx

On 14 October nginx released 1.31.7 and 1.30.6 with five fixes, all rated medium by nginx.org: buffer overflows (alias with rewrite, script evaluation), request body injection over HTTP/3, a use-after-free with AIO, and TLS session ticket forgery. That last one only matters with a shared session cache and no ticket key file, so your config decides if you are affected. I have seen no reports of attacks. Check with nginx -v and update anyway.

And npm: the one you cannot patch

npm is where web developers get their building blocks. On 8 October, tensorlake 0.5.144 was published with a worm that steals npm tokens, SSH keys, cloud credentials and .env files. The bad part: it went through the project's own release pipeline and carried valid build provenance, so the usual "is this package genuine?" check said yes. More malicious packages showed up through October.

This does not touch your server directly. It hits whoever builds your site, on their laptop and in their build system. What you can ask them: do they lock dependency versions, do they block install scripts, and do they use two-factor on their accounts.

What's still open

How many PHP2Shell attempts succeed is still unknown, and the picture is changing by the day. I will update this post if the PHP project or CISA confirm more.

Sources: PHP advisory, Amazon Threat Intelligence, Tenable FAQ, Sansec, nginx security advisories, Endor Labs on tensorlake.