Post cover image
Where a PHP core RCE flaw sits in the request path

October 25, 2026

PHP2Shell: Two Critical PHP RCE Flaws (Know the Adversary, Patch, Hunt, Respond)

By Musa Touray

3 min read

PHP2Shell: Two Critical PHP RCE Flaws, What We Know, and What to Do

Last updated October 24, 2026. Exploitation status reflects vendor reports through October 23. This story is still developing, so check the primary sources below for updates.

Brief overview

Two critical flaws in PHP core, CVE-2026–109618 and CVE-2026–109619, allow remote code execution and are both rated 9.2 on CVSS v4. Fixes shipped October 21, and exploitation in the wild has been reported. I'm writing this to raise awareness of PHP2Shell and its impact, from an incident response, security operations and security research perspective.

Timeline

  • October 17: Amazon Threat Intelligence reports the earliest observed exploitation attempt, four days before fixes shipped.
  • October 20: PHP pre-announces a release for October 21. A Hacker News post leaks the CVE IDs, CERT-EU urges teams to prepare, and watchTowr says it reproduced the first bug.
  • October 21: PHP moves the release up and publishes fixes at 14:00 UTC. watchTowr, which had reported seeing no exploitation earlier that day, reports active exploitation attempts. The Canadian Cyber Centre and Health-ISAC issue alerts.
  • October 22: Cloudflare says attack attempts have climbed into the millions, and SOCRadar reports finding lab-tested exploit tooling on an exposed attacker server.

Security research

None

Both bugs are in the interpreter itself, so patching application code or plugins does not help. CVE-2026–109618 is RCE from improper out-of-memory handling, and CVE-2026–109619 is RCE from stale internal state and a use-after-free. Both are memory-safety flaws in code that handles untrusted requests.

What I'd treat as established: the CVEs, the severity, and the official fixed versions. Exploitation in the wild is now reported by multiple vendors. watchTowr observed it in its honeypot network, Amazon reports attempts as early as October 17, and Cloudflare says attack attempts have surged. Researchers have also described working exploit chains, so treat this as an actively exploited flaw. It remains unclear how many attempts succeed, and as of October 22 neither flaw was in CISA's KEV catalog. Early rumors of a CVSS 10.0 rating and a reach back to PHP 5 don't match PHP's advisories, which rate both flaws 9.2 and fix only 8.2 through 8.5. Confirmed indicators of compromise remain limited. Amazon has published a short list of attacker source IPs, and vendors recommend hunting on behavior.

SecOps/Incident Response approach

None

Scope first. Any PHP serving web requests is in play: PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php highest, since a demonstrated exploit fires before application code runs. That also means application logs may show little, so lean on web server and process telemetry. Don't forget PHP bundled in containers and appliances.

Patch. Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, internet-facing mod_php hosts first. Verify with php -v, confirm which SAPI actually serves traffic, and restart services, because a routine package update may not change the running build. PHP 8.1 and older get no fix, so isolate and migrate them.

If you can't patch yet, take the system offline or put it behind network-layer authentication, and apply the interim mitigations in PHP's advisory as stopgaps only.

Hunt from October 17 onward, or further back if retention allows. Without published indicators, hunt behavior:

  • Web server or PHP worker processes spawning shells or download tools.
  • New or modified PHP files in web roots and upload directories.
  • Crash or out-of-memory spikes in PHP-FPM and web server logs. This is a heuristic, and quiet logs don't prove safety.
  • New outbound connections from the web tier, new accounts, SSH keys, cron jobs or services.

If you find something, capture memory, logs and a disk snapshot before patching or restarting, isolate the host, assume the attacker has the PHP user's privileges, rotate every secret that user could read, and rebuild from a known-good image instead of cleaning in place.

Takeaways

  • Know where your PHP runs, including inside containers and appliances.
  • Retire end-of-life runtimes before the next emergency.
  • One leak turned an orderly disclosure into a same-day scramble, and attack attempts reportedly began days before fixes existed, so keep your emergency patching path fast.
  • Grade your intel and date-stamp what you share. Early reports said no exploitation, then confirmed it within hours.

Sources