Post cover image
PHP2Shell: CVE-2026–109618 and CVE-2026–109619

October 23, 2026

PHP2Shell: Two Critical PHP Flaws (CVE-2026-109618 and CVE-2026-109619)

An overview of the two PHP runtime vulnerabilities, their potential impact, affected versions, and available fixes

By Aravind S

4 min read

On October 21, 2026, the PHP project released emergency security updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively called PHP2Shell. Both can allow unauthenticated remote code execution (RCE) with the privileges of the PHP worker.

The flaws are in PHP itself, not in a CMS, framework or plugin. That puts WordPress and Drupal sites, custom apps, containers, managed platforms and products that bundle PHP all in scope.

The story is still developing. The PHP advisories establish the bugs and the fixes. Exploitation and exposure details come from vendor reporting, which is not equally verified.

The bottom line

  • Severity: Both rated Critical, CVSS v4.0 9.2, per the PHP advisories.
  • Fixed releases: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
  • Highest risk: Internet-facing systems, especially Apache with mod_php. PHP-FPM, php-cgi and other integrations are also affected.
  • Exploitation: Amazon Threat Intelligence reports an attempt on October 17, four days before disclosure, and says exploitation is now broad. On the other hand, watchTowr said it had seen no successful attacks as of Oct 21.
  • The real fix: Upgrade, then restart workers. Config changes and WAF rules are stopgaps.
  • End-of-life branches: PHP 8.1 and older get no regular upstream releases.

Timeline

None
  • Aug 11: Calif and OpenAI independently report the out-of-memory RCE flaw to PHP, per the PHP Foundation.
  • Aug 19–24: Per Wiz, it independently found related flaws, confirmed unauthenticated RCE against WordPress and Drupal, and reported to PHP on Aug 24.
  • Sep 21: Per Wiz, PHP acknowledged the reports and began work on a fix.
  • Oct 17: Amazon's MadPot honeypots record an exploitation attempt from an anonymization-service IP.
  • Oct 20: The CVE IDs leak online ahead of the planned disclosure. PHP publishes an advance notice.
  • Oct 21, ~02:00 UTC: Amazon sees the earliest public proof-of-concept exploits, hours before the embargo lifts.
  • Oct 21, 14:00 UTC: PHP publishes the patched releases and advisories.

Amazon saw proof-of-concept exploits before the patch shipped. PHP's security team says it had not identified functional exploits at release time, while watchTowr says it reproduced both flaws. Assume working exploits exist.

What the two bugs do

Both are memory-safety problems in how PHP handles a request that fails midway, especially when it runs out of memory (OOM).

CVE-2026-109618: the half-built request. When memory runs out, PHP abruptly exits the current code path. If that happens before request data is fully set up, PHP's shutdown code later reads invalid memory.

With Apache mod_php, shutdown runs even when startup failed, and request-body parsing happens during startup. So the vulnerable sequence completes before your application code runs. PHP-FPM exits the worker on startup failure, which changes the path. The advisory says source analysis still supports FPM exposure, but no complete FPM exploit was demonstrated for this CVE.

None

CVE-2026-109619: the stale pointer. PHP workers are reused across requests. If one request leaves a dangling pointer behind, the next request on the same worker can trip over it before PHP resets it. That is a use-after-free, and it can become code execution.

The advisory confirms two cases: PHP 8.5's fatal-error backtrace feature, and session upload-progress handling, which is on by default and doesn't require session_start(). It also warns there is no complete generic config mitigation, because other request state may be reachable depending on your app and extensions.

Am I affected?

Treat any web-serving PHP install on a pre-fix version as exposed until you verify otherwise.

Fixed versions

  • PHP 8.5 → 8.5.12
  • PHP 8.4 → 8.4.27
  • PHP 8.3 → 8.3.36
  • PHP 8.2 → 8.2.35

Wiz and Calif report versions back to PHP 5.4 are affected. PHP published source-only backports for 7.4, 8.0 and 8.1. These are not regular releases, and PHP 7.3 and older get no fix from PHP. Unless your distribution or vendor supports a patched build, plan to migrate. Also, PHP 8.2 itself reaches end of life on Dec 31, 2026.

Look beyond what you installed yourself:

  • Container images, Kubernetes workloads and CI runners
  • Managed PHP runtimes and serverless functions
  • Hosting control panels, vendor appliances and products that bundle PHP
  • Long-lived worker pools, where a package update doesn't replace running processes

Remediation

The priority is to upgrade to a fixed release and confirm the patched runtime is the one actually running.

None
  1. Inventory: Identify every PHP installation, starting with internet-facing systems.
  2. Upgrade: Move to 8.2.35, 8.3.36, 8.4.27 or 8.5.12.
  3. Restart and verify: Restart workers or redeploy containers, then confirm the running version.
  4. Interim controls: If patching is delayed, restrict multipart requests, disable session upload progress where appropriate, and apply WAF rules. These reduce exposure but are not a fix. The PHP advisories list the specific settings. Consider isolating exposed systems that cannot be patched.
  5. Check for compromise: Review activity from at least October 17 onward. Patching does not remove a backdoor that is already in place.

The AI angle

Wiz credits frontier AI models with a major role in finding the flaws and building exploits. It says one researcher did in about a week what might have taken a top team months. Amazon makes a related point: AI-assisted analysis shortens the path from patch diff to working exploit, which strains 7- or 30-day patch windows for critical internet-facing bugs. Treat both as informed assessments, not measured facts. The operational lesson stands either way: plan for a compressed window between disclosure and exploitation.

The takeaway

PHP2Shell is a runtime-level issue, not a one-platform problem. Patch every PHP runtime, restart what uses it, verify the result, and don't count on application-level defenses or clean app logs as proof of safety.

This summary reflects public advisories and vendor reporting as of October 22, 2026. Check the primary advisories and your PHP vendor's guidance before making remediation decisions.

Sources

PHP advisories

Threat intelligence and government guidance

Research and coverage

That's it for this post. Stay tuned for more!