PHP Emergency Patch for CVE-2026-109618 and CVE-2026-109619: What We Know — and What to Make of the "PHP2Shell" Rumor

Today’s release, in one paragraph

Today’s PHP emergency patch — an emergency security release the PHP security team has scheduled for Wednesday, 21 October 2026, at 14:00 UTC — will fix two vulnerabilities that the team itself rates as Critical, each carrying a CVSS v4.0 score of 9.2. The notice names no CVE identifiers — the only thing PHP makes official at that stage is the CVSS v4.0 9.2 scoring pair. The identifiers under which the flaws are being tracked — CVE-2026-109618 and CVE-2026-109619 — come from watchTowr’s disclosure chain, not from php.net: security researchers at watchTowr relayed them to BleepingComputer in reporting on the leak, and corroborating coverage (SecurityWeek, phoenix.security) uses the same IDs. It is those researchers who identified both flaws as remote code execution (RCE) bugs, which is what transformed a routine patch day into an across-the-industry scramble. The advisory states only that full technical details, the affected version ranges, and the fixed releases will all be published together with the patch. As we sit down to write this — the morning of October 21 UTC, roughly six and a half hours before the scheduled drop (last check: ~07:30 UTC) — the PHP.net news archive still shows only the advance notice: no new versions, no changelogs, no technical write-up. So this post is part status report, part rumor-triage, and part prep checklist for the PHP emergency patch.

One logistical note that tells you how seriously the infrastructure world is taking this: when we attempted to load PHP.net’s downloads page while researching this post, the origin server timed out. That may mean nothing — large sites buckle under ordinary load all the time — but it is also exactly what you’d expect when every sysadmin on the planet starts refreshing the downloads page, so have a mirror or a signed checksum plan ready before the PHP emergency patch goes live.

Confirmed vs. rumor: the scoreboard before the whistle

Release-day stories get polluted fast. Rumor hardens into “fact” between the time a screenshot lands on social media and the time your non-technical boss emails you about it. So let’s be blunt about which pieces of this story rest on which kind of evidence.

What PHP has officially confirmed about the emergency patch

The advance notice was posted to the php.announce mailing list by Jakub Zelenka on October 20 and mirrored on PHP.net’s news archive. Taking it literally, here is everything the project has committed to:

• Two vulnerabilities, both rated CVSS v4.0 9.2 (Critical).
• Release scheduled for 21 October 2026, 14:00 UTC.
• The team “reserves the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.”
• Full details, affected versions, and fixed versions ship with the release — not before.

Read that list again and notice what’s missing: no affected-version range, no attack vector, no component name, no fixed-version numbers, no workaround. As of the time of writing, nothing here is vendor-confirmed. No vendor advisory has confirmed scope, technical cause, or a fix version — watchTowr’s own FAQ tracking these CVEs says exactly that, listing the fixed version as “to be confirmed” and the CVE entries as not yet scored in the major databases. There are public hints at a technical cause — SecurityWeek relays that one report suggests CVE-2026-109618 is a use-after-free bug, and a circulating community write-up makes its own root-cause claim (more on that below) — but none of it comes from PHP itself.

The “PHP2Shell” leak — real vulnerabilities, unconfirmed details

Here’s where the story gets messier, and more interesting.

The advance notice exists because details leaked. On October 20, information about the embargoed bugs surfaced online ahead of the original disclosure date, and shortly afterward, watchTowr’s CEO, Benjamin Harris, confirmed to BleepingComputer that the two vulnerabilities were real: “In the last hour, two remote code execution vulnerabilities in PHP have been leaked. These vulnerabilities were previously scheduled under embargo and due for release on Thursday at 11 am ET. While we are not able to share technical information at this point for obvious reasons, given the sensitivity, we can confirm that these vulnerabilities are indeed real.” watchTowr also stated that it believes it has successfully reproduced CVE-2026-109618, though it is withholding technical detail until patches are available — and that it has not observed exploitation in the wild.

Now the unconfirmed layer. An exploit tool calling itself “PHP2Shell” — credited in a leaked screenshot to a group or entity named Calif.IO — appears in a video purporting to show it executing code on servers running popular PHP applications, including WordPress, Drupal, Magento, Laravel, MediaWiki, phpBB, Joomla, and WHMCS. According to Ars Technica’s Dan Goodin, the report carrying that video was unconfirmed, and attempts to locate the original report were unsuccessful. watchTowr relayed that the report claimed the vulnerabilities affect “every PHP version from PHP 5 onward” — but the FAQ page is refreshingly explicit that this scope “has not been confirmed by an official vendor advisory.”

And the discrepancies are piling up in a way that should make you squint:

• Severity: PHP’s official notice says CVSS 9.2. watchTowr told BleepingComputer that both flaws are “CVSS10”, and a now-deleted Hacker News post saw by BleepingComputer — from a user named “petecooper” — also claimed CVSS 10.0. The official vendor score is the one that should anchor your risk decisions; the 10.0 figure comes from the leak chain.
• Version ceiling: watchTowr told BleepingComputer the bugs are understood to affect “PHP versions 5, 6, 7, and 8” — i.e., the leak chain’s claim has a ceiling at 8.x as well as a floor at PHP 5.
• Timing: PHP says the release is Wednesday (21 October, 14:00 UTC). The leak chain said the announcement was originally scheduled for Thursday, 11:00 a.m. ET — and watchTowr’s FAQ traces the leaked claim to an announcement slotted for 22 October at 18:00 CEST. The leak may be why everything moved up a day; that is consistent with PHP’s own stated reserve right, but the project hasn’t confirmed the cause.
• Update, ~07:40 UTC: the name is no longer unattached — SecurityWeek now links a report at 0x4148.com naming “PHP2Shell,” and our skepticism pillar accordingly downgrades from “a report nobody can locate” to “a report whose provenance is still unverified.” Treat the name as real but its provenance as unvalidated, not yet a taxonomy.

Two mood-of-the-moment details, downgraded from rumor since we started drafting. First, BleepingComputer’s own staff announcement confirms the site temporarily disabled forum posting over this story: a locked topic pinned by site founder Lawrence Abrams (t/819585, “Forum Posting Temporarily Disabled Due to PHP Security Concerns”) states the ability to create topics, reply, and perform other account functions was disabled “as a precautionary measure following reports of critical security vulnerabilities affecting PHP” — with the site adding there is no indication its forums were compromised. (The irony writes itself: BleepingComputer itself runs on PHP.) Second, the story’s reach on Hacker News is verifiable in real time via HN’s public API: as of October 21, roughly 07:30 UTC, the main thread stood at 516 points and the deleted petecooper thread at 196 points. Those figures are time-varying snapshots, not steady state — treat them accordingly.

How bad is 9.2, really?

Under CVSS v4.0, anything scoring 9.0 or above lands in the Critical band, so both of the flaws fixed by the PHP emergency patch sit comfortably inside it. But context matters more:

• CVSS is a vulnerability score, not an attack-landing-probability score. It rates severity assuming an attacker can reach the flaw. A 9.2 on an internet-facing PHP-FPM instance serving raw HTTP is a different species from a 9.2 reachable only via an authenticated admin API on a VLAN. PHP has not yet told us which of these worlds CVE-2026-109618 and CVE-2026-109619 inhabit — because they haven’t published technical details.
• Watchers lean toward pre-authentication exposure. CERT-EU’s read of the CVSS vector — relayed by SecurityWeek — is that, based on the 9.2 scores, both bugs could potentially be exploited without authentication. That is an assessment, not vendor confirmation, but it argues against the “only reachable via an authenticated admin API on a VLAN” reading of the severity. In terms of absolute exposure, coverage via Ars Technica cites one security researcher estimating roughly 1.3 million internet-connected hosts are likely affected.
• RCE on the interpreter means the blast radius is everything the interpreter can touch. If — if — these are truly RCE flaws in PHP core, the failure mode isn’t “your app has a bug”; it’s “the language runtime your entire fleet of apps shares has a bug” — the same shared-runtime failure mode that made this year’s Hugging Face Transformers config RCE so disruptive for ML pipelines. On a shared-hosting box, that means every site on every vhost sharing the same PHP processes. That’s why secondary coverage of this story is so spooked, and why Sansec recommends fixing at the infrastructure/rebuild-level rather than at the application level.
• Sansec, which has been writing about this pair since the leak, stated “We expect mass attacks to start within 15 minutes of the release.” That 15-minute figure is their opinion — a prediction, not evidence of attacks. watchTowr has stated it has not observed exploitation in the wild as of October 21. But the practical lesson holds regardless: assume the moment the PHP emergency patch goes public that attack code follows fast. If you’ve got a staging-to-production cycle measured in days, today is the day to compress it.

There’s a reason a “confirmed real, actively reproducible, RCE, in the world’s most-deployed web language, pre-patch” event gets treated this way even before the binaries drop. “Most-deployed” here is measurable rather than rhetorical: W3Techs’ survey for 21 October 2026 puts PHP at 69.3% of all websites whose server-side programming language is known — versus 8.1% for the runner-up, JavaScript.

Admin prep checklist before the PHP emergency patch drops (before 14:00 UTC)

You still have hours. Here’s how to spend them well.

Step 1: Inventory what you actually run

You can’t patch what you can’t find. On each host:

1
2
3
4
5
6
7
8
9
10
11

# What PHP is actually serving traffic?
php -v

# All PHP packages installed (Debian/Ubuntu)
dpkg -l | grep -i php

# All PHP packages installed (RHEL/Fedora/Rocky)
rpm -qa | grep -i php

# Which FPM pools are listening, and on what?
ss -tlnp | grep php-fpm

Two things to note down: the branch (8.2, 8.3, 8.4, 8.5, or older) and the binary doing the serving. Applications routinely run a different PHP version than the CLI php command points to — check the FPM pool configuration, not just the shell. This matters because, per PHP.net’s supported-versions page, the branches receiving official security fixes right now are 8.2 (security support ends 31 December 2026), 8.3 (ends 31 December 2027), 8.4 (ends 31 December 2028), and 8.5 (ends 31 December 2029). PHP 8.1 and earlier are past end-of-life.

Step 2: Pick your update path and rehearse it

Fixed version numbers aren’t public yet, so the smart move is to rehearse the update mechanism ahead of the PHP emergency patch release, not memorize a number.

1
2
3
4
5
6
7
8

# Debian/Ubuntu — update will arrive as a distro rebuild, typically within hours
sudo apt update && sudo apt install --only-upgrade 'php*'

# RHEL-family
sudo dnf update 'php*'

# Self-built PHP — expect a new tarball on php.net; keep your configure line handy
./configure <your-existing-options> && make && make install

If you’re on distro-managed PHP, expect the fix to reach you as a rebuilt package from your distro — Debian, Ubuntu, Red Hat, and friends generally turn around urgent PHP rebuilds within hours of upstream. Check your distro’s security-announce feed today, not just PHP.net. One caution as installs flow through package infrastructure: trust isn’t automatic — this year’s npm supply chain attack pushed malware from stolen maintainer accounts with valid certificates, so keep verifying what actually lands in your dependency tree.

Before the release: snapshot or backup, and identify one box you can test-patch first. Rollback for an interpreter upgrade is annoying (re-introducing the vulnerability) but possible — so know how you’d do it before you have to.

Step 3: If you can’t patch immediately

No official mitigation exists yet — an official advisory hasn’t shipped, so there’s nothing legitimate to anchor rules to. Treat any WAF rule or config tweak someone posts before the emergency patch lands as folkloric. And be careful how unverified guidance even reaches your consoles: the GhostApproval vulnerability showed how easily AI coding assistants can be steered into executing attacker-controlled instructions, and pasting folkloric rules straight into production configs has the same shape. What you can do as a precaution:

• Tighten egress from your PHP hosts (if an exploit executes code, it usually phones home first).
• Review firewall rules for PHP-FPM ports on hosts where traffic should only traverse the reverse proxy.
• Identify your crown-jewel PHP apps and consider more aggressive monitoring on them today.
• If you’re on managed hosting, ask your provider today to stand by for the update, and confirm they run PHP 8.2 or newer. If they’re on 8.1 or older, they have no official fix coming.

Step 4: If you’re on PHP 8.1 or older

Here’s the uncomfortable piece of this story worth flagging prominently. If the leaked claim (“every PHP version from PHP 5.4 onward” per the Calif.IO banner in the photo Sansec relayed; “PHP 5 onward” in the unverified report) turns out to be accurate, then a huge share of the vulnerable install base has no official PHP fix forthcoming — because PHP’s own support policy ends at 8.2 for security patches. Your options today are: distro-maintained builds that backport the fix into an older branch (Debian and Ubuntu long-term branches often do), or migration to a supported branch, which is not a Tuesday-morning move. If either of those is you, the clock is already running.

Why “affects every version since PHP 5” deserves skepticism

A bug living in PHP core from 2004 to 2026 is not impossible — memory-corruption classics have survived decades inside mature codebases. But a 22-year cross-version reach is a very specific claim, and it deserves a specific kind of proof, namely any of:

• A PoC or working exploit whose code clearly exercises an old PHP behavior.
• The vendor’s own advisory confirming an affected-range table once the PHP emergency patch ships today (PHP is publishing the affected versions with the fix — this is the single most important document to read tonight).
• A researcher write-up from a credible shop with reproduction steps against multiple PHP branches.

Where those stand right now: the vendor advisory has not shipped. But one of the other two sort of exists, and intellectual honesty requires saying so. On the morning of October 21 (~04:26 UTC), a public, self-described PoC write-up surfaced on Hacker News — “PHP session.upload_progress heap UAF (CVE-2026-109618 / -109619)” — from a site calling itself jackalsyn.com. It claims a heap use-after-free in PHP’s session.upload_progress feature that reaches zend_call_function, bundles PoC files, and says it was validated against php-src 8.4.4 and 8.2.34. Two caution flags: its provenance is unknown and unaffiliated with any vendor, and even HN commenters panned the write-up itself (“the text of this is basically unreadable”). The one detail worth taking seriously as a hypothesis: session.upload_progress has existed since PHP 5.4 — which, if this root cause is right, would be notably consistent with the Calif.IO banner’s “from 5.4.0 on” claim. We flag it as an unverified community write-up, not confirmation, until an independent party reproduces it. So the honest rendering of every sentence you hear containing “every PHP version since 5” is still: “a claim relayed via unverified screenshots and a deleted HN post, which watchTowr confirmed the vulnerabilities are real but has not confirmed the version range — and one unproven community write-up claims a 5.4-era root cause.” That’s not dismissiveness — it’s just the correct confidence interval.

It’s also worth naming the pattern: in the gap between leak and patch, exploit names, version claims, and severity figures inflate in the telling — the “CVSS 10” vs. the official “CVSS 9.2” and the “Thursday” vs. “Wednesday” schedule flip are both living exhibits. When the official advisory drops, it may well narrow the version range to something more precise than “everything” — though the 5.4-feature detail circulating above is a reminder that “specific and old” is not the same as “bogus.”

What to watch next

• The PHP emergency patch itself at 14:00 UTC today. PHP.net’s news archive is the authoritative source — and given the downloads page wobble we hit this morning, load balancers may be getting a workout. Expect new point releases on the 8.2, 8.3, 8.4, and 8.5 branches, with the real payloads in the changelogs.
• Distro rebuilds. Debian, Ubuntu, Fedora, Red Hat, Alpine, and the BSDs will likely have rebuilt packages following today’s emergency patch. If you run distro PHP, your window is short — patch the same day you see it land.
• PoC emergence and the first scan waves. Whether “PHP2Shell” becomes a name with code behind it will be decided in the 72 hours after the PHP emergency patch lands. Speed is already part of the threat model: in the TrapDoor supply chain attack, malicious packages were live in npm, PyPI, and Crates.io before most teams knew to look — weaponization now outruns the news cycle.
• CVE record population. As of October 21, both CVE entries are still thinly described and effectively unscored in the major vulnerability databases, per the tracking pages. Watch for NVD to flesh them out — that usually follows within days of a vendor advisory.
• Whether this changes PHP’s disclosure process. An embargoed pair of critical RCEs leaking before coordinated disclosure, forcing the vendor onto an out-of-baseline, next-day timeline, is exactly the kind of event that tends to trigger a review of how embargoed bugs get handled. The PHP team’s own “we reserve the right to release earlier” clause shows a process that anticipated this. The question is what the process says about preventing this.

The bottom line

Today’s PHP emergency patch ships at 14:00 UTC with fixes for two Critical-rated (CVSS v4.0 9.2) vulnerabilities confirmed as real RCE bugs by researchers who’ve reproduced at least one of them — in the most-deployed server-side web language (69.3% share per W3Techs), with roughly 1.3 million internet-connected hosts as one researcher’s public estimate of the affected surface. Everything else — the “PHP2Shell” name, the 10.0 severity, the “affects everything since 2004” claim, the Calif.IO origin — is currently rumor wearing a badge, and is being treated as such here. The moment the advisory drops, read the affected-version table first, patch your supported branches the same day, and start planning an exit on anything running 8.1 or older.

References and further reading

• PHP.net — Upcoming Critical PHP Security Release, php.announce (Oct 20, 2026)
• PHP.net — News archive 2026 (authoritative source for the release)
• PHP.net — Supported versions
• PHP.net — Downloads
• watchTowr — PHP Remote Code Execution FAQ: CVE-2026-109618 & CVE-2026-109619
• Sansec — Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619
• BleepingComputer — PHP warns admins of two critical flaws, emergency patches coming tomorrow
• BleepingComputer forums — Forum Posting Temporarily Disabled Due to PHP Security Concerns (t/819585)
• Ars Technica — PHP warns it plans to release 2 emergency patches imminently (Dan Goodin)
• SecurityWeek — coverage of the PHP emergency release
• 0x4148.com — the report naming “PHP2Shell”
• CERT-EU
• W3Techs — Usage survey of server-side programming languages for websites
• Hacker News API (Algolia) — live thread metrics
• Hacker News — main PHP emergency patch discussion

• ← Previous Post
• Next Post →