On October 21, 2026, the PHP project ships an emergency fix for two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619). We analyzed 7.2 million of the world’s most-visited PHP sites to see how many sit in the blast radius. Shocker: 46% of all PHP sites are EOL.
We’ll be tracking the statistics over the next 24 hours and provide updates on our blog.
Key takeaways
This applies to anyone running PHP in production.
- The PHP security team scheduled an emergency security release for Wednesday, October 21, 2026 at 14:00 UTC, for two critical remote code execution vulnerabilities tracked as php2shell (CVE-2026-109618 and CVE-2026-109619).
- Both are rated CVSS 9.2, and the flaw is in PHP itself, not in one plugin or framework.
- PHP’s supported branches, 8.2 through 8.5, will receive a fix. Everything older, 8.1 and down, is EOL.
- Of the top 7.2M PHP websites we analyzed, 46.1% of those that reveal a version run an End-of-Life branch.
- What to do before the release: find out what you run, set expose_php = Off, and make sure logging and alerting are on.
- When the release ships: install PHP’s official update as soon as it is available. PHP encourages all users to prepare so they can upgrade right away.
What is php2shell (CVE-2026-109618 and CVE-2026-109619)?
| php2shell at a glance | |
|---|---|
| Vulnerabilities | CVE-2026-109618 and CVE-2026-109619 |
| Type | Remote code execution (RCE) in PHP core |
| Severity | CVSS v4.0 9.2 (out of 10), per PHP’s advance notice |
| Affected versions | Published with the release |
| Fix release | Scheduled Wednesday, October 21, 2026 at 14:00 UTC |
| Gets a fix | Supported branches, PHP 8.2 through 8.5 |
| End-of-Life | PHP 8.1 and older |
| Exploited in the wild | None confirmed as of October 21, 2026 (not in CISA’s KEV catalog) |
The PHP security team just dropped notice of an emergency security release for Wednesday, October 21, 2026 at 14:00 UTC. It’s been rated as a CVSS of 9.2 (out of 10). The pair is being tracked under the name of “php2shell” (CVE-2026-109618 and CVE-2026-109619).
The full technical details, the exact affected versions, and the patched versions are held back until the release itself. That embargo is deliberate: it gives defenders time to prepare without handing attackers a map. But it also starts a countdown. Once the patch is public, the code change points straight at the bug, and attacks on unpatched servers usually follow within hours to days.
When was php2shell announced, and what happens next?
PHP announced the release on October 20, less than a day before it ships.
| When (UTC) | What happened |
|---|---|
| October 20, 20:32 | The PHP security team posted advance notice of a security release for two critical vulnerabilities, both rated CVSS v4.0 9.2. |
| October 21 | CVE-2026-109618 and CVE-2026-109619 were still in the “Reserved” state, with no technical details. |
| October 21, 14:00 | The scheduled release. PHP says full details, affected versions, and fixed versions will be published with it. |
Why is a PHP core flaw close to worst-case?
Remote code execution (RCE) means an attacker can run their own commands on your server without logging in (meaning, without any authentication). From there, the familiar outcomes follow: stolen data, web shells, ransomware, and a foothold to move deeper into the network. A CVSS score of 9.2 signals that this is reachable over the network and takes little skill to exploit.
What sets php2shell apart from the average CVE is where it lives. This is not a bug in one plugin or framework. It is in PHP itself, the runtime beneath roughly three-quarters of all websites whose server-side language is known.
Which PHP versions will get a fix?
PHP’s supported branches, 8.2 through 8.5, will receive a fix. Everything older, 8.1 and down, is EOL. It’s likely there will be backported fixes provided by some third-party vendors like CloudLinux. Note: Many servers can easily be ported to CloudLinux.
How many PHP sites are exposed? Our October 1 measurement
To size the problem, we analyzed the top 7.2M PHP websites. We identified PHP sites by their technology fingerprints and, where the server advertised it, read the PHP version from the response.
| Measure | Count | Share |
|---|---|---|
| Sites running PHP (top 15M) | 7,204,520 | 47% of the top 15M sites |
| Expose a PHP version | 2,152,204 | 29.9% of PHP sites |
| On supported branches (8.2-8.5) | 1,159,136 | 53.9% of version-visible |
| On End-of-Life branches (8.1 and older) | 992,930 | 46.1% of version-visible |
Among sites that reveal a version, the most common are PHP 8.3 (24%), 7.4 (19%), 8.2 (17%), 8.1 (9%), and 8.4 (9%). PHP 7.4, End-of-Life since late 2022, is the second most common version on the visible web.
Two caveats. We performed a passive, header-based read: about 70% of sites do not advertise their version, so version-level findings describe the roughly 30% that do. And the snapshot predates the fix, so it is a “before” picture, the baseline for how the web looks the moment the clock starts.
How big is the patching gap?
Among sites that do reveal their version, the split is nearly even: a little over half run a supported branch (will have a patch), and just under half run an EOL branch that may not. Given the size of this vulnerability, we wouldn’t be surprised (but don’t count on it) if PHP decides to publish patches for older versions of PHP.
When you project that version-share pattern onto the roughly 70% that do hide their version, the picture is sobering. On the order of 3.4 million of these top sites appear to run an EOL version of PHP! Their only real options are to upgrade, or to put compensating controls such as a web application firewall in front of the application. We imagine WAF providers like Cloudflare will also implement rules to protect their orange-clouded customers.
Cloudflare’s CTO, Dane Knecht, announced hours ago on X that they’ll have this covered.
The several million sites on supported branches are not safe on day one either; they are simply the group that has a patch available. Whether they are actually protected comes down to how fast they apply it, which is the number we will track in the days after the release.
What should you do before the PHP security release at 14:00 UTC?
There are rumors that you can mitigate the vulnerability by setting the following in your php.ini:
session.upload_progress.enabled = Off
On cPanel servers, you can find your php.ini file at:
/opt/cpanel/ea-phpNN/root/etc/php.ini
Replace NN with your cPanel PHP version, e.g., /opt/cpanel/ea-php74/root/etc/php.ini
You may also want to update your cPanel bundled PHP as well:
/usr/local/cpanel/3rdparty/php/NN/etc/php.ini
Replace NN with your cPanel bundled PHP, e.g., /usr/local/cpanel/3rdparty/php/84/etc/php.ini
- Find out what you run. If you’re running cPanel, you can find your php.ini files using this command:
locate php.ini | grep /opt/cpanel - Stop advertising your version. Set
expose_php = Offso your server stops volunteering its version in response headers. It is not a fix, but it removes an easy targeting signal. - Assume probing starts fast. Make sure logging and alerting are on so you can spot exploitation attempts when they begin.
How do you find every PHP version you run?
The hardest part of php2shell will not be applying the patch. It will be knowing which of your sites, subdomains, and half-forgotten staging servers still run an exposed or EOL PHP version in the first place.
Want to know where php2shell leaves you and where your data is being transmitted? See your exposure at MELURNA.
FAQs
Is php2shell being exploited in the wild?
We found no official confirmation of exploitation as of October 21, 2026. Neither CVE is in CISA’s Known Exploited Vulnerabilities catalog (version 2026.10.20, released October 20 at 19:00 UTC). PHP also said it would release earlier if evidence of active exploitation appeared, and as of 09:00 UTC on October 21, it had not.
How can I spot php2shell exploitation on my server?
PHP hasn’t published how php2shell works, so look for the general signs of code running through a web server: your web server or PHP processes starting a shell such as bash, cmd.exe, or powershell.exe (MITRE ATT&CK T1505.003), running a download tool such as curl (MITRE ATT&CK T1105), or running reconnaissance commands such as whoami (NSA guidance on web shells). These checks only cover servers you already monitor, so start with a complete list of where PHP runs.
Is there a public proof of concept for CVE-2026-109618?
Not from any official source. PHP will publish full details and the fixed versions with the release, and both CVE records on cve.org were still “Reserved” with no technical description on October 21. Treat any exploit shared on social media before then as unverified.
Does updating WordPress or my plugins fix php2shell?
No. The fix ships as a new PHP release, and PHP is the server software WordPress runs on, not part of WordPress. WordPress lists PHP as a server requirement and recommends PHP 8.3 or greater. The PHP installation on your server has to be updated.
What time is the PHP security release in US time zones?
The release is set for 14:00 UTC on Wednesday, October 21, 2026. That is 10:00 a.m. EDT and 7:00 a.m. PDT. PHP may release earlier if details become public or exploitation appears.
Will my hosting provider patch PHP for me?
Only if they manage PHP on your server. Whoever controls the PHP installation has to install the release, so ask your host today whether they will apply it, and when. If you’re on PHP 8.1 or older, the release won’t cover you. PHP’s supported branches are 8.2 through 8.5, and 8.1 reached end of life on December 31, 2025.
