PHP2Shell (CVE-2026-109618/109619): 1.75M Sites Run End-of-Life PHP

PHP2Shell is the nickname for CVE-2026-109618 and CVE-2026-109619, two critical (CVSS 9.2) bugs in the PHP engine that allow unauthenticated remote code execution. PHP fixed them on October 21, 2026 in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. TechnologyChecker's crawl finds 1.75 million sites (45.55% of PHP domains that announce a version) on end-of-life branches with no official fixed release.

I oversee the crawlers behind these numbers: PHP version strings that sites send in their X-Powered-By and Server headers. Most PHP2Shell coverage explains the bug. This post counts who's exposed, which PHP branches can get a fix at all, and how fast sites started announcing patched builds.

Key findings from TechnologyChecker's crawl (30 days to October 20, 2026):

• 4,643,562 domains announced PHP; 17.32% hid the version.
• 54.45% of version-announcing domains run a branch with an official fix; 33.38% run branches that got source patches but no release; 12.17% got nothing.
• 780,934 domains on PHP 8.2 reach end of life on 31 December 2026.
• LiteSpeed sites were the slowest to announce fixed builds after the release.

What Is PHP2Shell (CVE-2026-109618 and CVE-2026-109619)?

PHP2Shell is a pair of memory-safety bugs in the PHP engine's request handling, both rated 9.2 on CVSS v4.0, that let an attacker run code on a server without logging in. The bugs sit underneath WordPress, Laravel and every other PHP application, so clean application code doesn't protect you. php.net's October 21 security release advisory is blunt: "There are no complete mitigations, updating is the only safe choice."

The nickname comes from researchers and the press; php.net doesn't use it. Wiz's research says every PHP version back to 5.4 is affected.

Which PHP setups are in scope?

A SAPI (server API) is the layer that hands web requests to PHP, and the bugs matter wherever a SAPI serves web traffic.

According to Qualys, researchers also showed unauthenticated disclosure of worker memory, which "can contain passwords, authentication tokens, and API keys." Exploitation is rated high-complexity because it depends on allocator layout, the build and worker scheduling.

PHP2Shell Timeline: What Happened From October 17 to 22, 2026?

PHP2Shell went from the first recorded exploitation attempt to a public exposure scanner in five days. Amazon's honeypots logged attempts on October 17, details leaked on October 20, the fix shipped on October 21, and exploitation in the wild was confirmed the same day.

Sources disagree on the exact minute of the release and of Cloudflare's first blocks, and Sansec's timeline places the first attack reports later than ppc.land does. That's why the table says "hours before the release."

Is mass exploitation of PHP2Shell likely?

Mass exploitation looks less likely than the first headlines suggested, but the attacks are real. A researcher quoted by Sansec found that "the public exploits do not work against a default PHP installation," and most need a separate local-file-inclusion bug in the target application. CrowdStrike's demonstrated path needs memory_limit below roughly four times post_max_size, which PHP's shipped defaults don't meet but common upload-friendly pairings such as 64M with 128M do, and Datadog's lab used mod_php prefork with memory_limit=16M and post_max_size=64M.

The reality check isn't a reason to wait. watchTowr has seen exploitation in the wild since October 21, and Datadog reports broad untargeted scanning and cites Patchstack reports of active exploitation. A setting that's non-default on one server is the default on someone else's, so I read the reality check as a guide to patching order, not permission to skip it.

How Many Websites Are Exposed to PHP2Shell?

TechnologyChecker's crawl counted 4,643,562 domains announcing PHP in the 30 days to October 20, 2026, the eve of the fix. Of the 3,839,276 that named a recognisable branch, 1,748,886 (45.55%) run an end-of-life version with no official PHP2Shell release. The other 2,090,390 (54.45%) can install a fixed release from php.net today, and every one of them needs to.

I split the domains by the fix each branch can get. The middle tier needs a definition: for 7.4, 8.0 and 8.1, php.net published minimal source backports on GitHub branches such as PHP-7.4-CVE-2026-109618-109619, meant for source builds and users without a long-term-support vendor. There's no release and no new version number.

Which PHP branches do websites run?

Source: TechnologyChecker crawl, latest PHP version per domain from X-Powered-By and Server headers, 21 September to 20 October 2026. Shares are of 3,839,276 domains announcing a recognised branch; 154 blank or impossible version strings (8.6, 9.x, 114.5 and similar) are excluded. Sources name 5.4 as the oldest affected version; the 33,265 domains on 5.3 and older sit in the no-fix tier because nothing comes from upstream, not because anyone has confirmed them vulnerable.

The real backlog is the backport-only tier. A source patch nobody compiles isn't a fix, and most of those 1,281,669 domains don't build PHP from source: they run a distribution package, a control-panel build or whatever their host installed. Branch 7.4 alone covers 719,622 domains, the third-largest branch in our crawl and the biggest end-of-life one. The no-fix tier is simpler: there's nothing to wait for, so the choice is upgrade, isolate or accept the risk.

As an outside check, W3Techs puts 65.3% of PHP sites on version 8, 26.9% on 7 and 7.7% on 5. Our snapshot reads 69.09%, 25.58% and 5.31% with a different method, so the shape holds. PHP also leads TechnologyChecker's programming languages category by a wide margin.

What happens to PHP 8.2 on 31 December 2026?

PHP 8.2 reaches end of life on 31 December 2026, about 70 days after the fix shipped, and 780,934 domains move into the end-of-life tier with it. If none upgrade first, the end-of-life share of version-announcing PHP sites rises from 45.55% to 65.89%.

How many sites have patched since October 21?

A quarter of the supported-branch domains we re-scanned after the release already announce a fixed build. Between 14:00 UTC on October 21 and about 20:10 UTC on October 22, our crawlers revisited 19,196 domains on 8.2 to 8.5, and 4,901 of them (25.5%) reported a fixed release.

Two caveats before anyone quotes 25.5%. The sample is small and not random, just the domains our crawl revisited in about 30 hours. And distribution builds that carry the fix keep their old version strings, so the true patched share is higher than the headers show.

The first fixed builds appeared within the hour. Four domains announced 8.3.36 in the 13:00 UTC hour on October 21, ahead of the scheduled 14:00 release, which is consistent with distributions receiving patches early; four domains don't prove more than that. In the 14:00 hour, 237 domains announced 8.3.36, alongside the first 8.2.35, 8.4.27 and 8.5.12 builds.

For contrast, Qualys counted only 199,000 patched installs in the first 12 hours across its enterprise customers, and about 70% of the installs it could version sat on end-of-life 5.4 to 8.1. Those are package installs inside companies, a different population from public websites, so I wouldn't compare the two directly.

Why Do Version Strings Overstate and Understate PHP2Shell Exposure?

A PHP version header is evidence, not a verdict. It overstates exposure where Linux distributions backport fixes without changing the version number, and it understates exposure because 17.32% of PHP domains in our crawl hide their version and millions of PHP sites never announce PHP at all. Our guide to how header-based technology detection works covers the general method; the limits below are the ones that matter here.

Where version headers overstate exposure

A PHP 7.4 version string does NOT prove a site is vulnerable: Debian and Ubuntu backport security fixes into their packages without changing the upstream version number. For PHP2Shell, watchTowr reports that distributions and long-term-support vendors received patches before the public release. Qualys notes distro packages may keep older version numbers while carrying the fix, and Ubuntu's USN-8948-1 updated its php8.1, php8.3 and php8.5 packages.

That php8.1 update matters for reading our tiers. PHP 8.1 is end-of-life upstream and sits in our backport-only tier, yet an Ubuntu server with USN-8948-1 installed is patched while still announcing 8.1. AlmaLinux published its own PHP2Shell notice on release day too. So I treat 1,748,886 as an upper bound for unpatched end-of-life sites among those that announce a version.

Where version headers understate exposure

804,132 PHP domains send no version at all, and a hidden version isn't a patched one; it's an unknown one. The bigger gap is sites that never mention PHP. WordPress can't run without PHP, yet our WordPress profile counts 9,555,391 live domains (August 2026 rollup), roughly twice the 4,643,562 announcing PHP in the October window. Only 3,414,525 PHP-announcing domains also show WordPress. The windows differ, but the direction is clear: header-based PHP counts are a floor, ours included.

Which Web Servers and Platforms Put PHP2Shell on the Front Line?

Apache leads where PHP2Shell has no fix: 47.4% of no-fix-tier domains in our crawl show an Apache HTTP Server header, against 27.6% of domains on branches with an official release. The gap matters because mod_php, the setup php.net rates highest-risk, is an Apache module, so Apache is the only server where it can run.

Source: TechnologyChecker crawl, same snapshot. A domain can show more than one server header, so columns don't sum to 100%.

An Apache header does NOT prove mod_php: Apache often proxies PHP requests to PHP-FPM, so the header marks where mod_php is possible, not where it runs. Nginx and LiteSpeed sites use FPM or LSAPI, both still in scope. Those three lead TechnologyChecker's web servers category. My takeaway: the oldest PHP branches cluster on the one server where the highest-risk configuration can exist, and that overlap is where I'd audit first.

Which servers patched fastest?

In the same re-scan sample, grouped by primary server, nginx sites patched fastest and LiteSpeed sites slowest:

We don't know the cause of the LiteSpeed gap yet. One plausible reason, which I'm treating as a hypothesis to check rather than a finding: LiteSpeed sites usually run their host's own PHP builds, so the fix arrives when the host ships it, not when php.net does.

Which PHP platforms are in the blast radius?

Every PHP application inherits PHP2Shell from the engine underneath. Per Sansec, Calif demonstrated unauthenticated RCE against Magento 2.4.9, WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Nextcloud 35.0.1 and Laravel 13.11, plus Roundcube, phpMyAdmin, Symfony and WHMCS.

Source: TechnologyChecker technology profiles, monthly rollups dated August to October 2026 (each profile has its own date); Calif column per Sansec. "Not listed" says nothing about safety: the flaw is in PHP, not the application.

For most of these sites, the PHP binary isn't the owner's to patch. In our PHP profile's co-occurrence data, 876,127 PHP domains also show Hostinger, 432,112 GoDaddy, 228,741 OVH and 150,357 IONOS. On shared hosting the host ships your PHP, so your patch date is your host's patch date.

What Does Cloudflare Radar Show Since PHP2Shell Leaked?

Cloudflare Radar shows attack categories moving in a way that's consistent with PHP2Shell but can't be attributed to it. From October 20 to 18:00 UTC on October 22, Command Injection made up 11.17% of the WAF requests Cloudflare mitigated, against 5.69% in the same window a week earlier, and the "CVE" category rose to 5.44% from 2.47%. Daily, Command Injection went from 5.13% on October 19 to 11.26% on October 20, 8.46% on October 21 and 14.12% on October 22, while Remote Code Execution climbed from 1.28% to 6.14%.

Source: Cloudflare Radar, radar/attacks/layer7 managed-rule categories (radar.cloudflare.com), share of mitigated requests; 20 to 22 October (to 18:00 UTC) versus 13 to 15 October 2026, daily series 24 September to 22 October 2026, pulled 22 October 2026.

The catch: Command Injection hit 28.78% on October 10 and 15.80% on October 8, before anything leaked, and Remote Code Execution reached 11.76% on October 10. Radar groups traffic by rule category, not CVE, so it can't separate PHP2Shell from other campaigns. It also sees only traffic that passes through Cloudflare: 816,260 PHP domains in our PHP profile's co-occurrence data show Cloudflare in front of them, and for every other PHP site a Radar trend says nothing about the origin.

How Do You Check Whether Your PHP Is Affected?

You're affected if the PHP runtime serving your web requests is older than 8.2.35, 8.3.36, 8.4.27 or 8.5.12 on its branch and doesn't carry a vendor backport. The trap: the PHP you check from a shell may not be the PHP serving requests.

1. Find the runtime that serves requests. Put a temporary phpinfo() page behind access controls, read the "Server API" line ("Apache 2.0 Handler" means mod_php, "FPM/FastCGI" means PHP-FPM) and the version, then delete the page.

2. Don't trust php -v alone. The command-line binary can report a different PHP from the one serving requests, so check the FPM binary for your pool (such as php-fpm8.3 -v) or the Apache module.

3. Read the package changelog, not just the version. Distribution builds carry fixes under old version numbers, so search for the CVE IDs (package names vary):

   apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'
   rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'
   

4. Restart every worker. Updated packages don't help until every PHP-FPM pool and Apache process restarts.

5. Run an exposure check. Searchlight Cyber's open-source php2shell-scanner checks from outside; point it only at hosts you own.

6. Search your logs. Datadog's lab lists very long form-field names (around 3.5 MB), null bytes in an empty-named field, "Allowed memory size … exhausted … Unknown on line 0" lines, Apache AH00052 … Segmentation fault (11) errors and web workers spawning shells. None alone proves an attack, and Datadog's refined exploit returned HTTP 200 without a crash, so a quiet log isn't proof of safety.

On shared or managed hosting you can't run most of these checks, so ask your host four questions: which PHP build serves my site, does it include the fixes for CVE-2026-109618 and CVE-2026-109619, have all PHP workers restarted since, and is more than one PHP version active on my account?

How Do You Patch or Mitigate PHP2Shell, Branch by Branch?

Upgrading PHP is the only complete PHP2Shell fix. On 8.2 to 8.5, install your branch's fixed release; on 7.4, 8.0 and 8.1, use a vendor build that carries the fix or compile php.net's source backport; on 7.3 and older, upgrade to a supported branch.

AWS calls upgrading "the only complete fix" and tells 5.4 to 8.1 users to migrate; its security bulletin says AWS services aren't impacted and lists updates for Amazon Linux, Elastic Beanstalk and Lightsail. The UK's NCSC has urged taking offline any system that can't be fixed, as Help Net Security reports. On the RHEL family, watch your package source: rpms.remirepo.net had no updates on release day, and php.net told its users to switch to distribution packages or source builds.

Which partial mitigations help while you patch?

The published mitigations are partial, and php.net is explicit that none is complete. For CVE-2026-109618:

• Set memory_limit = -1 administratively (php_admin_value) so applications can't override it, then restore a finite limit after patching, since unlimited memory raises resource-exhaustion risk.
• Set post_max_size = 8M (32M if you accept uploads), with upload_max_filesize below it.
• Enforce request-size, field, multipart, header and nesting limits at the proxy, and block multipart where you don't use it.
• Use cgroup memory limits, never RLIMIT_AS or RLIMIT_DATA.

For CVE-2026-109619:

• Set session.upload_progress.enabled = 0 in php.ini or the FPM pool (not via ini_set() or .user.ini), then restart workers.
• On 8.5, set fatal_error_backtraces = 0.
• Remove invalid per-request settings and fix attacker-reachable fatal errors and timeouts. Hiding errors with display_errors or @ doesn't help.

Do WAF rules stop PHP2Shell?

WAF rules reduce exposure; they don't replace the patch. Cloudflare deployed rules for both CVEs on all plans including Free, Help Net Security reports, quoting Cloudflare's CTO. AWS WAF guidance points to SizeRestrictions_BODY in the Core rule set for CVE-2026-109618 and PHP Managed Rule Group v2.3 for CVE-2026-109619. Any WAF misses traffic that reaches the origin directly, and its rules can lag new variants.

For online stores, Sansec suggests blocking multipart/form-data at the web server as a stopgap. It breaks Magento admin image uploads and some cart and checkout forms, so place a test order after adding it. In Sansec's words: "You do not need to take your store offline."

Frequently Asked Questions

Is PHP2Shell related to shell_exec()?

No. PHP2Shell is a memory-safety bug in the PHP engine's request handling, not a flaw in the shell_exec() function or exec(). Disabling those functions isn't on any advisory's mitigation list, because the bug triggers inside PHP's own request processing. Only a patched PHP build fixes it.

Is PHP 7.4 patched for PHP2Shell?

Not by an official release. PHP 7.4 is end-of-life, and php.net published only a minimal source backport for people who build PHP themselves or have no long-term-support vendor. A 7.4 site is patched only if its distribution, vendor or host shipped a build with that fix, and the version string won't tell you which.

Is WordPress affected by PHP2Shell?

Yes, through PHP. The flaw is in the engine that runs WordPress, and Calif demonstrated unauthenticated RCE against WordPress 7.1.2, per Sansec. Updating WordPress core or plugins doesn't fix PHP2Shell; updating PHP does, and on managed hosting that update comes from your host.

Does Cloudflare protect me from PHP2Shell?

Partly. Cloudflare's rules run on every plan, Free included, but they only filter traffic that passes through Cloudflare. Requests that reach your origin directly skip them, and rules can lag new exploit variants. Treat the WAF as cover while you patch.

Is the PHP CLI affected by PHP2Shell?

The CLI isn't listed by any source, because it doesn't serve web requests. "Not listed" is not the same as "safe," so update it with everything else. A patched CLI also tells you nothing about the PHP-FPM or mod_php runtime serving your site.

Is patching enough to stop PHP2Shell?

Installing the fixed release closes both CVEs. One unconfirmed claim is worth knowing: Abstract Security says it reproduced unauthenticated RCE on a fully patched 8.2.35 host by chaining session upload progress with an include-style application flaw. Nobody else has confirmed it. Its advice, keeping session.upload_progress.enabled = 0 at pool or php.ini level, costs little if you don't use upload progress.

Is PHP2Shell in CISA KEV?

Not as of October 22, 2026, according to watchTowr. A KEV listing isn't a precondition for acting: exploitation in the wild is already confirmed, and the fix has been out since October 21.

How many websites are affected by PHP2Shell?

TechnologyChecker's crawl counted 4,643,562 domains announcing PHP in the 30 days to October 20, 2026, and every unpatched version back to 5.4 is affected. Of those naming a version, 1,748,886 run end-of-life branches with no official release. Header counts are a floor, since many PHP sites never announce PHP.

How is PHP2Shell different from a PHP web shell?

A PHP web shell is a malicious script an attacker plants on a compromised site to run commands later. PHP2Shell is a pair of engine bugs that can give an attacker code execution in the first place. If you find a web shell, treat the server as compromised and rotate the secrets it held.

Methodology and Sources

• Eve-of-disclosure snapshot: crawl dates 21 September to 20 October 2026, latest PHP version per domain; 4,643,562 PHP domains, 3,839,276 with a recognised branch.
• Version method: X-Powered-By and Server response headers only, grouped by major.minor branch. 804,132 domains (17.32%) sent no version; 154 blank or impossible strings were excluded.
• Server split: same snapshot. Domains can show more than one server header, the no-fix column covers 5.2 to 7.3, and an Apache header marks where mod_php is possible without proving it.
• Patch-uptake sample: 19,196 domains on 8.2 to 8.5, re-scanned from 14:00 UTC on 21 October to about 20:10 UTC on 22 October 2026. The sample isn't random, and distribution backports keep old version strings, so the patched share is a floor.
• Profile figures: platform, hosting and Cloudflare figures come from TechnologyChecker technology profiles with monthly rollups dated August to October 2026. The PHP profile shows 5,337,408 domains in its September rollup, a different window from this post's October snapshot.
• Cloudflare Radar: radar/attacks/layer7 managed-rule categories, share of mitigated requests, pulled 22 October 2026.
• External facts: vulnerability details come from php.net and the GitHub advisories; other claims are attributed inline and linked at first mention.
• What we publish: aggregates only. TechnologyChecker doesn't publish lists of individual vulnerable sites.

If you look after PHP sites for clients or across a portfolio, TechnologyChecker's PHP profile has the full version table, and the same detection data shows which PHP branches, web servers and hosts your own sites run, so you know where to start patching.