Skip to content
Hacker Posts

PHP2Shell flaws exploited days before the patch, Amazon says

Amazon's MadPot honeypot logged a PHP2Shell exploit attempt on Oct 17, four days before PHP shipped fixes for CVE-2026-109618 and CVE-2026-109619. Mass exploitation followed.

Published 3 min read
cvephprceexploited-in-the-wild

Amazon Threat Intelligence says it saw someone try to exploit the two PHP2Shell flaws on 17 October 2026 — four days before PHP shipped the fixes. The attempt hit Amazon's MadPot honeypot while the vulnerabilities were still under embargo, and mass exploitation followed within hours of Wednesday's patch release. If you run PHP exposed to the internet and haven't applied the 21 October release, the window to patch ahead of attackers has already closed.

The two bugs are CVE-2026-109618 (RCE via out-of-memory corruption) and CVE-2026-109619 (RCE via stale global state), both rated CVSS v4.0 9.2 and both allowing unauthenticated remote code execution. We covered the pre-announcement when PHP would only confirm the scores; the CVE IDs and fixed versions are now public.

Fixed versions

PHP shipped the fixes on 21 October at 14:00 UTC, per the php.net release archive:

8.5.12   8.4.27   8.3.36   8.2.35

End-of-life branches 7.4, 8.0 and 8.1 received source-only patches to compile yourself; everything on 7.x and 5.x should migrate to a supported branch. The highest-risk configuration is Apache with mod_php, where an unauthenticated request can trigger the flaw before any application code runs.

Exploitation status

This is confirmed in the wild. Amazon's account, reported by BleepingComputer and The Hacker News:

  • The 17 October attempt "originated from an IP address associated with a commercial anonymization network," said AWS chief information security officer CJ Moses. Targeting a honeypot from an anonymized IP while the flaws were embargoed points to a threat actor with early knowledge.
  • Within hours of disclosure, attackers deployed multiple proof-of-concept PHP2Shell exploits from VPN addresses.
  • Cloudflare, watchTowr, Previdian, Hadrian and Patchstack separately reported unsuccessful pre-disclosure attempts.

No group has claimed responsibility, and no public attribution ties the activity to a named actor. VirusTotal tracks more than 5.1 million exposed PHP hosts, roughly 3.8 million with at least one port open — the surface is enormous.

Action checklist

  1. Patch internet-facing PHP first: move to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 on the matching branch. Compile the source patch for 7.4 / 8.0 / 8.1, or migrate off them.
  2. Prioritise mod_php deployments — that is where the pre-auth path is cleanest.
  3. Hunt for compromise before you assume the patch closed the door. Any exposed host running an unpatched build since 17 October should be treated as potentially breached: review PHP worker and web-server logs for anomalous requests and unexpected child processes.
  4. The UK's NCSC asked organisations to update PHP servers or take them offline until they can. If you can't patch an exposed host today, pull it from the internet.
  5. Rotate credentials and secrets reachable from any host you suspect was hit.

Context

The gap between a pre-announced security release and working exploitation is normally measured in hours once the diff is public. Here it ran the other way: exploitation attempts preceded the patch, which is the worst case for an embargoed server-side RCE and a reminder that "no public PoC yet" is not the same as "not being attacked." PHP core developer Gina Peter Banyard's guidance is the only durable one — applying the official patch is the sole permanent defence. Mitigations buy time; they don't close a 9.2 pre-auth RCE.

Related stories