In our first PHP2Shell post the advice was simple: update. For a lot of people, it is not that simple. The patch exists only for the newest PHP branches, and a large share of the web runs something older.
The numbers
CybelAngel counted about 2.24 million internet-facing hosts that advertise PHP. Of the roughly 1.5 million that report a version, 883,717 (59%) run a branch with no official release. These are scan-banner counts of hosts, not of organisations or websites, so read them as a sign of scale, not an exact audit. A separate WordPress.org statistic puts 35.1% of WordPress sites on unsupported PHP versions.
In short:
- Fixed: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Support for 8.2 ends on 31 December 2026.
- Source patch only: 8.1, 8.0 and 7.4 got minimal source patches meant for people who build PHP themselves, not for typical hosting accounts.
- Nothing from PHP: 7.3 and older. Some distributions and long-term-support vendors may backport a fix, so check yours.
Are attacks happening?
Be careful here, because the early reporting is mixed. Cloudflare’s CTO said it saw early attacks and added temporary firewall rules for known exploit patterns. A security-news headline reports the first exploitation attempts hitting sensors. At the same time, other trackers noted no confirmed in-the-wild compromises, and the Australian Cyber Security Centre was not aware of active exploitation at the time. Remember the difference: an attempted exploit is not a successful intrusion. Still, an unpatched, internet-facing PHP host has a short window, and a forecast of mass scanning is credible given how many hosts are exposed.
Alleged exploit tools and screenshots are circulating. Do not run unreviewed exploit code or scanners against your own production systems to “test” yourself.
What could happen to your servers
The same as in the first post, but with a worse starting position: an attacker who reaches vulnerable PHP code can run commands as your web user, read configuration and database credentials, plant a web shell, and move sideways. If your host is on an unsupported branch, you cannot simply wait for it to go away.
Your options, from best to worst
- Move to a fixed branch. 8.4 or 8.5 is the best choice. Test your application first; jumping from 7.x is a real migration, not a button, so start the dependency and compatibility check today.
- Use a vendor build with a backport. Some Linux distributions and extended-support providers patch old PHP versions. Read the advisory for your exact package, then confirm the fixed package version is installed.
- Apply the source patch yourself if you build PHP and have the skills to test it. This is for teams that already compile their own PHP.
- Isolate it while you work. Put the site behind a VPN or an IP allowlist, take internet-facing admin and upload endpoints offline, and keep a firewall rule that blocks outbound connections from the web host.
- Use temporary firewall rules from your CDN or WAF. They help, but they are temporary and are not a fix. PHP’s own position is that there is no complete mitigation other than updating.
Be wary of shared “just turn this setting off” advice. Disabling session.upload_progress is widely repeated, but researchers say it is not enough on its own.
After you patch
- Restart PHP-FPM or Apache, then check the version of the web-serving process, not only
php -von the command line. - Hunt for signs of trouble, going back to at least June 2026: unexpected or recently changed
.phpfiles (especially in upload and cache folders), new admin users, odd child processes of the web server and unusual outbound connections. - Rotate secrets the PHP user could read if you find anything: database passwords, API keys and session secrets.
- Ask managed hosts in writing whether and when they patched.
Sources
CybelAngel’s analysis for the exposure figures and fixed versions, TryHackMe’s update for the exploitation timeline, and the Wiz research post. Verify version numbers for your branch at php.net.