Back to blog
PHPRCEPHP-FPMmod_phpCVE-2026-109618

PHP2Shell: two unauthenticated RCEs in PHP (CVE-2026-109618 and 109619), and a third flaw with no patch

Published on 2026-10-22 · Updated on 2026-10-247 min readCleanIssue

> TL;DR: On October 21, 2026, the PHP project shipped emergency releases for two critical flaws nicknamed PHP2Shell. CVE-2026-109618 corrupts memory during out-of-memory (OOM) handling, and CVE-2026-109619 reuses freed state between requests. Both allow unauthenticated remote code execution with the web worker's privileges (CVSS v4: 9.2). Fixed versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On October 23, a third flaw, CVE-2026-115560, was published with no fix.

Who is affected

Any PHP installation serving web requests: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. According to Rapid7, the vendor considers mod_php the most exposed, because exploitation can succeed before any application code runs.

PHP 8.1 and older no longer receive routine updates. For this incident, PHP supplied limited source backports for 7.4, 8.0 and 8.1. If you run one of these branches, use your distribution's fix or upgrade.

How the two flaws work

  • CVE-2026-109618: crafted multipart requests (forms, uploads) can exhaust memory even while respecting configured limits. PHP then abandons the request with partly initialized data that cleanup reuses. Under mod_php, cleanup runs even when request startup fails, which enables the attack before application code.
  • CVE-2026-109619: a worker handling several requests can keep a pointer to memory freed at the end of a previous request. A fatal error (memory exhaustion, timeout) interrupts cleanup, and the next request reads the stale state. Session upload progress, enabled by default, acts as the trigger.
  • Where exploitation stands

    Several public proofs of concept exist. Rapid7 reviewed them: each works only on a specific combination of operating system, PHP version and web server, and none is broadly reliable. Exploitation attempts are reported. This difficulty is a window to patch, not a reason to wait.

    What to do now

  • Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's package containing both fixes. Restart every worker.
  • Until you patch, apply PHP's temporary measures at server level (not through ini_set()):
  • session.upload_progress.enabled=0 in php.ini or the FPM pool;
  • on PHP 8.5, fatal_error_backtraces=0;
  • bound request size upstream and block multipart on routes that do not need it.
  • CVE-2026-115560: no fix published as of October 23. A mitigation exists and, according to Rapid7, exploitation relies on a non-standard configuration. Watch PHP's announcements.
  • What this means for an AI agent

    Many agents call tools hosted on PHP backends: a WordPress plugin, a Laravel API, an in-house CRM. If that backend falls, the attacker controls what the tool returns to the agent, and therefore what the agent reads and does next. Patching the backend is part of the agent's security.

    The takeaway

    These flaws have existed in PHP since 2004. A mature technology is not an audited one. Inventory where PHP runs in your stack, including the tools nobody considers critical.

    Building software? CleanIssue performs security audits for your product in real-world conditions, no source code access needed. For a first read of your exposure, start with an external review of your application.

    Want to know what your AI agent can do?

    Tell us about your agent, its tools, and client context. We will come back with the right review scope.

    Discuss your audit