Events Secure.com at Black Hat USA 2026
Published: October 27, 2026 3 min read

Five Days After the Patch, PHP2Shell Lands on CISA’s Must-Fix List

CISA added the PHP2Shell flaws to its KEV catalog on 26 Oct after honeypot evidence showed working shells. Federal patch date is 29 Oct.

By Secure.com
Summary

PHP2Shell Is Now Proven, Not Just Critical: What CISA’s KEV Listing Changes

The two PHP flaws called PHP2Shell were rated critical on day one. Nobody could prove they worked. By Saturday, someone could. By Monday, they were on the US government’s must-fix list.

What Happened?

PHP shipped emergency fixes on Wednesday, 21 October, for two bugs that let an attacker run commands on a server without logging in. Versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 carry the fix. Both score 9.2 out of 10.

For three days, security firms reported scanning, probing and failed attempts. The firms later walked back several early claims of a real break-in.

Then on Saturday 24 October, a researcher’s decoy servers logged 35 shells started by Apache workers running an unpatched PHP 8.4.26. On Monday 26 October, CISA added both bugs to its Known Exploited Vulnerabilities catalog, with a federal deadline of Thursday 29 October.

What’s the Impact?

KEV listing is the line between a scary score and a proven attack. Federal agencies now have a hard date. Everyone else inherits the same math. Working exploit code is public, attempts run into the millions, and patching does not remove a shell that already landed.

How to Avoid This

  • Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 today
  • Hunt for PHP workers starting shells after you patch
  • Find bundled PHP in appliances and control panels, then upgrade the product
  • Retire PHP 8.1 and older, or take it off the internet
  • Set session.upload_progress.enabled=0 for the separate third flaw

Indicators of compromise

PHP2Shell · Indicators of compromise

No IP list to block. Hunt the behavior instead.

Read this first. There is no published set of attacker IP addresses or file hashes that is useful for blocking. The addresses that appear in public honeypot research belong to one researcher’s sensors, so blocking them protects nobody. What follows is behavioral detection drawn from confirmed execution evidence and government patching guidance. Patching does not remove a shell that already landed, so run these hunts after you patch.
Process behavior (strongest signal)
  • A shell such as /bin/sh or /bin/bash whose direct parent is an Apache worker, php-fpm, php-cgi or httpd
  • On Windows, cmd.exe or powershell.exe spawned by a PHP or IIS worker process
  • The child process runs as the web server account, such as uid 33 or www-data
  • Any outbound network connection opened by a process whose parent is a PHP worker
Log signals
  • PHP fatal errors recorded at request startup as Unknown on line 0, before any application code runs
  • Memory exhaustion errors clustered on internet facing hosts
  • Apache or PHP workers crashing with SIGSEGV right after a request
  • Requests with no normal completion entry in the access log
Request shape
  • Large multipart/form-data POST bodies, in the range of several hundred kilobytes
  • An unusually high number of parts in a single upload, in the hundreds rather than a handful
  • POST requests to / or other paths that take no file upload
  • An unusually large response body returned just before a crash or a shell start
Hunt window and scope
  • Search from mid October through the moment each host was patched. Attempts were recorded before the fix shipped
  • Every web facing setup is in scope, including mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed
  • Risk is rated highest for Apache mod_php, where the request lands before application code
  • Check hosts you did not patch yourself, such as appliances and control panels that bundle their own PHP
Scope caveat Confirmed execution evidence comes from research decoys built to favor the attacker, not from a named victim. Treat it as proof the exploit works, not as a measure of how reliably it works on your estate.

There is no useful list of attacker addresses or file hashes to block. The addresses in public honeypot research belong to one researcher’s sensors, so blocking them protects nobody. The real indicators are behavioral, and they sit in the IOC embed: a shell whose direct parent is a PHP or Apache worker, PHP fatal errors logged at request startup before application code runs, workers crashing right after a request, and oversized multipart uploads with hundreds of parts.

Your scanner flagged it Wednesday. Why did it only matter on Monday?

A severity score tells you something is bad. It does not tell you what to fix first. Exploit evidence does, and it changes daily.

  • Both CVEs show up in Secure.com with their KEV status, EPSS score, and exploit evidence once a connected scanner reports them
  • It runs above the stack you already own, so your scanner stays where it is
  • Offense evidence sets the order, so the fix list follows what is provably exploitable
  • Consequential actions wait for your approval, and every step is logged
  • Start with one teammate on the function creating the most grunt work

Other News