PHP2Shell is now being used in real attacks: what to do today

Last week I wrote about PHP2Shell, the two critical flaws in PHP itself. Back then the working attacks were ones security researchers had built to prove the point. Nobody had confirmed a real break-in.

That has changed. If your website runs on PHP and your host hasn't updated it yet, this is today's job.

What's changed

On 26 October 2026 the US Cybersecurity and Infrastructure Security Agency (CISA) added both flaws, CVE-2026-109618 and CVE-2026-109619, to its catalogue of known exploited vulnerabilities. A flaw only goes on that list when there's reliable evidence it's being used in real attacks. US government agencies have been told to fix them by 29 October.

Two days earlier, a security researcher's bait servers (honeypots, set up to watch attackers at work) caught it happening. They ran PHP 8.4.26, one release behind the fix. Attackers from two internet addresses got a command line on all three of them, 35 times in total.

The attack fires while PHP is still starting to handle a request, before any website code runs. So it doesn't matter whether the site on top is WordPress, Drupal or something hand-built.

One honest caveat. The bait servers were set up to be easy targets, in the configuration PHP itself rates riskiest. That tells us nothing about how often the attack works on real servers. It does tell us people are running it for real.

Who needs to act

Anyone whose website runs on PHP: WordPress, WooCommerce, Joomla, Drupal, Magento or a custom PHP site. If PHP on your server hasn't been updated, someone with no login can take over the server behind your site.

Updating WordPress and your plugins won't fix this. The fix is a PHP update on the server, and on most hosting only your host can do that.

What to do today

Get your PHP version confirmed in writing. The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12 (or anything later). On an older number, get your host to confirm the PHP2Shell fixes are applied. The copy-and-paste email in my first post does the job.
On PHP 8.1 or older? CISA now says organisations that can't update, or are still on 8.1 or earlier, should take their PHP systems offline until they're patched or upgraded. Some hosts and Linux vendors have their own fixes for older versions, so ask yours straight away.
If your host can't update today, ask them to apply PHP's temporary settings and put a web application firewall in front of the site. CISA says a firewall may give some protection in the meantime. Neither makes a site safe on its own.
Ask whether the server has been checked for anything an attacker left behind. Updating stops new attacks. It doesn't remove anything already planted. The NCSC says that if a system wasn't patched straight away, it should be checked for backdoors.

Signs someone may have got in

What you might notice: admin accounts you don't recognise, pages or files you didn't add, visitors being redirected to other sites, or the site suddenly throwing errors or going down.

What your host or developer should look for is in the notes below.

For developers

KEV: both CVEs added on 26/10/2026 (catalogue version 2026.10.26), with a 29/10/2026 due date for US federal agencies. CISA revised its alert the same day.
What the confirmed attacks looked like (honeypots, 24/10/2026, PHP 8.4.26 on single-worker Apache mod_php, 128 MiB memory_limit, plain HTTP): a four-stage multipart chain. Memory pressure, then memory disclosure through an oversized PHPSESSID cookie (about 800 KiB), more memory pressure, then an execution request built from the leaked addresses. The traffic closely matches the public proof of concept.
Signals worth searching your logs for:
- multipart POSTs to / or /index.php with no User-Agent and hundreds of parts, often chunked
- PHP memory-limit errors reported in Unknown on line 0, which means request start-up, before your code runs
- responses setting a very large PHPSESSID cookie
- Apache or PHP-FPM workers starting /bin/sh, curl or wget, and workers dying with segfaults
Detection: CISA published a Sigma rule for PHP2Shell on 23/10 in its cisagov/SIGMA_Rules repository.
Fixed: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (21/10/2026). Make sure every worker has restarted on the new build. Linux distributions had the patches in advance, so check your vendor's packages too.
Windows: on 26/10 PHP issued rebuilt Windows packages (8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1) with Brotli 1.2.1, fixing CVE-2026-111497, an out-of-bounds write reachable through cURL when automatic response decompression is turned on. Same PHP source, so this only matters on Windows.
Temporary settings if you can't update yet (php.net, 21/10): session.upload_progress.enabled=0 in php.ini, the FPM pool or server config (not ini_set() or .user.ini), then restart every worker. On 8.5, also fatal_error_backtraces=0. Then memory_limit=-1, locked so applications can't change it back (php_admin_value, for example), and a low post_max_size: PHP suggests 8M for sites without uploads and 32M with them. PHP is clear these reduce exposure but don't make an installation safe.
CVE-2026-115560 (still unpatched): a third, related flaw, covered by PHP's informational advisory of 23/10. An app is only exposed if its config sets the session serialiser to php_binary or php_serialize and its code flips it back to php with ini_set() before calling session_start(), while session upload progress is still enabled. PHP calls that combination unlikely and is fixing it in its next regular release, with the full advisory then. Until that release, the workaround is the same session.upload_progress.enabled=0.
8.1 and older: no releases from the PHP project, but its security team published minimal source backports for 7.4, 8.0 and 8.1 for anyone building from source.

Want me to check yours?

If you're not sure which PHP version your site runs, or whether it's been patched, send me your web address and I'll tell you in plain words where you stand.