php2shell / anatomy ZERO-DAY · AWARENESS

CVE-2026-109618CVE-2026-109619CVSS v4.0 9.2 · CRITICAL

One plain POST,
and PHP is theirs.

No upload form. No login. A single ordinary HTTP POST is reported to run code on nearly every server running PHP. That is php2shell. This page exists so you patch before it reaches you.

LineageHeartbleed 2014›Shellshock 2014›Log4Shell 2021›php2shell 2026

patch status · 2026-10-21 14:00 UTC releaselive

…

PHP ships an out-of-cycle security release at 14:00 UTC, 2026-10-21 for 8.2 / 8.3 / 8.4 / 8.5. Have your update staged now. The gap between patch and weaponisation is expected to be tiny.

9.2

CVSS v4.0

unauth

no login required (reported)

PHP 5.4+

claimed impact

~15 min

patch-diff to mass exploit

URGENT BROADCAST

Even the Prime Minister told you to patch tonight.

Sanae Takaichi

@takaichi_sanae

View on X

An urgent request for tonight.

PHP’s security team has issued an advisory about two critical vulnerabilities in PHP, which is used by a great many websites.

Please check whether your public sites use PHP, and prepare to apply the fix released tonight at 23:00 JST as quickly as possible.

If applying it promptly is difficult, temporarily taking the site offline is one effective way to reduce risk.

Our national cyber office is posting related information on its X account too, so please refer to that as well.

When the head of government announces your maintenance window, “I’ll get to it after lunch” stops being a plan. 23:00 JST = 14:00 UTC, the same clock ticking at the top of this page. That night, “emergency maintenance” out-trended the pop charts.

Plate 01Why it's different

“We’re not affected” doesn’t hold here.

An ordinary web shell is the story of one vulnerable app getting one file dropped in it. php2shell is different. The flaw is reported to live in PHP itself, with no special feature and no risky setting required. If your site runs PHP, you’re in scope.

01 · core flaw

Not a plugin. PHP itself.

It isn’t a bug in some WordPress plugin or one framework. It’s reported in the PHP interpreter, so it doesn’t care what your site is built with.

02 · default on

No special setup needed

The suspected code path, session.upload_progress, has been on by default since PHP 5.4. Nobody has to misconfigure anything for it to apply.

03 · unauthenticated

No login, no upload field

Even a site with no upload feature can be reached by a POST to any PHP endpoint. “We blocked uploads” does not save you.

04 · whole ecosystem

Shown across major CMS and frameworks

Leaked footage reportedly showed it working on WordPress, Drupal, Joomla, Magento, Laravel, Symfony, MediaWiki, phpBB and WHMCS.

Plate 02How it works

In plain terms. No recipe.

You don’t need exploit details to grasp why this is bad. Here is the shape of it, at a level that informs defenders without handing anyone a weapon.

Mechanism below is high-level and based on leaked info / researcher analysis. PHP has not published root-cause details (as of 2026-10-21). No reproduction steps are shown here.

Reached through

PHP’s upload-progress handling

PHP has a built-in feature that reports how far an upload has got. The flaw is reported to sit in that code path, and it’s active by default, so ordinary requests can reach it.

The bug class

A memory-safety flaw (use-after-free)

Internal bookkeeping is reported to reuse a piece of memory after it was already released. That “use-after-free” is the classic kind of bug that can be steered into running attacker code.

The payoff

Code execution as the web user

The end result is remote code execution: commands run as the PHP / web-server process. From there: read secrets and DB credentials, pivot inward, drop a persistent shell.

Plate 03Attack sequence

What an intrusion actually looks like.

From the attacker’s side, it’s a routine. Watch the stages they walk through, and what you lose at each one. This is the consequence, not a how-to.

Attacker

Edge / WAF

Your PHP server

Database

Internal network

01 / 06threat0

Recon

You’re found by a scanner, not a person

Attackers mass-scan the internet for servers in the vulnerable PHP range. Nobody singled you out; your address simply matched.

what you loseTargeted automatically, at internet scale.

Break in

One ordinary request, no alarm

A single normal-looking POST reaches the core flaw. No login, no upload form, and little that reads as “an attack” in your app logs.

what you loseCode now runs on your box as the web user.

Grip

Your server starts taking their commands

With code execution, the machine answers to them. They read your application source, its configuration and its environment.

what you loseSource, config and secrets exposed.

Loot

Secrets walk out the door

Database credentials, API keys, session secrets and customer records are collected and quietly sent out.

what you loseData breach. Credentials stolen.

Pivot

The blast spreads inward

Stolen credentials and internal reach let them move to the database, internal services and neighbouring hosts, their traffic dressed as normal web requests.

what you loseThe breach spreads past the web server.

Persist

They stay, even after you patch

A hidden backdoor is left behind, and ransomware may be staged. Closing the hole does not evict someone already inside.

what you loseLingering access, ransom, downtime.

Plate 04Exposure check

Are you exposed?

Pick your situation. This is a quick orientation, not a scan. When in doubt, assume exposed and patch.

Your PHP branch

WAF / Cloudflare filtering multipart POST?

Plate 05The race

Leaked early. Patched late. Exploited fast.

What makes php2shell frightening isn’t only the bug. It’s the timeline. Details got out before the fix, turning disclosure into a sprint.

2026-10-20~2 days early

Details leak

Information leaked ahead of coordinated disclosure. PHP issues an advance notice; CERT-EU publishes Security Advisory 2026-018.

2026-10-2114:00 UTC

Out-of-cycle security release

PHP ships fixes for 8.2, 8.3, 8.4 and 8.5. End-of-life branches get nothing.

2026-10-21+~15 min

Weaponisation window

Sansec expects mass exploitation within minutes: comparing the patched code with the old reveals exactly where the bug was.

2026-10-22original date

Planned disclosure

The coordinated disclosure date the leak jumped ahead of. Early exploitation attempts were already reported (e.g. by Cloudflare) before this.

Plate 06Blast radius

Who gets a patch, and who doesn’t.

Fixes land only for currently-supported branches. If you’re on anything older, there is no fix, only an upgrade.

PHP branchPatch 2026-10-21Action

8.5PatchedUpdate to the latest 8.5 release

8.4PatchedUpdate to the latest 8.4 release

8.3PatchedUpdate to the latest 8.3 release

8.2PatchedUpdate to the latest 8.2 release

8.1No fix (EOL)Upgrade to 8.2+ immediately

8.0 / 7.x / 5.xNo fix (EOL)Upgrade to a supported branch

Reportedly demonstrated against, among others:

WordPressDrupalJoomlaMagentoLaravelSymfonyMediaWikiphpBBWHMCS

Plate 07Defense

Patch, filter, upgrade. In that order.

Perfect detection is hard; removing the precondition is stronger. The priority is simple: get onto a patched version. Everything else buys time until you do.

✕ Myth

“Disable system() or use a WAF and you’re fine.” Not here. This is a memory-safety bug in PHP’s core, so disable_functions is irrelevant, and CSP is for client-side (XSS), not a server-side core RCE. A WAF filter helps for hours; the patch is the fix.

Primary

Patch to a fixed release

Update to the 2026-10-21 release for your branch (8.2 / 8.3 / 8.4 / 8.5), then confirm with php -v. This is the only real cure.

Filter multipart POST at the edge

Until patched, block or heavily restrict multipart/form-data POSTs at a WAF / Cloudflare. Emergency rules exist as a stopgap, not a replacement for patching.

Disable upload-progress tracking

If you can’t patch instantly, set session.upload_progress.enabled=0 in php.ini, a targeted mitigation if the reported root cause holds. Re-test your apps.

Upgrade anything end-of-life

8.1, 8.0, 7.x and 5.x receive no fix. If you’re on them, an upgrade is the mitigation; there is no patch to wait for.

Watch for post-exploitation

Alert on the web process spawning a shell, unfamiliar child processes, or new files in web dirs. Right after the patch is public is when scanning spikes.

Verify, don’t assume

Confirm the running PHP version on every host: containers, legacy VMs, that one forgotten box. Fleets fail where a single unpatched server hides.