Two critical remote code execution flaws in the PHP engine itself, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, leaked publicly on October 20 before the planned coordinated disclosure. PHP responded with emergency releases on October 21. Both are scored CVSS v4.0 9.2. watchTowr and Cloudflare report exploit attempts in the wild, though no source has yet confirmed a successful compromise of a named victim.

What Happened

The embargo for the October 21 PHP security release broke early, and details of both bugs circulated before patches were available. watchTowr said it reproduced CVE-2026-109618 and confirmed the leak was genuine, without publishing technical detail. Cloudflare reported attack traffic and attackers rotating payloads to evade its WAF rules. Early claims of a CVSS 10.0 score were wrong; the official rating is 9.2.

These are bugs in the runtime, not in a framework or plugin. Every PHP application on an unpatched interpreter is in scope, regardless of what code it runs.

Technical Details

CVE-2026-109618 — out-of-memory corruption. Per PHP’s analysis as reported by JFrog, the out-of-memory handling path can abandon a request while its memory is only partly initialized, and request shutdown then treats that state as valid. Sansec describes the reachable primitive as a use-after-free in the upload-progress unserializer, which can also leak heap contents on its own.

CVE-2026-109619 — stale state between requests. A long-lived worker can reuse state left over from an earlier request. Researchers place the issue in fatal-error backtrace handling and OPcache type confusion. PHP validated a session-path variant against PHP-FPM with a normal dynamic pool.

Exposure by SAPI:

  • Apache mod_php is the highest-risk configuration. PHP confirmed full RCE over HTTP with default limits, triggering before any application code executes.
  • PHP-FPM is affected and was validated for CVE-2026-109619.
  • FrankenPHP, php-cgi and LiteSpeed are listed as at risk with varying likelihood.

Some reports say the bugs reach back as far as PHP 5; PHP’s own notice does not confirm the full range, so treat any unsupported branch as vulnerable and unpatchable.

Impact

Unauthenticated, network-reachable code execution as the web server user on any host running a vulnerable interpreter. That includes shared hosting, WordPress and Magento fleets, internal admin panels and containerized PHP images pinned to old tags. Because the trigger fires in the engine, WAF rules and application hardening are weak defenses. Expect rapid mass scanning now that the details are public.

Mitigation

  1. Upgrade now to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Updating is the only complete fix.
  2. Distro packages: AlmaLinux has published patched packages; check your vendor’s tracker (Debian, Ubuntu, RHEL, Alpine) and rebuild container images against the fixed packages. Rebuilding is not optional: a running container keeps its old interpreter.
  3. Restart after patching. Apache with mod_php, PHP-FPM pools and FrankenPHP workers keep the old code in memory until restarted.
  4. Stopgap if you cannot patch immediately. Sansec suggests setting session.upload_progress.enabled = 0 in php.ini and restarting. They also suggest a memory_limit change; that value is unusual, so verify it against PHP’s advisory before relying on it.
  5. Prefer PHP-FPM over mod_php where you have a choice, to put a process boundary between the web server and the interpreter.
  6. Hunt. Look for new or modified .php files in web roots and upload directories, unexpected child processes of httpd/php-fpm, and outbound connections from web workers. Review logs from October 20 onward for anomalous multipart or upload-progress requests.

References