C7 Security - Cybersecurity Experts

If your server runs PHP, update it today. On October 21, PHP fixed two critical bugs, together called PHP2Shell, that can let an attacker on the internet take over a web server. No password and no bug in your own code are needed: even a plain "Hello World" page can be vulnerable, and researchers demonstrated attacks on fresh WordPress, Drupal and Joomla installs.

Attackers didn't wait. Amazon's honeypots caught an exploitation attempt on October 17, four days before the bugs were made public. By release day, Amazon was seeing attempts from multiple groups, and Cloudflare has since reported millions of attack attempts.

The short version:

Check which PHP version actually serves your website, not just the one on your command line.
Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your Linux distribution's patched package.
Can't update today? Turn on your WAF's PHP2Shell rules and lock the server down, or take it offline until you can.

The rest of this guide walks through each step.

Am I affected?

Almost certainly, if PHP serves web pages for you. The flawed code goes back as far as PHP 5.4, released in 2012, so practically every PHP version in use today is affected. It doesn't matter which framework or CMS you use.

How you run PHP changes how urgent this is:

How PHP runs	Risk	Why
Apache with mod_php	Highest. Patch first	One request can trigger the attack before your code even runs
PHP-FPM (Nginx and most modern setups)	High	One attack path is blocked, but remote takeover was still shown under certain conditions
php-cgi, FrankenPHP, LiteSpeed	High	Named by PHP as affected
PHP 5.x, or 7.4 to 8.1 with no vendor support	Highest	No official patched release. You need a vendor backport or an upgrade

Check in 10 seconds. Don't trust php -v alone: it shows the command-line PHP, which can differ from the one serving your site. Check the one your web server uses:

Any site: drop a temporary <?php echo PHP_VERSION; file in your web root, open it in a browser, then delete it right away.
Debian/Ubuntu: dpkg -l | grep php lists installed PHP packages.
RHEL/Rocky/Alma: rpm -qa | grep php.
Docker: docker exec <container> php -v, and check which base image tag you build from.
Shared hosting or WordPress: look in your hosting panel's PHP settings, or under Tools → Site Health → Info → Server in WordPress.

Distributions often keep the old version number and backport the fix, so on Linux compare your package against your distribution's security advisory, not just the number.

A terminal showing php -v with a patched PHP 8.3.36 version: check the PHP your website runs, not just your terminal

Patch: the versions you need

Updating is the only complete fix. Workarounds lower the risk; they don't remove it.

Your PHP branch	Update to	Notes
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35	8.2 reaches end of life on December 31, 2026, so plan an upgrade
8.1, 8.0, 7.4	No official release	Use your vendor's patched build, or the source backports in php-src (branches `PHP-<version>-CVE-2026-109618-109619`)
5.x	No fix	Upgrade, or take it off the internet

How to update, by setup:

Debian/Ubuntu: sudo apt update && sudo apt upgrade (Ubuntu's advisory is USN-8948-1/-2).
RHEL/Rocky/Alma/Fedora: sudo dnf upgrade 'php*' (Red Hat: RHSA-2026:87080).
Alpine, Arch, Gentoo: patched packages are out; update as usual.
Docker: rebuild from the latest official php image tag and redeploy. Restarting an old container doesn't patch it.
Shared hosting: many hosts, SiteGround among them, put protections in place before the release. Check your PHP version in the panel; if it's old, open a ticket.
Remi's repository users: PHP warned it wouldn't have updates on release day, and we couldn't confirm a final release there yet. Switch to distribution packages or build from source.

After updating, restart PHP (PHP-FPM, or Apache for mod_php) so the old workers die, then re-check the version your site actually serves.

Can't patch today?

Buy time, in this order. None of these replaces the update, so give each unpatched server an owner and a deadline.

Put a WAF in front. Cloudflare shipped rules for the known attack patterns to every plan, including free. Fastly, Google Cloud and Vercel have protections too. WAF rules only protect traffic that actually passes through them, so make sure attackers can't reach your server directly.
Turn off session upload progress. Set session.upload_progress.enabled=0 in php.ini or your FPM pool config, then restart PHP. Setting it from your app with ini_set() or .user.ini is not enough.
On PHP 8.5, also set fatal_error_backtraces=0 and restart.
Cap request sizes at your web server or proxy: smaller bodies, fewer multipart parts, lower upload limits.
On PHP-FPM, pm.max_requests=1 gives every request a fresh worker. It costs performance, so use it only as a short-term shield.
Restrict access. Put admin panels and internal apps behind a VPN or IP allowlist.
Take it offline. The UK's National Cyber Security Centre advises taking systems you can't fix immediately off the internet, and the US NSA and CERT-EU gave similar advice. For a forgotten test server or old marketing site, that's often the right call anyway.

Running PHP inside products you didn't build? Palo Alto Networks says all PAN-OS and Panorama versions are affected and fixed versions were still pending as of October 22. Watch your vendors' advisories.

Signs you were already hit

Attack attempts were seen before the patch existed, so patching isn't the end. Your application logs will show little: the attack happens inside PHP itself. Look in web server and PHP logs instead, starting from mid-October:

Odd file-upload requests followed by memory-limit errors (Allowed memory size ... exhausted)
Bursts of HTTP 500 errors with no matching deploy or bug
Unusually large or malformed PHPSESSID cookies
PHP workers crashing or restarting far more often than usual

If you find these, treat the server as compromised: new PHP processes or files you didn't create, outbound connections you can't explain, new admin users. Isolate it, rotate the secrets it held (database passwords, API keys), and rebuild from a clean image rather than cleaning in place.

To test your public hosts, Searchlight Cyber released an open-source scanner, php2shell-scanner. Use it with care: it works by deliberately triggering PHP memory errors on the target, so run it only on your own systems and outside peak hours. Qualys, Rapid7 and Tenable have added detections too, and quiet logs don't prove you're safe.

We're helping too. Our team at Cerberus is running free PHP2Shell checks for any company: fill out a short form, verify your domain, and we'll tell you whether you're vulnerable. Our checks stay within the scope you approve and don't crash your servers. → c7-security.com/cerberus-php2shell

The bigger story: AI found it, and attackers moved first

These bugs sat in PHP's core for more than a decade. Researchers at Calif, OpenAI and Wiz found them in August using AI models, and it took two months to get a fix out.

A timeline of PHP2Shell: found with AI on Aug 19, reported to PHP on Aug 24, first attack seen on Oct 17, patch released on Oct 21

Date (2026)	What happened
Oct 21	PHP ships fixes; the bugs go public
Oct 17	First exploitation attempt seen in the wild, 4 days before disclosure
Sep 21	PHP confirms and starts on a fix
Aug 24	Wiz reports the bugs to PHP
Aug 20–21	Remote takeover confirmed on Drupal and WordPress
Aug 19	Wiz finds the first bug, with AI's help

This is what security looks like now. AI can find in weeks what humans missed for ten years, and attackers have the same AI. Nobody knows how the attacker got the details early. What matters is that the window between "a bug exists" and "someone is using it" is now days, not months. By October 22, the UK government had 32 services offline, largely as a precaution while it patched.

Annual pentests weren't built for this. A test you ran in March says nothing about a bug that went public on Tuesday.

Why we're giving away free PHP2Shell checks

What we're watching this week is chaos. Attacks started before the patch existed. Teams are patching blind, unsure which servers run which PHP. Forgotten test servers and old marketing sites are sitting exposed, and some vendor products still have no fix at all.

We're the team behind Cerberus, an AI ethical hacker built to test live systems safely: every action it takes is mathematically guaranteed to stay within the scope you approve. Because of this disaster, we've launched an initiative to help secure as many companies as we can.

Any company can get a free PHP2Shell check. Fill out the form, verify your domain, and we'll check it and send you the results. We only test domains you've verified as yours.

→ Get your free check: c7-security.com/cerberus-php2shell

If this guide helped, share it with whoever runs your servers. Someone on your team needs it today.