On Tuesday the PHP project shipped an emergency release for two critical flaws in PHP itself. Not a plugin. Not WordPress. The language your website runs on. Cisco Talos is calling the pair “php2shell” and says both are unauthenticated remote code execution, triggered by a plain HTTP request, before any of your application’s code even runs. They affect every PHP build going back to version 5.4.
Talos began seeing exploitation attempts within hours of disclosure. The SANS Internet Storm Center raised its threat level to yellow, which they do maybe a couple of times a year, citing the sheer spread of PHP and the fact that working exploit code circulated before the patch existed.
If you own a small business with a website, this is your problem whether or not you think of yourself as having a server.
What “unauthenticated RCE” actually means for you
Remote code execution means an attacker runs their own commands on your machine. Unauthenticated means they do not need a password, an account, or a stolen session. They send a request to your site the same way a browser does, and they get a shell.
From there the usual sequence follows: drop a web shell so they can come back, scrape the database (customer records, order history, hashed passwords, whatever your contact form has collected for the past six years), inject redirect or skimmer code into the pages your customers see, and in the worse cases use the box as a foothold toward anything else on the same network. A compromised website is also a compromised email reputation, since attackers love sending from a domain that already passes authentication checks.
Both bugs are rated 9.2 on the CVSS v4 scale. The two mechanisms are different (one involves out-of-memory handling leaving request data half-initialized, the other reuses internal state after the memory behind it is freed), but the outcome is the same and neither requires the attacker to know anything about your site.
The blast radius is bigger than WordPress
Wordfence put it bluntly: every WordPress site runs on PHP, and this is a hole in PHP, not in WordPress, a plugin, or a theme. Keeping plugins current does nothing for you here.
Talos lists the rest: Drupal, Magento, Shopware, WooCommerce, Laravel, plus anything hosted behind cPanel or Plesk. That covers most of the small business web.
Here is the part people miss. A lot of firewall and router appliances run their admin interface on PHP. SANS noted bulletins from pfSense, OPNsense, Cisco, and Palo Alto within a day. If you have a firewall with a web login page, assume it is in scope until the vendor says otherwise, and if that login page is reachable from the public internet, fix that today regardless of this bug. Admin interfaces do not belong on the open internet. We said the same thing a few weeks ago about self-hosted tools, and it keeps being true.
Patched versions, and the half of the internet that will never get one
The safe releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Linux distributions are backporting the fix into their own package versions, so if your server runs Ubuntu or Debian or RHEL, the right move is almost always to take your distribution’s update rather than compile anything yourself.
Now the ugly part. PHP 8.1 and everything older is end of life. There is no patch and there will not be one. Talos estimates roughly half of PHP systems on the internet will not receive a fix at all. PHP 8.2’s security support runs out on December 31, 2026, so landing on 8.2 buys you ten weeks, not a year.
Plenty of small business sites are sitting on PHP 7.4 or 8.0 right now because someone built the site in 2019, it still loads, and nobody touched it. Those sites are permanently exploitable as of this week. The fix is not a patch, it is an upgrade, and sometimes a rebuild.
What to do, in order
Find out what PHP version each of your sites runs. Your host’s control panel shows it in one click. If you cannot find it, ask whoever built the site.
If you are on 8.2 through 8.5, update to the patched release today. Managed hosts (WP Engine, Kinsta, SiteGround and similar) are pushing this automatically, but verify instead of assuming.
If you are on 8.1 or older, you are not patching your way out. Plan the upgrade to 8.4 now and test it on a staging copy, because older themes and plugins will break.
If you cannot patch in the next day or two, SANS notes that setting session.upload_progress.enabled = Off is partial mitigation, and capping the maximum request size at your web server helps. Partial. Not a substitute.
Then check your firewall and router vendors for updates, and take their admin pages off the public internet while you are in there.
Keeping track of which version of what is running where, and updating it before someone else notices, is exactly the unglamorous work we do for clients. If you are not sure which of your sites would survive a week like this one, that is worth a conversation. Book a free 15-minute consult.