Quick response by shared and managed hosting providers has led to a sharp jump in patched sites. On Wednesday, PHP.net shipped an emergency fix for two critical, remotely exploitable flaws. Twenty-four hours later, we re-checked every site on the web that advertises its PHP version to see who actually updated. The short answer: 23% of PHP sites have been patched. The bottom line: 24 hours later, 77% of PHP sites are still vulnerable!
By Wednesday evening, Cloudflare CEO Matthew Prince announced that there had already been millions of attempts at exploiting the vulnerability.
If you manage PHP in production, this article shares PHP2Shell patch data on how quickly sites updated, which versions remain vulnerable, and what to do now.
Key takeaways
- Twenty-four hours after PHP shipped the fix, 23% of PHP sites had been patched, 77% were still running a vulnerable version.
- Newer branches patched fastest: 54.5% of PHP 8.5 sites are patched, versus 33.7% of PHP 8.2 sites.
- Most early patching came from hosting providers updating hosting platforms at once. Sites on their own web servers stay exposed until someone updates them by hand.
- Some hosts patched almost their entire supported-branch fleet in a day: Loopia reached 99.9%, and Beget, GMO Internet and IONOS each moved more than 90% of their PHP 8.2 to 8.5 sites onto the fix within 24 hours. Amazon AWS (65.3%) and OVH (59.7%) lagged behind.
- Among the sectors we tracked, education patched fastest at 23.9% of sites, but End-of-Life PHP is the bigger gap: 50.6% of government sites and 60.3% of gambling and adult sites still run it.
- The rollout was rough: package mirrors for AlmaLinux, CloudLinux, and cPanel were outdated or failed intermittently, leaving some servers half-updated.
- What to do now: check your PHP version, update immediately to the fixed release (8.2 to 8.5), plus a web application firewall.
What is the PHP2Shell patch status after 24 hours?
In the first 24 hours after the fix shipped:
- 23% of the PHP sites had already been patched. Fast adoption, mostly due to patching from managed hosting providers.
- 77% are still running a vulnerable version. Of those, more than half are on End-of-Life (EOL) PHP that won’t receive a patch.
- Naturally, the newest supported branch moved fastest: 55% of PHP 8.5 sites are already patched, versus 34% of PHP 8.2 sites.
How fast did PHP sites patch PHP2Shell?
Adoption was uneven, and it tracked closely with how current a site already was. In the first 24 hours, the share of sites on each branch running the fix climbed to:
- PHP 8.5: 54.5%
- PHP 8.4: 52.5%
- PHP 8.3: 43.3%
- PHP 8.2: 33.7%
- All PHP versions: 22.9%
The newer the branch, the faster it was patched, which fits the pattern that the best-maintained sites are also the quickest to update.
Hosting providers accelerate patching
Hosting providers brought hundreds of thousands of websites up to date within 24 hours. Among sites on a supported PHP branch (8.2–8.5), Swedish host Loopia had 99.8% on the fixed release nine hours after it shipped and 99.9% at the 24-hour mark; IONOS, GMO Internet and Beget each moved more than 90% of their supported-branch sites onto the fix within 24 hours. Beget almost entirely between hour 9 and hour 24.
Biggest gains, baseline → 24 hours (tracks supported branches 8.2-8.5)
| Operator | 9h (after patch released) | 24h |
|---|---|---|
| Beget | 0.3% | 98.1% |
| GMO Internet | 66.0% | 96.5% |
| IONOS | 66.3% | 96.4% |
| Dogado (part of Group.one) | 89.1% | 98.3% |
| Microsoft Azure | 64.4% | 82.3% |
| Duocast | 54.6% | 79.7% |
| TransIP/Signet | 77.8% | 93.2% |
| DigitalOcean | 41.1% | 74.5% |
| Loopia | 99.8% | 99.9% |
| Amazon AWS | 28.8% | 65.3% |
| Hetzner | 42.9% | 64.4% |
| One.com (part of Group.one) | 80.9% | 86.9% |
| OVH | 34.5% | 59.7% |
Patch rate by sector
| Industry | Patched (all) | Patched (of supported 8.2–8.5) | On EOL PHP |
|---|---|---|---|
| Education (.edu, .ac.*, .k12) | 23.9% | 46.3% | 48.2% |
| Healthcare | 22.8% | 40.9% | 42.2% |
| Real Estate / Construction | 22.3% | 42.4% | 45.0% |
| Government (Worldwide aggregate, e.g., .gov, .gov.br, .gov.in) | 22.1% | 44.8% | 50.6% |
| Gambling & Adult | 18.7% | 47.8% | 60.3% |
What is PHP2Shell (CVE-2026-109618 and CVE-2026-109619)?
On October 21, the PHP project released an emergency security update fixing two critical vulnerabilities in PHP’s core, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10. Both allow remote code execution, meaning an attacker can run commands on an unpatched server without logging in. Because the flaws are in PHP itself and not in any single application, the exposure spans a large share of the web.
PHP powers nearly 70% of websites whose server-side language is known, from custom PHP applications to WordPress sites. The PHP security team’s advisory says all PHP installations that serve web requests are at risk, and rates Apache mod_php highest.
These two critical PHP vulnerabilities sit in PHP’s core request handling. CVE-2026-109618 allows unauthenticated remote code execution through memory corruption after an out-of-memory error. CVE-2026-109619 lets request state outlive its freed memory, so a later request on the same worker can reuse it. It also lets attackers steal sensitive data from PHP’s memory. The affected versions are every supported branch before the fixed releases below.
The fixed releases are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Anything on 8.1 or older is End-of-Life and will only receive a fix from third parties who may provide backported fixes. Note: There are mitigation measures you can implement to prevent exploitation.
Our php2shell explainer covers the technical details.
Which PHP sites are still exposed to PHP2Shell?
Patching the easy cases still leaves most of the web behind. Among sites that reveal a version:
- 23% are patched.
- 33% are on a supported branch (8.2 to 8.5) but have not applied the fix. The patch exists; they simply have not installed it.
- 44% are on End-of-Life PHP (8.1 and older). For them, there is no official fix. They are not waiting on a patch; they need a migration.
That last group is the real problem. PHP 7.x and older, all End-of-Life, is the single largest slice of the web. These sites stay exposed until they move to a supported branch, and for them “update PHP” is not a one-click action.
Why did some sites patch so fast?
Almost all of the early patching came from hosting providers, not individual site owners. The patched sites cluster tightly on shared infrastructure: about 56% of them sit on an IP address that hosts five or more other patched sites, and a third on an IP with twenty or more. The busiest single IP address carried over a thousand patched sites, and many carried 500 or more each, the signature of individual providers pushing a PHP update across their entire fleets.
When a managed host updates, thousands of sites flip at once. When a site runs its own server, nothing happens until someone logs in and acts. That divide is the story of the first day, and it is why the headline percentage is far higher among managed sites than across the web as a whole.
On Wednesday evening, Cloudflare CEO Matthew Prince announced that there had already been millions of attempts at exploiting the vulnerability.
Why was the PHP update hard to install?
The rollout was not smooth on the operations side. Throughout the day, the package mirrors and repository servers they rely on to fetch the update, including CentOS, AlmaLinux, CloudLinux, and cPanel mirrors, were intermittently failing or not responding. Update jobs timed out, retried, and in some cases left servers in a half-updated state that needed manual recovery.
Hosting providers experienced connection timeouts and failed requests to AlmaLinux and CloudLinux mirrors, which delayed emergency PHP security updates, causing package managers to stall, retry connections, and experience significant delays.
The practical lesson for operators: an emergency release puts sudden, synchronized load on the same mirror infrastructure everyone depends on, and that infrastructure can become the bottleneck. Staging the update, pinning a known-good mirror (or your own), and verifying the installed version afterward all help.
What should PHP site owners do now?
- Check your version today. Confirm the PHP version on every internet-facing host. If you are not sure, assume it is older than you think.
- On 8.2 to 8.5: apply the fix now. The patched releases (8.2.35, 8.3.36, 8.4.27, 8.5.12) are out. This is a same-day action, not a maintenance-window item.
- On 8.1 or older: you will not get a patch. Perform mitigation measures and plan the migration to a supported branch, and place a web application firewall (e.g., Cloudflare, Fastly) in front of the application in the meantime.
- If you are on managed hosting, confirm your provider has updated your account. PHP says Linux distributions and LTS vendors received the patches in advance.
The first 24 hours show that fast patching is possible; it already happened for hundreds of thousands of sites on well-run hosting. The gap now is everyone else, and the window before exploitation becomes routine is short.
FAQs
If there is no patch available, what settings should I use to mitigate the PHP vulnerability?
Temporary mitigations include using the following settings in your php.ini (please research and understand what these settings do before using them):
post_max_size = 32M
upload_max_filesize = 26M
memory_limit = -1
session.upload_progress.enabled = Off
The above applies to all PHP versions.
What did the PHP Foundation say about PHP2Shell?
In its October 21 post, the PHP Foundation said a PHP core developer it contracts first found signs of the out-of-memory problem behind CVE-2026-109618 in 2024, and that its funding let several people work on the fix full time. It called the delay in fixing it a structural failure of the security team’s decision process and resources, and says the team is changing how it makes decisions.
Is PHP 7.4 still safe to use?
No. PHP 7.4 reached end of life on November 28, 2022, so it no longer gets regular security updates. For php2shell, the PHP team published mitigation steps for PHP versions 8.1 and older. In Melurna’s October 20, 2026 measurement, 7.4 was still the second most common version among sites that reveal one, at 20%.
What is a PHP security update?
It is a new point release of a supported PHP branch that fixes security issues, such as PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 for php2shell. PHP 8.4 and 8.5 are in active support, while 8.2 and 8.3 get security fixes only, and PHP 8.2’s security support ends on December 31, 2026. Sites that patch to 8.2.35 should plan their next upgrade now.
