---
title: "PHP2Shell takes a server in one request; 2.6 million hosts are exposed"
summary: "How two PHP flaws let one unauthenticated request run code, why the exposure counts disagree, and what to patch and restart first, 17 to 30 October 2026."
url: https://www.thetechbag.com/blog/php2shell-every-php-web-server-one-request
format: Analysis
desk: "Security operations"
published: 2026-10-29
facts_checked: 2026-10-29
author: TechBag (The TechBag Journal)
tags: ["PHP","PHP2Shell","CVE-2026-109618","CVE-2026-109619","CISA KEV","CERT-In","patch management","end-of-life software","WordPress","PAN-OS"]
cover: https://www.thetechbag.com/blog/covers/php2shell-every-php-web-server-one-request.png
---

# PHP2Shell takes a server in one request; 2.6 million hosts are exposed

*How two PHP flaws let one unauthenticated request run code, why the exposure counts disagree, and what to patch and restart first, 17 to 30 October 2026.*

Analysis · Security operations · By TechBag · Published 2026-10-29 · Facts checked 2026-10-29 · Canonical: https://www.thetechbag.com/blog/php2shell-every-php-web-server-one-request

The short version

- Two PHP flaws, CVE-2026-109618 and CVE-2026-109619, let one unauthenticated web request run code on the server, and on Apache with mod_php the attack fires before any of the site’s own code has run. The fix is PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 plus a restart of every worker; PHP says no setting makes an unpatched server safe.[1]
- Attackers were early. An Amazon honeypot logged a probe four days before disclosure, scans began hours before the release, and CISA listed both flaws as exploited on 26 October with a three-day deadline for US federal agencies.[5][11]
- Nobody can say how many servers are exposed: the public counts run from 2.6 million hosts to 167 million installs because they measure different things. Where they agree is the worrying part. Roughly three in four PHP deployments that reveal a version run a branch the PHP project no longer patches.[4][9]

If your organisation has a website, a customer portal or a firewall with a web console, it almost certainly runs PHP, whether or not anyone on your payroll writes it. W3Techs puts PHP behind roughly 70% of websites.[8] The questions are narrower: what breaks when one request arrives, why switching a feature off does not close it, and how to find every copy of PHP you answer for before someone else does. Node.js, Oracle and Java are in our [roundup of the patch week](https://www.thetechbag.com/blog/one-week-php-node-java-oracle-critical-patches); this piece stays with PHP.

## One worker, many strangers: how a single request takes over

Picture how a PHP site serves traffic. The web server keeps a pool of PHP **workers**, long-lived processes that each handle request after request, often thousands before they are recycled. For every request a worker does three things. It sets up: reads the headers, cookies and uploaded body into memory and builds the request’s internal state. It runs the application’s script. Then it cleans up, freeing that memory so it is ready for the next stranger. PHP2Shell is two bugs in the first and third steps, so the application’s own login check and input validation never get a say.

In PHP’s words, CVE-2026-109618 is out-of-memory handling that “can interrupt PHP while internal request data is only partially initialized”, after which “request cleanup may then treat the invalid data as valid.” CVE-2026-109619 is request state that “can survive after its backing memory has been freed”, so “a later request handled by the same worker may use that stale state before normal initialization resets it.”[1] Engineers call the second a use-after-free.[4] Memory is handed back and handed out again while an old pointer still trusts it, and an attacker who decides what gets written there next decides what the worker does with it.

**Figure: The attack lives in the worker's setup and cleanup, before and after the application, so the application cannot stop it**

*The life of one PHP worker and where the two October 2026 flaws sit in it*

Step 1 of 5

1. A worker serves strangers in turn

PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed all keep workers that handle request after request. All five are in scope.

Source: PHP security advisory, 21 October 2026; Qualys TRU; BleepingComputer on the first confirmed exploitation · as of 26 October 2026

PHP rates the risk highest under Apache mod_php, “with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.”[1] The first confirmed compromise in the wild matched that profile exactly: a honeypot running Apache with mod_php on PHP 8.4.26, with a single worker.[8] PHP has not published why mod_php is worse than PHP-FPM, and we will not guess at the internals. What matters is that a mod_php server needs nothing from the application to be taken.

Our view

Our view: do not read the 9.2 score as reassurance. The CVSS v4.0 vector marks attack complexity as high and attack requirements as present (AC:H, AT:P), which is why it is not a 10.[4] That means the exploit depends on memory layout and worker settings, so it is harder to make reliable. It does not mean hard to do. VulnCheck reported on 22 October that most public proof-of-concept code did not yet work.[12] By 24 October a working one had landed on a honeypot.

## The race: probed four days early, listed by CISA in five

The disclosure did not go to plan. On 17 October Amazon’s MadPot honeypot logged an attempt from 103.216.220[.]92, an address Amazon tied to “a commercial anonymization network”. A spokesperson said there was “no evidence” the probe was benign.[5] On 20 October PHP pre-announced a release for 21 October at 14:00 UTC, reserving the right to go earlier “should details of either vulnerability become public”.[1] The Hacker News reports that the coordinated date had been 22 October and was brought forward a day, and that the CVE identifiers and proof-of-concept code leaked ahead of time.[5]

Release day ran ahead of the release. Amazon saw its first attempt at about 02:00 UTC. ELLIO logged its first PHP2Shell request at 08:36 UTC, less than an hour after Chainguard published container images with the fix. ELLIO says Chainguard “unilaterally broke the embargo”; the PHP Foundation says Chainguard had received the patch in advance “so its users could update the moment the vulnerabilities were disclosed.”[5] Cloudflare’s CTO said it was seeing attacks on both flaws before the patches shipped.[7] The web host Pantheon had blocked more than 60,000 suspicious requests by that evening.[5]

**Figure: Attackers were probing four days before the fix and scanning hours before the release**

*PHP2Shell disclosure and exploitation events, 17 to 29 October 2026 (UTC)*

| Date | Event | Detail |
| --- | --- | --- |
| 17 Oct 2026 | Amazon honeypot probed | From an anonymiser in Australia, four days before disclosure |
| 20 Oct 2026 | PHP pre-announces fix | Release set for 21 October, 14:00 UTC; earlier if details leak |
| 21 Oct 2026 | First release-day attempt | Amazon, about 02:00 UTC |
| 21 Oct 2026 | Scans after Chainguard images | ELLIO's first request, under an hour after patched images appeared |
| 21 Oct 2026 | PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 | Scheduled release; no complete mitigation without it |
| 24 Oct 2026 | First confirmed takeover | Honeypot running mod_php on 8.4.26; same day, operators shortlist 216 hosts |
| 26 Oct 2026 | CISA adds both to KEV | Known exploited; forensic triage required |
| 29 Oct 2026 | US federal deadline | KEV due date, three days after listing |

Source: The Hacker News; PHP security announcements; BleepingComputer; Security Affairs on Cyfirma; CISA KEV catalogue · as of 29 October 2026 · The leak of the CVE identifiers and proof-of-concept is reported without a date, so it is not plotted

ReportedWhat KEV listing means

CISA added both CVEs to its Known Exploited Vulnerabilities catalogue on 26 October. The catalogue sets a due date of 29 October for US federal civilian agencies and flags both entries for forensic triage, meaning agencies should look for compromise, not only patch.[10][11]

## Why nobody can count the exposure, and the one thing every count agrees on

Four public counts appeared within a week, and the largest is 64 times the smallest. VulnCheck found 2,608,039 internet-facing PHP hosts and judged 2,607,985 of them, 99.998%, vulnerable or likely vulnerable.[9] Modat counted 4.38 million internet-facing PHP services on 20 October.[5] VirusTotal put exposed PHP hosts at over 5.1 million.[7] Qualys found 167 million PHP package installs across more than 10,000 customers, 73% of them on internet-facing assets, and only 199,000 patched in the first 12 hours.[4]

They are not contradicting each other. A **host** is one internet address that answers a web request. A **service** is an address and a port, so a server answering on two ports counts twice. An **install** is a PHP package an agent found on a scanned machine, including internal servers, containers and machines carrying two PHP versions. And a version banner is not a vulnerability: VulnCheck counts the 1,133,000 hosts that show no version as likely vulnerable, and notes that Linux distributions backport fixes without changing the version string.[9] The scanners overstate on a patched Debian box and understate wherever the banner is hidden.

**Figure: Three counts, three units, one answer: about three in four PHP deployments that show a version are past end of life**

*Per cent of each count by PHP branch status, as published 20 to 29 October 2026*

VulnCheck: 2.61M internet hosts

42%

15%

43%

Modat: 4.38M internet services

79%

21%

Qualys: 167M installs

66%

26%

|  | End-of-life branch (8.1 or older) | Supported branch (8.2 to 8.5) | Version hidden or not reported |
| --- | --- | --- | --- |
| VulnCheck: 2.61M internet hosts | 42 | 15 | 43 |
| Modat: 4.38M internet services | 79 | 0 | 21 |
| Qualys: 167M installs | 66 | 26 | 8 |

Source: VulnCheck (internet hosts, 21 Oct); Modat via The Hacker News (internet services, 20 Oct); Qualys TRU (installs in its customer base, updated 29 Oct) · as of 29 October 2026 · Shares as each vendor published them, rounded to whole per cent. VulnCheck: about 42% end-of-life, 403,000 hosts (15%) supported, 43% showing no version. Modat published only the end-of-life share. Qualys: 110 million end-of-life and 44 million supported installs leave 13 million of its 167 million without a stated branch, which it does not reconcile.

TechBag countTechBag count

Among the hosts and installs that reveal a version, the end-of-life share is 73% in VulnCheck’s data (1.1 million of about 1.5 million) and 71% in Qualys’s (110 million of 154 million). Modat reports 79% across everything it saw.[4][5][9] The gap between the largest and smallest count is 64 times (167 million against 2.6 million). Three methods, one shape: about a quarter on a fixable branch, three quarters on one PHP no longer ships for.

That is the real problem. The PHP project fixed 8.2 to 8.5. For 7.4, 8.0 and 8.1 it published “minimal source-backports” for people who build PHP themselves; there is no release to install.[1] PHP 7.3 and older, PHP 5 included, get no fix at all.[3] VulnCheck counts more than 700,000 internet hosts on PHP 3.x to 7.3.[9] For those, the patch was never coming.

## The PHP you did not know you were running

Most organisations do not run PHP; they run something built on it. VulnCheck could identify the application on part of the exposed estate, and calls every figure a floor.[9] WordPress alone is more than all the others combined.

**Figure: WordPress sits on nearly half a million exposed PHP hosts, more than every other named application combined**

*Internet-facing PHP hosts by application identified, 21 October 2026*

WordPress

4,69,699 hosts

Laravel (incl. Livewire)

1,24,866 hosts

Joomla

26,591 hosts

Drupal

24,116 hosts

Magento / Adobe Commerce

3,735 hosts

MediaWiki

2,116 hosts

Symfony

2,104 hosts

phpBB

1,391 hosts

WHMCS

59 hosts

|  | Value (hosts) |
| --- | --- |
| WordPress | 4,69,699 |
| Laravel (incl. Livewire) | 1,24,866 |
| Joomla | 26,591 |
| Drupal | 24,116 |
| Magento / Adobe Commerce | 3,735 |
| MediaWiki | 2,116 |
| Symfony | 2,104 |
| phpBB | 1,391 |
| WHMCS | 59 |

Source: VulnCheck, PHP2Shell exposure analysis · as of 21 October 2026 · Floors: only hosts where the application could be identified. Hosts are counted once, at their latest scan.

The harder inventory is the PHP inside things you bought. Palo Alto Networks lists PAN-OS and Panorama 10.2, 11.1, 11.2, 12.1 and 12.2 as affected through the management web interface, both the HTTPS console and the XML API; GlobalProtect is not. Its first hotfixes were 10.2.18-h13, 11.1.16-h4 and 11.2.10-h16, with 17 more due between 27 and 30 October. Cisco lists Ultra-Reliable Wireless Backhaul, Expressway and Duo Access Gateway (fixed in 3.2.0) as affected, with 11 products and services under investigation. Fortinet’s FG-IR-26-186 has four products under investigation (FortiDDoS, FortiClient Cloud Services, FortiSOAR and FortiSOAR PaaS) and 43 not affected, FortiOS and FortiWeb among them.[12]

Our view

Our view: the firewall line is the one to underline. A security appliance’s management console is PHP you cannot patch yourself, on a box whose whole job is to be trusted. If a PAN-OS or Expressway console is reachable from the internet, close that path today . Container images are the other blind spot: a base image with PHP baked in stays vulnerable until it is rebuilt and redeployed, whatever the host runs. Ubuntu, Debian and Alpine had fixes out by 22 October; RHEL, Amazon Linux and SUSE had not at that time.[12]

## What to do, in order

PHP’s release notes put it in one line: “There are no complete mitigations, updating is the only safe choice.”[2] Everything below follows from that.

4

Fixed releases: 8.5.12, 8.4.27, 8.3.36, 8.2.35

PHP, 21 Oct 2026

0

Settings that make an unpatched server safe

PHP advisory

3 days

From KEV listing to the US federal deadline

CISA KEV

1. **Find every PHP.** Start with what faces the internet: websites, portals and shared-hosting accounts, then appliance management consoles, then container images and their base layers, then anything a vendor hosts for you. Read the version from the package manager, not the banner, because distribution backports keep the old version string.[9]
2. **Patch, then restart every worker.** Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s fixed package, and restart every PHP-FPM pool, Apache running mod_php, LiteSpeed and FrankenPHP process. A fixed binary on disk does nothing for a worker still running the old code in memory.[3] Rebuild and redeploy images rather than patching running containers.
3. **Decide about end-of-life PHP this week.** On 7.4, 8.0 or 8.1: take a backported package from your distribution or an extended-support vendor, build PHP’s minimal source backport, or upgrade. On 7.3 or older there is no fix; upgrade or take it off the internet. While you decide, PHP’s interim settings (session upload progress off in `php.ini`, a low `post_max_size`, a container memory limit, then a restart) “reduce exposure to specific attack paths but do not make an installation safe.”[1] A web application firewall rule is a bridge too; Cloudflare described its own as temporary.[7]
4. **Assume you were probed, and look.** Anything internet-facing and unpatched after 21 October deserves the forensic triage CISA asks of federal agencies.[11] Look for new PHP files in web roots, since one recorded attempt tried to plant a web shell through PHP’s session upload-progress feature.[9] Look for workers crashing on out-of-memory errors, and for outbound connections from web servers. Rotate session secrets and API keys held by affected applications, because the confirmed exploit read cookie data out of worker memory.[8]

If you are buying this in India

**India is on a named target list.** The threat-intelligence firm Cyfirma reports a campaign it rates with high confidence, and links to the Lazarus family only with *moderate* confidence; it says a Korean-speaking criminal group without state backing would also fit. The operators shortlisted 216 hosts that appeared unpatched or only partly protected on 24 October, named 21 scan nodes, and listed their target countries as the US, Japan, South Korea, Thailand, Indonesia, Australia, Taiwan, India, Singapore, the UAE, Saudi Arabia and the EU. Their priority order puts government agencies first and banks second, then logistics, ports, airports and aviation, then manufacturing, then online trading platforms.[13] These are named targets, not recorded attacks: nothing published says any Indian host was compromised.

**Figure: India is one of eleven countries, plus the EU, on the operators' PHP2Shell target list**

*Countries named as targets in the campaign Cyfirma monitored, 22 to 24 October 2026*

|  | Value |
| --- | --- |
| United States | – |
| Japan | – |
| South Korea | – |
| Thailand | – |
| Indonesia | – |
| Australia | – |
| Taiwan | – |
| India | – |
| Singapore | – |
| United Arab Emirates | – |
| Saudi Arabia | – |
| European Union (named as a bloc) | – |

Source: Security Affairs, reporting Cyfirma's advisory · as of 26 October 2026 · Named targets, not attacks or victims. Countries are outlined; dots mark capitals, with India in red. The EU was named as a bloc and is marked at Brussels. Singapore is too small for the base map and is shown as a dot.

**What CERT-In has said.** CERT-In posted a Current Activities alert, CICA-2026-3650, on 22 October: “Multiple reports confirm large scale exploitation in the wild, users are advised to patch urgently.” Its list of affected software names only the supported branches, 8.2 to 8.5, before their fixed versions.[14] Do not read that as a clean bill for 7.4, 8.0 or 8.1: PHP says those branches are affected too.[1] We found no numbered CERT-In vulnerability note (CIVN) or advisory (CIAD) for PHP2Shell as of 29 October.

**What it costs, and the clock.** No source gives an Indian host count; VulnCheck has no country split, and we will not invent one. The patch costs ₹0. The cost is the inventory and the restarts, and for end-of-life PHP either an upgrade project or paid extended support. If you buy extended support, compare quotes in INR inclusive of 18% GST. And a web shell on a production server is a reportable incident: CERT-In’s directions of 28 April 2022 require it to be reported within six hours of being noticed.[15] For a bank, the second name on the operators’ list, that clock starts the moment someone finds an unexpected PHP file.

How we did this

Figures as of 29 October 2026

Mechanism, affected server types, interim settings and end-of-life status are quoted from PHP’s announcements of 20 and 21 October and the php-8.4.27 release notes. The timeline is from The Hacker News, SecurityWeek and BleepingComputer; the leak itself is reported without a date and is not plotted. KEV dates and the forensic-triage flag are read from CISA’s catalogue feed, version 2026.10.29. Each exposure figure is the vendor’s own and is labelled by what it counts; the end-of-life shares among versioned hosts and installs are TechBag’s arithmetic on them. A Mallory count of about 884,000 hosts and an NVD score of 9.8, seen only in search summaries, are left out. Appliance statuses are as of Help Net Security’s 26 October update. Cyfirma’s findings are as reported by Security Affairs; the advisory itself was not fetched.

Spotted an error? Write to us; corrections are published at the foot of the piece.

Sources

1. [PHP, security release pre-announcement (20 Oct) and advisory for CVE-2026-109618 and CVE-2026-109619 (21 Oct)](https://www.php.net/archive/2026.php) — 20 and 21 October 2026
2. [php-src, release php-8.4.27](https://github.com/php/php-src/releases/tag/php-8.4.27) — 21 October 2026
3. [watchTowr, PHP CVE-2026-109618 FAQ: fixed versions, end-of-life table, worker restarts](https://watchtowr.com/intelligence/php-cve-2026-109618-faq/) — 20 October 2026, updated 26 October
4. [Qualys Threat Research Unit, PHP announces critical security release: CVSS vectors, 167 million installs](https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities) — 20 October 2026, updated 29 October
5. [The Hacker News, Someone tried to exploit PHP2Shell four days before disclosure (Amazon, ELLIO, Chainguard, Pantheon, Modat)](https://thehackernews.com/2026/10/someone-tried-to-exploit-php2shell-4.html) — 22 October 2026
6. [SecurityWeek, PHP2Shell: mass exploitation looms for leaked critical PHP flaws](https://www.securityweek.com/php2shell-mass-exploitation-looms-for-leaked-critical-php-flaws/) — 21 October 2026, updated 22 October
7. [BleepingComputer, PHP ships emergency patches for critical PHP2Shell flaws (Cloudflare, VirusTotal)](https://www.bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws/) — 21 October 2026
8. [BleepingComputer, PHP2Shell security flaws now successfully exploited in the wild (honeypot confirmation; W3Techs share)](https://www.bleepingcomputer.com/news/security/php2shell-security-flaws-now-sucessfully-exploited-in-the-wild/) — 26 October 2026
9. [VulnCheck, PHP2Shell vulnerabilities: exposure, versions, applications, canary activity](https://www.vulncheck.com/blog/php2shell-vulnerabilities) — 21 October 2026
10. [CISA, CISA adds two known exploited vulnerabilities to catalog](https://www.cisa.gov/news-events/alerts/2026/10/26/cisa-adds-two-known-exploited-vulnerabilities-catalog) — 26 October 2026
11. [CISA, Known Exploited Vulnerabilities catalogue feed, entries for CVE-2026-109618 and CVE-2026-109619 (due date, forensic triage)](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) — catalogue version 2026.10.29
12. [Help Net Security, PHP2Shell: Fortinet, Cisco and Palo Alto Networks products affected](https://www.helpnetsecurity.com/2026/10/22/php2shell-vulnerability-fortinet-cisco-palo-alto-networks/) — 22 October 2026, updated 26 October
13. [Security Affairs, PHP2Shell: suspected North Korean campaign targets 216 vulnerable PHP hosts (Cyfirma)](https://securityaffairs.com/201748/hacking/php2shell-suspected-north-korean-campaign-targets-216-vulnerable-php-hosts.html) — 26 October 2026
14. [CERT-In, CICA-2026-3650: Critical remote code execution vulnerabilities in PHP](https://www.cert-in.org.in/s2cMainServlet?pageid=PUBADV01&CACODE=CICA-2026-3650) — 22 October 2026
15. [CERT-In, Directions under section 70B(6) of the IT Act (six-hour reporting)](https://www.cert-in.org.in/Directions70B.jsp) — 28 April 2022

Related on TechBag: the [vulnerability management guide](https://www.thetechbag.com/browse/security/vulnerability-management) covers the scanners that find every PHP install, including the agent-based kind behind the Qualys count; the [RMM and patch guide](https://www.thetechbag.com/browse/endpoint-management/rmm-patch) covers the tools that push fixes and restarts at scale; the [Palo Alto Networks hub](https://www.thetechbag.com/palo-alto) tracks the PAN-OS line whose console is affected.

**Disclosure.** TechBag is a software reseller: it earns a margin when a reader buys through it, including from vendors named here. The analysis is TechBag’s own; no vendor paid for or saw this piece before publication. Facts are labelled reported, TechBag count or our view.

Go deeper on TechBag

- [Vulnerability management guide](https://www.thetechbag.com/browse/security/vulnerability-management) — the scanners that find every PHP install, internet-facing or not
- [RMM and patch management guide](https://www.thetechbag.com/browse/endpoint-management/rmm-patch) — push fixed packages and worker restarts at scale
- [Palo Alto Networks vendor hub](https://www.thetechbag.com/palo-alto) — the PAN-OS line whose management console is affected