PHP2Shell: Patch the Critical PHP RCE Today (2026)

PHP2Shell is the name researchers have given to two critical vulnerabilities in PHP — CVE-2026-109618 and CVE-2026-109619 — both rated 9.2 on the CVSS v4.0 scale by the PHP security team. PHP ships an out-of-band security release fixing them today, Wednesday 21 October 2026, at 14:00 UTC (3:00 p.m. WAT). If your WordPress site runs on PHP — and every WordPress site does — this one is yours to act on.

This article was written at around 10:30 a.m. WAT, before the patches drop. It covers what is confirmed, what is still rumour, and exactly what to do on your WordPress site today — before and after 14:00 UTC.

Table of Contents

What PHP2Shell is (the confirmed facts)

PHP itself announced the release on Tuesday evening. Here is what the PHP security team has actually confirmed:

Two vulnerabilities, both rated CVSS v4.0 9.2. PHP’s own notice names neither the flaws nor their CVE identifiers — the CVE numbers and the “PHP2Shell” name come from leaked reporting, not from PHP.
The fix lands Wednesday 21 October 2026 at 14:00 UTC — though PHP says it may release earlier “should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.”
They are real. Security firm watchTowr confirmed both flaws are genuine and reproduced one in its lab — while refusing to share technical details until the patches are out.
No in-the-wild exploitation has been observed — watchTowr and Huntress both say they have not seen either flaw exploited yet, and neither CVE is in the CISA known-exploited catalog as of this morning.
Only supported PHP branches get official fixes — PHP 8.2 through 8.5. If your server runs PHP 8.1 or older, there is no official patch coming for it.
Fixed version numbers are published with the release. Nobody outside the PHP security team knows them yet.

How we got here: the leak timeline

On 20 October, a post on Hacker News claimed two PHP remote-code-execution flaws, rated CVSS 10.0 and affecting every PHP version from PHP 5 onward, would be disclosed on Thursday 22 October. The poster’s own admission: they had “no evidence beyond ‘source: trust me, bro’.”

Then watchTowr posted on X that the leaked information was real, that the two flaws were under embargo, and that everyone had been supposed to wait until Thursday. That evening, at 19:33 UTC, PHP published its own notice — and moved the release forward to Wednesday 14:00 UTC, a full day earlier than the leaked date.

Since then: CERT-EU has publicly named the two CVE identifiers, Australia’s ACSC issued a critical alert, some hosting providers started pre-emptively hardening servers, and a screenshot of an alleged exploit tool called “PHP2Shell” (credited to Calif.IO) has been circulating. Sansec, the firm tracking the story, expects “mass attacks to start within 15 minutes of the release.”

What is confirmed vs what is still rumour

Because this story broke through a leak, you need to keep two piles in your head. Acting on the wrong pile wastes your day.

Confirmed (by PHP, watchTowr, Huntress, or multiple outlets):

Two critical flaws, CVSS v4.0 9.2 each, per the PHP security team.
Release at 14:00 UTC today, 21 October 2026, possibly earlier.
Both flaws are real; watchTowr reproduced one in a lab.
No observed in-the-wild exploitation as of this morning.
Only PHP 8.2–8.5 receive official fixes.

Leak-only (reported by one or two sources, not confirmed by PHP):

The CVSS 10.0 figure — that’s the leak’s number; PHP’s official rating is 9.2.
The “all PHP versions from PHP 5 onward” scope — watchTowr’s own FAQ says this “has not been confirmed by an official vendor advisory.”
The use-after-free root cause — suggested by a single report.
The multipart-upload attack path — unofficial reconstructions only.
The PHP2Shell exploit tool screenshot — leaked and unattributed by PHP; treat it as unverified.

If a source states any leak-only item as settled fact, read the rest of that source sceptically. This post will stick to the confirmed pile wherever the distinction matters.

Why this is a WordPress problem

WordPress is PHP. Every page, every admin screen, every WooCommerce checkout on your site is executed by the PHP interpreter on your server. A remote-code-execution flaw in PHP sits underneath your theme, your plugins, and WordPress core itself.

That means the thing you must not do is the instinctive thing: updating WordPress core, plugins, or themes will not patch a vulnerability in PHP itself. Your site can be fully updated — WordPress 7.x, every plugin current — and still be exposed, because the flaw is in the runtime that runs all of it. The fix happens at the server level: your PHP version has to change.

Step 1: Check your PHP version right now

Before 14:00 UTC, find out exactly what you’re running. Any of these works:

In wp-admin: go to Tools → Site Health → Info tab → Server. The “PHP version” line tells you the truth.
With WP-CLI: run wp --info on the server and read the “PHP version” line.
On a VPS: run php -v.
On cPanel shared hosting: open MultiPHP Manager — it lists the PHP version per domain.

Write the number down. Then ask one question: is it 8.2 or newer? If it says 8.1, 8.0, 7.4, or anything older, you are on a branch that gets no official fix — read the EOL section below, because your day looks different.

Step 2: Know who updates your PHP

PHP2Shell is fixed at the infrastructure level — you cannot fix it from inside your WordPress code. Who applies the fix depends on your hosting:

Shared hosting / managed WordPress: your host does it. Sansec’s advice is direct: “Ask your hosting provider today to stand by and apply the PHP update as soon as it is released.” Open a ticket or chat now — before 14:00 UTC — and ask two questions: (1) will you apply the PHP security release today, and (2) what PHP version am I on? If your panel has a PHP version selector, check it again after the release drops; hosts roll the new builds out at different speeds.
VPS / dedicated server: it’s you. Be ready to update the moment the release lands — check php.net or your package manager for the new patch versions this afternoon. On Ubuntu with the standard packages, that’s sudo apt update && sudo apt upgrade and a restart of PHP-FPM (sudo systemctl restart php8.2-fpm — match your version). If you use the Ondřej Surý PPA, the new builds usually land within hours of the upstream release.

The update you want today is a patch release inside your current branch (for example, 8.2.x to the new 8.2.x) — not a branch jump from 8.1 to 8.3. Patch releases are drop-in by design; branch jumps are where the surprises live, and patch day is not the day for surprises.

Step 3: The EOL problem — PHP 8.1 and older

If Step 1 showed PHP 8.1 or older, the official release will not include a fix for your branch. Your options, in order of preference:

Ask your host to move you to PHP 8.2+ today. For most WordPress sites this is a panel setting (cPanel MultiPHP Manager, Plesk, or your host’s dashboard) and a few minutes of testing. WordPress itself has long recommended modern PHP, and the 8.1→8.2 jump is one of the gentler ones.
If you can’t move today, ask your host whether they backport security fixes to EOL PHP builds. Some managed hosts do; most shared hosts don’t. Get the answer in writing.
Do not assume a plugin or WAF “covers” this. A web application firewall can block known exploit patterns, but it cannot fix the interpreter. Treat mitigations as buying hours, not as a fix.

On a VPS, the move is sudo apt install php8.3-fpm (or your branch of choice), pointing your web server at the new socket, testing, then removing the old branch. Keep the old version installed until the new one is proven — you want a rollback path on a day like today.

Step 4: When 14:00 UTC hits — the update order

Once the release is out and your host or packages have the new builds:

Update PHP to the newly released patch version in your branch.
Restart PHP-FPM (and your web server if you’re unsure — a full restart is cheap insurance).
Verify with php -v or Site Health that the new version is actually serving requests.
Smoke-test the site: front page, wp-admin login, and one form submission (contact form or checkout). A patch release should change nothing visible; if something breaks, you want to know in the first five minutes, not from a customer.
Take a backup before you start if you don’t have a fresh one — today of all days.

If you can’t patch today: reducing exposure

Be honest with yourself about what these buy you — hours, not safety:

session.upload_progress.enabled: some hosts are pre-emptively disabling PHP’s session upload-progress feature. The PHP manual itself advises turning it off if you don’t use upload progress bars — but no source confirms this stops PHP2Shell. If you don’t use it, disabling it is harmless hygiene; don’t treat it as a fix.
Firewall rules: if your host or WAF publishes PHP2Shell rules after the technical details land, enable them. They help against mass scanning, not targeted exploitation.
Least privilege: the PHP process should already run as a limited user with no shell access. If your host runs PHP as root or a shared user — a separate problem worth raising today.
Backups: confirm you have a restorable backup from before today. If the 15-minute warning proves right, clean backups are your fastest recovery.

After the patch: the 15-minute warning

Sansec expects mass attacks to begin within 15 minutes of the release. That pattern — vulnerability disclosed at patch time, exploit tooling already circulating, botnets scanning within minutes — is exactly what happened with previous PHP-adjacent mass-exploitation events. Practical steps for the rest of today:

Watch your access logs for unusual POST bursts, especially to upload endpoints, in the hours after 14:00 UTC.
Check for new admin users, unknown files, and modified core files this evening — the same post-compromise checks you’d run for any suspected breach.
Follow watchTowr and Huntress — both held technical details back until patch time and are the most likely sources of detection guidance and indicators of compromise once the embargo lifts.

The one-paragraph version

PHP ships an emergency security release today at 14:00 UTC for two critical flaws (CVE-2026-109618, CVE-2026-109619, CVSS 9.2 each), collectively called PHP2Shell. Updating WordPress won’t fix it — your PHP version has to change. Check your PHP version now (Site Health → Info → Server), ask your host to stand by if you’re on shared hosting, and apply the patch release in your branch this afternoon. If you’re on PHP 8.1 or older, there is no official fix — move to 8.2+ today.

PHP2Shell: What the Critical PHP RCE Means for Your WordPress Site (Act Today, Oct 21)