Critical PHP2Shell: two unauthenticated RCE flaws in PHP itself. Fixes shipped on 21 Oct 2026. Check if you are affected →
← All news

Trail of Bits Says Its PHP2Shell Exploit Is Now "Production-Grade", Reaching Root on Stock mod_php and PHP-FPM

Trail of Bits CEO Dan Guido says the firm's private PHP2Shell exploit works against stock production PHP settings with ASLR on, under Apache mod_php and nginx PHP-FPM. Public exploits remain unreliable, but unpatched servers should be treated as exploitable.

Security firm Trail of Bits says its private exploit for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is now "production-grade". The claim undercuts an argument many administrators have leaned on since the October 21 patches: that real-world servers with default hardening are hard to exploit.

What Trail of Bits is claiming

According to a running tracker maintained by Mallory, Trail of Bits CEO Dan Guido said on October 24 (UTC) that the exploit works with:

  • a stock php.ini-production configuration and display_errors=off
  • a normal memory limit, multiple workers, and ASLR enabled, under load
  • both x86-64 and ARM64 targets
  • both Apache with mod_php and nginx with PHP-FPM
  • applications including MediaWiki, WordPress, phpBB and Laravel

Guido said the chain ends in root. Two days earlier, on October 22, he had reported getting a shell on an unmodified MediaWiki install. Trail of Bits has not published the exploit.

It's not the only private exploit

VulnCheck says it had a weaponized exploit for CVE-2026-109618 by October 22. It chains a separate memory leak into code execution with ASLR on and display_errors=off. As of October 23 it supported PHP 8.4.10 through 8.4.26 and 8.5.10 through 8.5.11 under mod_php on AMD64 and ARM64, including default WordPress Docker installs. VulnCheck shares it only with customers.

Why public exploits look weaker than they are

SANS ISC says no reliable exploit is publicly available. Many public proofs of concept assume an 8 MB memory limit when real servers typically use 128 MB, rely on reading memory addresses from the target, or only work with ASLR switched off. Sansec has also said publicly available exploits fail against default PHP settings.

That is true of the public code. The private Trail of Bits and VulnCheck results show reliable exploitation is achievable by capable attackers, and TechCrunch reports that Palo Alto Networks and Trail of Bits now point to confirmed compromises with post-exploitation activity.

What to do

  • Patch now: upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's or host's backported package.
  • Don't rely on hardening as a substitute: display_errors=off, ASLR and a sensible memory_limit are good practice, but they are not a defence against these private exploits.
  • Also disable session upload progress: PHP's separate CVE-2026-115560 is not fixed in those releases, so keep session.upload_progress.enabled=0 until the next regular release.
  • Hunt for compromise: Amazon has said defenders should look for exploitation as early as October 17.

Running PHP 7.x, 8.0 or 8.1, or a framework version that blocks the upgrade? RescuePHP can help with backported security patches, compromise checks and a planned upgrade path for legacy PHP applications.