PHP2Shell: what's confirmed, what isn't, and what to do now

On October 20, word leaked that two remote code execution bugs in PHP itself were about to be disclosed. Within hours the PHP security team confirmed it with an advance notice: two critical vulnerabilities, fixed releases on October 21 at 14:00 UTC.

They're tracked as CVE-2026-109618 and CVE-2026-109619. Researchers are calling them PHP2Shell. That name isn't PHP's. It reportedly comes from an exploit tool in one of the leaked screenshots.

Bugs

2

Both in the PHP runtime

Severity

9.2

CVSS v4.0, both

Fix ships

14:00

UTC, October 21

Fixed branches

8.2–8.5

8.1 and older: none

We're writing this two hours before the release, and most of what's out there is guesswork. We've kept what's confirmed apart from what isn't. When PHP publishes its advisory, we'll update this post.

How it unfolded

1. Oct 20 · 15:20 UTC

   A Hacker News post says two PHP RCE bugs are about to be disclosed. It's taken down, but screenshots have already spread.

2. Oct 20

   PHP publishes an advance notice: two critical bugs, both CVSS v4.0 9.2, with fixes on October 21.

3. Oct 20

   CERT-EU publishes advisory 2026-018, naming both CVEs.

4. Oct 21 · overnight

   Repositories claiming working proofs of concept appear on GitHub.

5. Oct 21 · morning

   GMO Flatt Security suggests disabling session upload progress, then says it isn't a complete fix. Cloudflare ships emergency WAF rules and calls them a stopgap.

6. Oct 21 · 14:00 UTC

   PHP's scheduled security release.

What's confirmed

• Confirmed:

  Two critical bugs in PHP itself

  Both are in the PHP runtime, not in a framework or plugin. The PHP security team rates both at CVSS v4.0 9.2.

• Confirmed:

  Fixes on October 21, 14:00 UTC

  PHP says it may release earlier if details go public or exploitation shows up.

• Confirmed:

  Independently reproduced

  watchTowr has reproduced CVE-2026-109618.

• Confirmed:

  Isolate if you can't patch

  CERT-EU advisory 2026-018 says to isolate internet-facing PHP applications if you can't patch right away.

• Confirmed:

  Only supported branches get fixed

  PHP fixes 8.2 through 8.5. Anything older is end-of-life upstream.

What isn't confirmed

PHP hasn't said which versions are affected or which component the bugs are in. It also hasn't said whether any configuration changes the risk. Everything below comes from third parties.

• ?Unconfirmed:

  Affected versions

  CERT-EU says the bugs "could affect all PHP versions from PHP 5 onwards." Sansec puts it at PHP 5.4 and later. Until PHP says otherwise, assume every version you run is affected.

• ?Unconfirmed:

  Root cause

  Most researchers point at session upload progress, which handles uploads before your application code runs. One claim puts the second bug in multipart form handling more generally. An anonymous code audit argues the bug being described doesn't exist in released PHP.

• ?Unconfirmed:

  Exploitation in the wild

  Cloudflare's CTO says the company is seeing early attacks, and Patchstack has reported activity at hosting partners. Huntress and watchTowr hadn't seen any, and neither CVE is in CISA's KEV catalog. Plan as though attacks have started.

• ?Unconfirmed:

  Fixed version numbers

  A list naming 8.5.12, 8.4.27, 8.3.36 and 8.2.35 is going around. Those are the plausible next patch releases, but nobody outside PHP has confirmed them.

About the public PoCs

A demonstration video went up and came down on October 20. By the next morning, at least two GitHub repositories claimed working proofs of concept against session upload progress. We ran them in our lab after reading the code. Don't run them anywhere except a lab you own.

The more detailed one describes three exploit chains, and each needs something extra from the application:

• A local file inclusion bug in the app.
• unserialize() called on attacker-controlled data.
• Mismatched session handlers, plus a usable gadget chain.

That's useful, but don't plan around it yet. Nobody has confirmed these are the bugs PHP is fixing. The anonymous audit says the circulating code doesn't work, and GMO Flatt expects attacks that get past the obvious workaround. Treat the PoCs as clues, not a list of conditions you can check off.

The config workaround isn't a fix

Early on October 21, GMO Flatt Security suggested setting session.upload_progress.enabled=0, and hosts rolled it out across their fleets within hours. GMO Flatt later said it isn't a complete fix and that attackers are expected to get around it. Gina Peter Banyard, a PHP core developer, put it plainly: "the only mitigation is patching/upgrading PHP." Aikido reports that the PHP team has confirmed the bugs can't be mitigated through configuration.

Turning upload progress off is still sensible if you don't use it. The PHP manual has recommended that for years. If you do, check the value on the process that actually serves web traffic (PHP-FPM or mod_php), not php -i at a shell. Under CGI/FastCGI, a .user.ini file in a web directory can switch it back on. Whatever you do, don't close the ticket because of this setting.

WAF rules aren't a fix either. Cloudflare calls its emergency rules a stopgap. No vendor has a complete signature yet, because nobody outside PHP and the original researchers knows exactly what the attack looks like.

What to do in the next few hours

1. 01

   Inventory every PHP runtime

   Not just your web apps. Include vendor appliances, control panels like cPanel and Plesk, Windows software that ships php.exe or php-cgi.exe, and container base images. Note the version and whether it's reachable from the internet.

2. 02

   Rank by reachability

   An internet-facing PHP-FPM pool on 8.1 is your first problem. An internal tool on 8.4 behind a VPN can wait an hour.

3. 03

   Cut exposure before 14:00 UTC

   Put admin panels and internal apps behind a VPN, an allowlist, or authenticated edge access. Check the origin can't be reached directly, around your CDN.

4. 04

   Stage the update

   Know which package or image you'll pull, who approves the deploy, and how you'll roll it out internet-facing first. If you depend on distro or hosting packages, find out when their backport lands. Most can't build until the upstream release is out.

5. 05

   Decide on end-of-life branches

   PHP 8.1, 7.x and 5.x get no upstream fix. Upgrade, isolate, take offline, or buy extended support. Pick one before the exploit details land.

6. 06

   Start watching now

   Record what your PHP workers normally spawn, so you can tell what's new later.

What exploitation will probably look like

Nobody has confirmed indicators of compromise yet. But code execution inside a PHP worker usually plays out the same way. Huntress has published behavior worth alerting on today, based partly on guidance from Florian Roth.

Also look for new PHP files in the web root or temp directories, new cron jobs, scheduled tasks or admin accounts, and unusual outbound connections.

Once you've patched, look back as well as forward. Aikido recommends reviewing systems back to at least June 2026. Patching stops new attacks. It won't tell you whether someone got in first.

Why reachability matters this week

Every PHP install you have is about to carry a 9.2, and the score won't tell you where to start. Ask the question you'd ask of any finding: can an attacker reach this from somewhere they could realistically be, and what's on the other side?

After the release, the question changes to whether the fix actually took. The package may be upgraded while the FPM pool was never restarted. The image may be rebuilt but never redeployed. Either way, the old code is still serving traffic. Re-test after you patch. A merged PR doesn't mean the bug is fixed, and an installed package doesn't mean the server is patched.

When PHP's advisory is out, we'll update this post with affected versions, fixed releases, and technical details.