PHP's security team has scheduled an out-of-band release for 21 October 2026 at 14:00 UTC to fix two flaws it rates 9.2 on CVSS v4.0. Researchers have nicknamed the pair php2shell, and a leaked post gave them the identifiers CVE-2026-109618 and CVE-2026-109619. This page sorts the php2shell vulnerability story into what PHP has actually confirmed, what researchers and agencies say, and what so far rests only on a leak. It also gives you a short list of things to get done before and right after the patch lands.
php2shell vulnerability: status at a glance
PHP vulnerability: latest status as of our last check (21 Oct 2026, 11:15 UTC):
- Fix released? Not yet. The php.net home page still lists 8.5.11, 8.4.26, 8.3.35 and 8.2.34 (all from 24 September) as current.
- Release time: Wednesday 21 October, 14:00 UTC (10:00 EDT, 16:00 CEST, 19:30 IST). PHP has said it may ship sooner if details leak or attacks are spotted.
- Severity: two critical issues, each CVSS v4.0 9.2, according to the PHP advance notice.
- Affected and fixed versions: not published. PHP says they come out together with the release.
- Exploitation: none reported publicly, per watchTowr and Huntress.
- CVE records: no published record yet on CVE.org or NVD.
The PHP critical security release is the only official statement so far, and it is four sentences long. Everything else you read about php2shell today, including the name, comes from outside the PHP project.
Confirmed, claimed or leaked: sorting the php2shell claims
Most coverage mixes these three tiers together. Here they are separated, with who said what.
| Claim | Who says it | Status |
|---|---|---|
| Two critical vulnerabilities, both CVSS v4.0 9.2 | PHP security team (php.net, 20 Oct) | Confirmed by the vendor |
| Release on 21 Oct at 14:00 UTC, possibly earlier | PHP security team | Confirmed by the vendor |
| The flaws allow remote code execution | watchTowr, Huntress, CERT-EU (citing leaks) | Reported by researchers; PHP has not described the bugs |
| IDs are CVE-2026-109618 and CVE-2026-109619 | Leaked Hacker News post; used by watchTowr, CERT-EU, Mallory | Not in PHP's notice; no published CVE record yet |
| Every version from PHP 5 onward is affected | Leaked post; CERT-EU, citing a Kevin Beaumont post | Unconfirmed; watchTowr notes no vendor advisory backs it |
| CVSS 10.0 | Leaked post only | Contradicted: PHP says 9.2 (v4.0) |
| Fixes will be 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | Mallory and other trackers | Expected, not confirmed: these are just the next patch number on each branch |
| A special configuration is needed to exploit it | Nobody yet | Unknown; watchTowr says no requirement has been described |
One detail neither the leak nor most write-ups mention: when we queried the CVE.org API at about 11:01 UTC, both IDs came back as CVE_RECORD_DNE (no published record), and the NVD API returned zero results. That is normal for embargoed bugs, but it means no CVE page carries an official description of the PHP RCE vulnerability yet.
Timeline of the PHP critical security release (UTC)
- 24 Sep 2026: PHP ships the last regular security batch (8.5.11, 8.4.26, 8.3.35, 8.2.34). Those releases fixed earlier, unrelated bugs, so being current as of last month does not cover the php2shell vulnerability. The php-src GitHub advisory list has nothing newer than this date.
- 20 Oct, around 16:00 UTC (going by the thread's age when we checked): a "Tell HN" post on Hacker News claims two PHP RCE CVEs rated 10.0, an announcement on 22 Oct at 18:00 CEST, and PHP 5+ in scope. The poster admits having no evidence.
- 20 Oct, same day: Huntress reports that watchTowr confirmed the leak was genuine, quoting it as saying everyone was meant to wait until Thursday.
- 20 Oct, later that day: php.net posts "Upcoming Critical PHP Security Release". watchTowr's FAQ goes up at 19:35 UTC. CERT-EU advisory 2026-018 follows the same evening.
- 20 Oct, 19:00 UTC: CISA's KEV catalog version 2026.10.20 is published; it does not list either ID.
- 20 Oct, 22:15 UTC: Mallory publishes Shodan-based exposure figures.
- 21 Oct, 14:00 UTC: scheduled release, a day ahead of the date in the leak.
That makes the PHP security release date one day earlier than the embargo the leak described. If you plan around "Thursday", you are planning for the wrong day. By PHP's own rating it is also a step up from every earlier PHP vulnerability of 2026 fix you may have applied: the advisories published on php-src with the September releases were rated Low, Moderate or High, not critical.
Which PHP branches get the fix
PHP only issues fixes for branches listed on its supported versions page. Today that is four branches:
| Branch | Current release | Support state | Security support ends | Next patch number (expected, unconfirmed) |
|---|---|---|---|---|
| 8.5 | 8.5.11 | Active support | 31 Dec 2029 | 8.5.12 |
| 8.4 | 8.4.26 | Active support | 31 Dec 2028 | 8.4.27 |
| 8.3 | 8.3.35 | Security fixes only | 31 Dec 2027 | 8.3.36 |
| 8.2 | 8.2.34 | Security fixes only | 31 Dec 2026 | 8.2.35 |
Treat the last column as a guess until php.net and the PHP 8 ChangeLog say otherwise. Linux distributions may backport the fix into their own package versions (Mallory names Debian, Ubuntu and RHEL as possibilities), in which case the number you need will not match upstream.
Note the 8.2 row. It gets this fix, but its security support ends on 31 December 2026, roughly ten weeks from now. If you patch 8.2 today, put the next upgrade on the calendar at the same time.
The end-of-life gap
PHP 8.1, 8.0, every 7.x and every 5.x release are end of life, and PHP will not ship a fix for them. If the php2shell vulnerability does reach those branches, the only protections are a distro or vendor backport, an upgrade, or keeping the host off the open internet.
How many systems are in that position? Security firm Mallory ran Shodan counts on 20 October and published these figures. They are third-party estimates based on X-Powered-By banners, not confirmed vulnerable systems:
- About 1.5 million internet-facing hosts announce a PHP version; 59% of them (883,717) run 8.1 or older.
- PHP 5.x: 368,570 hosts; 7.x: 329,358; 8.0 and 8.1 together: 185,789; 8.2 to 8.5: 612,269.
- Two branches alone, 5.6 and 7.2, account for about 371,000 hosts.
- Roughly 740,000 more hosts send a PHP header with no version, so the real number is unknown.
Shared hosting puts many sites behind one IP, so the count of websites is higher than the count of hosts. Our companion PHP end-of-life survival guide covers the options for those older branches in depth.
Your next 24 hours
PHP has published no workaround, so the plan is about being ready to patch fast and shrinking exposure until you can. This list is deliberately short; each step points to a deeper guide.
- List every PHP install. Web servers first, then the less obvious ones: control panels such as cPanel and Plesk, Windows software that bundles
php.exeorphp-cgi.exe, and vendor appliances. Huntress stresses this point because PHP often runs where nobody remembers it. - Record version and SAPI for each. The commands below take a minute per host. Knowing whether you run PHP-FPM, mod_php or php-cgi will matter once PHP says which setups are exposed.
- Set your patch window for 14:00 UTC. Internet-facing systems first. Watch php.net, your distro's security tracker and your host's status page. Our companion guide on checking and upgrading your PHP version walks through each platform.
- Decide now what happens to end-of-life hosts. Upgrade, move behind a VPN or allowlist, or take them offline. For anything you cannot patch quickly, CERT-EU suggests cutting the exposed application off from the public internet until a fixed build is out.
- Start watching what PHP launches. A PHP worker starting
sh,bash,curlorpowershell.exeis the signal Huntress expects. On Linux without endpoint tooling, Florian Roth's process-watcher quick start logs every program a PHP process starts; its own README says it "prevents nothing" and is no substitute for patching. Our companion guide on detecting a PHP web shell covers what to look for and how to harden. - After patching, test the site. A rushed upgrade on WordPress hosts can surface errors such as the missing MySQL extension error in WordPress when an extension package was not reinstalled.
Find the version and SAPI on a host
The CLI version is a quick first check:
php -vOn the official php:8.3-apache Docker image this printed PHP 8.3.35 (cli) (built: Oct 21 2026 00:33:53) (NTS). The CLI binary is not always the one your web server uses, so check the FPM binary too. The SAPI appears in brackets:
php-fpm -vTested on php:8.4-fpm: PHP 8.4.26 (fpm-fcgi) .... Distro packages often name the binary php-fpm8.4 or similar (not tested here). To flag whether a binary is on a branch that can receive the fix:
php -r 'echo PHP_VERSION, " -> ", version_compare(PHP_VERSION, "8.2.0", ">=") ? "supported branch (8.2+)" : "end-of-life branch", PHP_EOL;'Tested on php:8.5-cli (8.5.11 -> supported branch (8.2+)) and php:8.3-apache. The end-of-life output was not exercised, and a pre-release such as 8.6.0 RC3 would also report as supported. On Debian-style Apache, this shows whether mod_php is loaded:
ls /etc/apache2/mods-enabled | grep -i phpIt printed php.load on php:8.3-apache (Apache 2.4.69, Debian).
Questions the release should answer
When the advisory lands, read it for these points before you relax:
- Which component is affected (core, an extension, a SAPI such as FPM or CGI)?
- Does an attack work with a plain HTTP request, or does it need a login, a specific
php.inisetting or a particular way of running PHP? - What are the actual fixed version numbers, and do they match the guesses above?
- Are the CVE IDs the ones from the leak, and when do CVE.org and NVD records appear?
- Does PHP say anything about end-of-life branches being affected?
The answers decide whether the end-of-life exposure is a real emergency or a smaller one. We will update this page as each is answered. Longer term, the habits taught in this secure PHP apps course (input handling, dependency hygiene) matter more than any single patch.
Why the clock matters: the CVE-2024-4577 precedent
The last PHP bug to cause this kind of scramble was CVE-2024-4577, an argument-injection flaw in PHP-CGI on Windows that NVD describes as allowing attackers to run arbitrary PHP code. It reached NVD on 9 June 2024 and was in CISA's Known Exploited Vulnerabilities catalog by 12 June. Akamai's research team reported exploit attempts as early as one day after disclosure. Mallory expects the same pattern for php2shell, with attacks within hours of technical details going public. That is a forecast, not an observation, but it is why the patch window should be hours, not days.
For a non-PHP example of working through a breaking incident with only partial facts, see our Denmark CPR data breach explainer, which uses the same confirmed-versus-reported approach.
FAQ
Is the php2shell vulnerability real?
Partly confirmed. PHP has confirmed two critical flaws rated CVSS v4.0 9.2 and a fix on 21 October at 14:00 UTC. The php2shell name, the CVE numbers, the remote code execution description and the claim that PHP 5 onward is affected all come from researchers and a leak, not from PHP.
When is the PHP security release date?
Wednesday 21 October 2026 at 14:00 UTC, which is 10:00 EDT and 16:00 CEST. PHP said it could release earlier if details become public or exploitation is seen.
Which PHP versions will get a fix?
Only the supported branches: 8.2, 8.3, 8.4 and 8.5. The exact fixed version numbers will be published with the release; the numbers circulating now are expectations.
Are CVE-2026-109618 and CVE-2026-109619 being exploited?
No exploitation had been reported as of 21 October, according to watchTowr, and Huntress says it is not aware of public exploit code. Neither ID is in CISA's KEV catalog version 2026.10.20.
What if I run PHP 7.4 or 8.1?
PHP will not patch those branches. Check whether your Linux distribution or hosting provider backports the fix, and plan an upgrade or isolate the host. Our companion end-of-life guide goes through the options.
Need a hand with the upgrade?
If you run PHP or WordPress sites and want help planning or doing the move to a supported PHP version, fixing plugin and theme compatibility, or keeping an older PHP app running safely while you migrate, our studio, Pravinya Studio, takes on that kind of work. We build WordPress plugins and do Shopify, mobile and AI projects; we are not an incident-response firm.
Last updated / fact-checked: 21 October 2026, 11:15 UTC, before PHP's scheduled 14:00 UTC release. At that time no fixed versions, CVE records or technical details had been published. This page will be updated when PHP publishes the advisory and fixed versions. Commands tested on the official Docker images php:8.5-cli (8.5.11), php:8.4-fpm (8.4.26) and php:8.3-apache (8.3.35).