PHP2Shell went live before the patch. Fix your web touchpoints now

Attackers started poking at PHP2Shell days before the fix went live. By the time the patches landed, probes had already surged to millions. If your email stack touches PHP anywhere—from unsubscribe pages to webhook receivers—this isn’t a drill.

What happened

Amazon reported the first PHP2Shell exploitation attempt on October 17, while the flaws were still under embargo, originating from a commercial anonymization network (SecurityWeek). Roughly 12 hours before public disclosure, it saw multiple proof-of-concept (PoC) variants hit from additional anonymized infrastructure, suggesting more than one threat actor.

Both issues—tracked as CVE-2026-109618 and CVE-2026-109619—leaked online on October 20, speeding PoC circulation before fixes were ready (SecurityWeek). The PHP project shipped emergency updates on October 21 at 14:00 UTC in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35, stating that only updating fully protects affected servers (The Hacker News).

Cloudflare said it saw “thousands” of exploit attempts in the 10 hours before public announcement, jumping to “tens of thousands” in the first 45 minutes after, “hundreds of thousands” within two hours, and “millions now,” according to CEO Matthew Prince quoted early Thursday (SecurityWeek). Hadrian, Patchstack, and others also logged activity before patches were available.

WatchTowr observed mass exploitation attempts shortly after release, but noted many PoCs “don’t work at all,” crash targets, or only test timing differences, per Jake Knott’s statement (SecurityWeek). Despite the sloppiness, Amazon stated PHP2Shell is “now being broadly exploited in the wild.”

Censys saw 2.58 million internet-facing hosts on October 21, with 1.58 million reporting identifiable PHP versions and approximately 1.57 million still unpatched (SecurityWeek). By October 22, it tracked nearly 3 million PHP hosts. VulnCheck’s view topped 2.6 million PHP hosts, “nearly all” vulnerable, with at least 1 million running end-of-life (EoL) versions.

VirusTotal counted roughly 5.1 million IPs running PHP overall but only 1.1 million advertising a version in headers; of those, about 272,000 ran a supported version, while approximately 758,000 were EoL (PHP 5.4–8.1) (SecurityWeek). It said about 920,000 of these hosts were in the US, concentrated on providers like AWS, DigitalOcean, Alibaba, OVHcloud, and Hetzner.

CISA urged immediate upgrades to the fixed versions on Wednesday, echoing that the flaws allow unauthenticated remote code execution (RCE) in the PHP runtime itself, independent of any specific application (SecurityWeek; The Hacker News).

The background

The pair of vulnerabilities—colloquially “PHP2Shell”—live in the PHP runtime, meaning even a barebones site can be exposed if its web server executes PHP before application-level checks. That runtime placement is why the PHP team offered no official workaround ahead of release (The Hacker News).

Security researchers rated the bugs 9.2/10 and warned that common environment toggles won’t fully prevent exploitation. One firm that had suggested a stopgap later clarified that setting alone “is not enough on its own,” reiterating only the official updates close the holes (The Hacker News).

BlueVoyant’s CISO John Harbaugh cautioned that events like this surface “forgotten applications” and shadow PHP installs organizations don’t know about, complicating both discovery and patching (SecurityWeek). That aligns with VirusTotal’s finding that most observed versions were end-of-life and unlikely to receive upstream fixes.

ThreatLocker CTO Michael Jenkins warned that in some configurations, these bugs let attackers run code before security checks, justifying emergency updates and proactive compromise hunting (SecurityWeek). He advised using controls that limit what web-facing processes can launch or connect to as a backstop during and after patching.

Comparisons to Log4Shell resurfaced quickly. Forescout’s Sai Molige argued PHP2Shell could reach Log4Shell scale, but for a different reason: organizations will find PHP in “forgotten infrastructure” that lacks an upstream fix. Former hacker Marcus Hutchins estimated it’s “50% the way towards Log4J,” with worse direct exploitation but a shorter tail in third-party software (SecurityWeek).

As with other zero-days we’ve covered in the security hub at /category/security, the early wave included booby-trapped PoCs and prank code. JFrog saw fake exploits on GitHub, and VulnCheck reported at least one Chinese IP trying—and failing—to drop a webshell via PHP2Shell (SecurityWeek). The noise makes triage harder while real actors iterate.

What people are saying

Amazon said its sensors were targeted from anonymized infrastructure before public disclosure and that “PHP2Shell is now being broadly exploited,” highlighting multiple actors entering the fray (SecurityWeek). That timing suggests partial leaks or independent rediscovery ahead of the official announcement.

Cloudflare’s Matthew Prince quantified the surge: thousands of attempts pre‑announcement, tens of thousands within 45 minutes after, hundreds of thousands in two hours, and millions soon after (SecurityWeek). Those curves mirror how we saw attackers rush a Cisco email gateway zero‑day earlier this year, where exploitation also accelerated immediately after patch notes dropped—see our analysis on how attachments were weaponized in /news/cisco-patches-email-gateway-flaw-exploited-through-attachments.

WatchTowr’s Jake Knott played down some panic by noting many PoCs were broken, timing‑based, or crashy, but he still observed broad attempts seconds after release (SecurityWeek). Even low‑quality scanning clutters logs and masks real intrusions.

BlueVoyant’s John Harbaugh emphasized asset discovery: the slowest part is finding everything that needs patching, not the patches themselves (SecurityWeek). That resembles the cleanup dynamic we saw when a compromised backup service forced emergency shutdowns across tenants—see the incident breakdown in /news/connectwise-pulls-cloud-backup-after-173-m365-tenants-hit.

ThreatLocker’s Michael Jenkins recommended process‑level controls to restrict what PHP can access and launch, reminding teams that such hardening should persist post‑incident (SecurityWeek). Least privilege on web servers narrows blast radius if another runtime bug appears.

Censys, VulnCheck, and VirusTotal collectively warned the long tail is massive: millions of internet‑facing PHP servers, with a large fraction running versions that won’t ever see security updates. That’s the same structural risk we outlined when intermediate certificate failures briefly broke trust at scale—the patch gap creates outsized exposure until ecosystems update; revisit our explainer in /news/eight-emudhra-ca-keys-cracked-email-needs-patches-too.

What happens next

Short‑term, expect exploit quality to improve as attackers refine payloads and aim for webshell drops, credential theft, and lateral movement. Amazon already flagged pre‑disclosure scans, and Cloudflare counted millions of attempts in hours, signaling sustained interest (SecurityWeek).

Remediation will hinge on two tracks: upgrading PHP to 8.5.12/8.4.27/8.3.36/8.2.35, and isolating or decommissioning EoL installs that can’t be updated. VirusTotal’s and Censys’s numbers imply that providers hosting large slices of vulnerable fleets—AWS, DigitalOcean, Alibaba, OVHcloud, Hetzner—can blunt risk quickly with guided configuration pushes and WAF rules (SecurityWeek).

For email operations, teams should audit every PHP‑backed endpoint that touches subscribers or mail flows: unsubscribe links, preference centers, landing pages, pixel redirectors, inbound webhooks, and CRM plugins. Rotate secrets used by those components, capture request bodies for forensic review, and block unexpected egress from web hosts.

Medium‑term, expect clearer guidance from vendors and additional detections from EDR, WAF, and CDN providers. The PHP team and researchers were explicit that “no full workaround” existed before patches, and one widely shared mitigation was later walked back as insufficient (The Hacker News). Prepare for updated rulesets and IOCs as working exploit chains stabilize.

Long‑term, treat “How fast can we find everywhere we run X?” as a measurable capability separate from patching speed. Forescout’s Sai Molige framed that as the durable lesson from Log4j, and PHP2Shell’s runtime nature makes that discipline non‑optional (SecurityWeek).