2.24M Internet-Facing PHP Hosts, 59% on Versions With No Fix Coming: What We Know About php2shell
Table des matières
PHP ships an emergency security release on 21 October 2026 at 14:00 UTC (16:00 CEST) for two critical remote code execution (RCE) vulnerabilities in PHP core, tracked as CVE-2026-109618 and CVE-2026-109619 and both rated 9.2 under CVSS v4.0. CERT-EU notes the scores suggest they could be exploited without authentication, and researchers call them “php2shell”, a name implying an attacker could obtain a shell on a vulnerable server.
The incident started with a leak. On the morning of 20 October, a since-removed Hacker News post claimed the two flaws were about to be disclosed; within hours, watchTowr confirmed they were real and said it had reproduced CVE-2026-109618. The PHP security team then scheduled its release a day earlier than the original embargo, reserving the right to ship sooner if details went public or attacks began.
The stakes come from PHP’s reach: it powers WordPress, Drupal, Joomla and Magento sites, shared hosting platforms, control panels and a lot of vendor software that does not advertise it. Exploitation has now been reported in the wild, according to Aikido, which cites Cloudflare; on 20 October, watchTowr and Huntress had seen none. Sansec expects mass exploitation within 15 minutes of the release.
The fix happens at the infrastructure level: updating PHP on the server is the only official remediation, and CMS or plugin updates will not apply it.
Timeline
The disclosure was originally under embargo until Thursday 22 October at 11:00 ET; after the leak, PHP scheduled its release a day earlier than that.
You can review the technical timeline in more detail below.
| Date (UTC) | Event | Source |
|---|---|---|
| 21 Oct, 14:00 | Scheduled PHP security release with fixed versions and technical details | CERT-EU |
| 21 Oct, 09:18 | Aikido reports exploitation in the wild, citing Cloudflare | Aikido |
| 21 Oct | Cloudflare pushes an emergency update to its managed WAF ruleset, adding four rules understood to target these flaws (its changelog does not mention PHP) | The Repository |
| 21 Oct | A site claiming to publish working exploit code goes public; WordPress hosts reportedly start disabling session.upload_progress | The Repository |
| 20 Oct | CERT-EU publishes Security Advisory 2026-018 | CERT-EU |
| 20 Oct | PHP security team posts advance notice: two critical vulnerabilities, both CVSS v4.0 9.2 | CERT-EU |
| 20 Oct | watchTowr confirms the leaked vulnerabilities are real and names CVE-2026-109618 and CVE-2026-109619 | The Repository |
| 20 Oct | A Hacker News post, since removed, reports two upcoming PHP RCE disclosures, breaking the embargo | The Repository |
What we know about the vulnerabilities
Only the severity and the release time are official; everything else comes from researchers and must be treated as provisional until PHP publishes its advisory.
Confirmed
- Two critical vulnerabilities, both rated CVSS v4.0 9.2 by the PHP security team. The IDs CVE-2026-109618 and CVE-2026-109619 come from watchTowr and CERT-EU; PHP’s own notice does not list them.
- CERT-EU notes the scores indicate potential for unauthenticated remote code execution.
- watchTowr confirmed the leaked reports describe real vulnerabilities and believes it reproduced CVE-2026-109618.
Reported, not yet confirmed by PHP
- Exploitation: Aikido reports exploitation in the wild, citing Cloudflare, which says attacks have started (Aikido). watchTowr had reported none at the time of its last update.
- Scope: every PHP version from PHP 5 onward, according to an unverified report cited by watchTowr and CERT-EU.
- Nature: GMO Flatt Security reads a researcher’s demo video, labelled “php2shell”, as showing a memory corruption bug, reproduced on mod_php and PHP-FPM and on WordPress, Laravel and Symfony setups.
- Component: Flatt’s own research points to the Session Upload Progress feature (ext/session), which is enabled by default.
Affected versions and patch status
Only the four supported branches, PHP 8.2 to 8.5, are expected to receive patched point releases; PHP 8.1 and older are end of life and will get no official fix. Exact fixed version numbers will be published with the release; the latest builds available before it (8.5.11, 8.4.26, 8.3.35 and 8.2.34) are not fixed versions.
| PHP branch | Support status (20 Oct 2026) | Official fix expected |
|---|---|---|
| 8.5 | Active support | Yes |
| 8.4 | Active support | Yes |
| 8.3 | Security fixes only | Yes |
| 8.2 | Security fixes only, until 31 Dec 2026 | Yes |
| 8.1 | End of life since 31 Dec 2025 | No |
| 8.0 and older | End of life | No |
Source : mySites.guru, based on the php.net supported versions timetable. Being on a supported branch is not enough on its own: the server must also run the new patch level within that branch.
Exposure: how many assets, and where
About 2.24 million internet-facing hosts advertise PHP, and 59% of those that report a version (883,717 of about 1.5 million) run a branch that will get no official fix. These figures come from Shodan banner counts published by Mallory on 20 October 2026; they count hosts, not organisations or websites.
By version
PHP 8.2 to 8.5 account for 612,269 versioned hosts and will receive the fix. PHP 5.x (368,570), 7.x (329,358) and 8.0–8.1 (185,789) will not. PHP 5.6 and 7.2 alone represent about 371,000 unpatchable hosts.
By country
The United States has the largest number of hosts with no fix coming (228,770), followed by China, Japan and Germany. Among these ten countries, Algeria (100%, almost entirely PHP 5.3 on Telecom Algeria), South Korea (82%) and China (75%) have the highest shares. France counts 25,439 unpatchable hosts, 54% of its versioned PHP hosts.
By hosting provider
Exposure is concentrated: Amazon (293,480 PHP hosts), Hostinger (142,401) and Alibaba Cloud (81,078) host the largest PHP populations, which makes provider-side patching decisive.
WordPress
Selon le WordPress.org statistics reported by The Repository, 35.1% of WordPress sites run a PHP version the PHP project no longer patches, including 16.46% on PHP 7.4. Across the live Joomla and WordPress sites mySites.guru monitors, 22.7% run PHP 8.1 or older.
Limits of these numbers
The real exposure is higher than banner counts suggest: about 740,000 PHP hosts hide their version, and shared hosting puts many websites behind one IP. Conversely, some Linux distributions (Debian, Ubuntu, RHEL) may backport fixes to older packages.
A different count puts France first
Measuring active PHP services rather than hosts, Infrawatch observes about 11 million services across 4.38 million IP addresses, with France at 6.62 million, more than eight times the United States. Much of that concentration comes from Freebox OS, the management software of Free’s home routers; Infrawatch stresses this does not mean these hosts are exploitable.
Recommendations
Patch PHP itself as soon as the release lands; every other measure only buys time.
- Inventory every internet-facing PHP asset, including those run by hosting providers, agencies and appliance vendors, and record the branch and SAPI (PHP-FPM, mod_php, php-cgi).
- Patch at release, then restart PHP-FPM or the web server so the new interpreter is loaded. Check the version the site reports while serving a request, not
php -v, as the two binaries often differ. - On managed hosting, confirm the timing with your host, and take a fresh backup before anything changes on the server.
- Plan the upgrade of end-of-life branches (8.1 and older). Until then, restrict access (VPN, IP allowlist) or isolate internet-facing applications, as CERT-EU recommends.
- Reduce exposure until you patch: take internet-facing PHP applications offline where you can.
- Check for compromise after patching, going back to at least June 2026: web shells, unexpected or modified PHP files, new admin users and unusual outbound connections. Watch for unexpected child processes of the web server, reduce the data and cloud privileges held by PHP servers, and check that logs are retained.
How CybelAngel is helping
Our teams are reviewing the external perimeters we monitor for the signals that matter here: exposed web servers, outdated software stacks and PHP-based control panels. Where we see heightened risk, we are reaching out to customers directly. If you are not a CybelAngel customer and want to understand your external exposure, contact our team.
Please note that we will update this article once PHP publishes the technical details and fixed versions.
À propos de l'auteur
