PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)

1. News

On 21 October 2026 the PHP project published a security advisory for two critical, unauthenticated remote-code-execution bugs in the PHP runtime. The names in common use are PHP2Shell and, in CISA’s wording, “php2shell”.

Confirmed attack activity (public record)

• AWS MadPot reported an exploitation attempt on 17 October 2026, before public disclosure.
• Cloudflare, AWS, and watchTowr describe large volumes of exploitation attempts after the advisory; Cloudflare’s CEO posted on 22 October about attempts rising from thousands to millions.
• Confirmed compromise of named production websites is not established in the sources reviewed for this page. Secondary reports said the CVEs were not in CISA KEV as of 22 October — check the KEV catalog yourself.

2. Check whether you are affected

Enter the PHP version your web SAPI reports (`php -v`, hosting panel, or `phpinfo()`). This checker only compares version numbers to the upstream fix releases. It cannot see vendor backports.

• Branch pages: 8.5, 8.4, 8.3, 8.2, EOL 5–8.1.
• Full matrix: Affected versions.
• Chinese hosting panel: 宝塔面板.

3. Notable sites and vendors

More detail: Vendor status · Authority assessments.

4. How to fix / patch

1. Upgrade to PHP **8.5.12**, **8.4.27**, **8.3.36**, or **8.2.35** (or newer in that branch). Source and Windows builds: php.net downloads.
2. Restart every worker that serves requests (Apache with mod_php, PHP-FPM pools, php-cgi, FrankenPHP, LiteSpeed, containers).
3. On PHP 8.1 and older: get a vendor backport, rebuild from the project’s minimal source backports for 7.4/8.0/8.1 if you build from source, or take the service offline until you can upgrade — consistent with CISA’s guidance for systems you cannot update.
4. WAF rules and the interim `php.ini` measures in the PHP advisory reduce some paths only. They are not a complete fix.

Step-by-step for apt, yum, Docker, cPanel, Plesk, and more: Remediation.

5. Global exposure and the AI-era pressure on legacy stacks

Public footprint estimates are large, and they are not a count of successfully hacked sites. The Record, citing VirusTotal analysis, and a ThreatCluster write-up both use about **5.1 million** internet addresses fingerprinted as PHP (ThreatCluster notes only about 1.1 million advertise a version header). Separate research cited earlier put Censys-style exposure estimates above **1.3 million** affected hosts. Bitsight’s recent PHP observations concentrated in the US, Germany, France, the Netherlands, and Japan — not a proof that any one country is “more outdated.”

We do **not** invent a dollar figure for global loss. Until insurers, governments, or breach disclosures publish attributable costs, any number would be speculation.

Why this lands harder in the AI era

• Reporting around PHP2Shell (including Wiz and The Record’s coverage of the PHP Foundation) describes AI-assisted review helping surface critical defects that had lingered in a decades-old runtime. Attackers get the same leverage: once a PoC exists, scanning and weaponization scale faster than manual patch cycles on forgotten hosts.
• EOL PHP (5.x through 8.1 without a vendor backport) is still common on shared hosting, appliances, and “set and forget” CMS sites. Those systems often lack owners who still know how to upgrade — so a language-level RCE becomes an internet-wide cleanup problem, not an app bugfix.
• The practical lesson for operators: inventory every place PHP is embedded, patch on the day of the advisory, and retire branches the PHP project no longer ships. The practical lesson for the industry: AI shortens the discovery-to-exploit window; patch latency on legacy stacks is the exposure.