CVE-2026-109618 & CVE-2026-109619 (PHP2Shell) Explained

What CVE-2026-109618 and CVE-2026-109619 are

CVE-2026-109618 and CVE-2026-109619 are two vulnerabilities in the PHP runtime — the program that reads and runs PHP code every time a visitor loads a page on a PHP website. Together they are nicknamed PHP2Shell. They are not bugs in WordPress, a plugin or a theme; they sit one layer below all of that, which is why this guide treats them on their own. For the WordPress-owner walkthrough — checking, patching and cleanup — start with our PHP2Shell and WordPress guide.

Both bugs share a shape: PHP loses track of its own memory at the wrong moment while handling a web request, and an attacker who shapes a request carefully can turn that confusion into remote code execution — running their own commands on your server — without logging in. This explainer stays at the conceptual level. It deliberately contains no exploit code, proof-of-concept or reproduction steps; the aim is to help you understand and prioritise the fix, not to reproduce the attack.

CVE IDs

CVE-2026-109618 · CVE-2026-109619

Nickname

PHP2Shell

Severity

Critical · CVSS v4.0 9.2

Login needed?

No (unauthenticated)

Fixed in

8.5.12 · 8.4.27 · 8.3.36 · 8.2.35

Released

21 October 2026

CVE-2026-109618: RCE via out-of-memory corruption

The PHP project’s own title for CVE-2026-109618 (advisory GHSA-w8hw-w9fx-j79w) is “RCE via OOM corruption”. “OOM” means out-of-memory.

Conceptually: when PHP begins handling a request it sets up a set of internal structures to hold the request’s data. If PHP hits an out-of-memory condition midway through that setup, the request is left only partly initialised. The problem is what happens next: the clean-up code that tears the request down treats that half-finished data as if it were valid and complete. Acting on data that was never properly formed is where the memory corruption comes from, and with careful shaping it can be steered toward code execution.

The practical sting is that the out-of-memory condition can be induced by an attacker’s request rather than waited for — which is why the mod_php attack path described below needs nothing from your application at all.

CVE-2026-109619: RCE via stale global state

The PHP project titles CVE-2026-109619 (advisory GHSA-6wmf-4rv5-p3rp) “RCE via stale global state”. This is a classic use-after-free in slow motion.

A PHP worker process handles one request, then another, then another. Some internal state belongs to a single request and should be cleared when that request ends. In this bug, a piece of that request-owned state outlives the memory it refers to: the memory is freed, but a pointer to it survives into the next request handled by the same worker. When that later request reuses the stale pointer, it is reading or writing memory that now means something else — so it needs two requests on the same worker to line up.

Beyond code execution, researchers demonstrated that this stale state can be used to disclose chunks of the worker’s memory to an unauthenticated attacker. That memory can contain whatever the worker touched recently: passwords, session tokens, API keys. That is why, if your site was exposed and unpatched, the advice is to rotate secrets — a leaked credential keeps working after you patch.

How bad is it? Severity, memory disclosure and SAPIs

The PHP project rates both bugs at CVSS v4.0 9.2 (Critical), with the vector AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H. In plain terms: reachable over the network, needs no privileges and no user interaction, and has high impact to confidentiality, integrity and availability. (Secondary trackers quoted other numbers — CVSS 3.x scores of 9.8 and 8.1, and one firm rated it 10.0 — but the PHP project’s 9.2 is the figure we use.)

The one part of the vector that sounds reassuring is AC:H/AT:P — “high attack complexity, attack requirements present.” That reflects reality: reliable exploitation depends on how memory happens to be laid out, how PHP was built, and which worker handles which request. But high complexity is not safety. It slows an attacker down rather than stopping them, and the usual response is to send a great many attempts and wait for the odds to line up.

Which server setup you run changes your exposure. All PHP installations that serve web requests are affected, but not equally:

Affected and fixed versions

Every PHP release before the fixed versions is affected. The lower bound is uncertain — it is believed to reach back to PHP 5.4 (2012), though not every old release was tested. The fixes shipped on 21 October 2026.

Not sure whether your branch is still supported at all? Pick it below.

Timeline and disclosure

The disclosure didn’t go to plan: details leaked a day before the coordinated release, and attack attempts started even earlier.

1. Aug 2026

   Bugs reported to PHP

   Researchers from Wiz, Calif, OpenAI and Quarkslab report the issues. The PHP security team receives the reports from 11 August and begins a coordinated fix with Linux distributions.

2. 17 Oct 2026

   First attempt seen

   Amazon's threat intelligence team records an exploitation attempt against its sensors while the bugs are still under embargo — four days before any patch exists.

3. 20 Oct 2026

   Details leak; emergency release announced

   Information spreads publicly ahead of the plan (a Hacker News thread, a watchTowr post, and a proof-of-concept video released by mistake). PHP pre-announces a critical release for 14:00 UTC the next day.

4. 21 Oct 2026

   Fixes released

   PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 ship (advisories published 13:34 UTC), plus source backports for 7.4, 8.0 and 8.1. Distributions and control panels publish patched packages over the following hours.

5. 21–22 Oct 2026

   Mass scanning

   Cloudflare reports attempts climbing from thousands to millions after the announcement and deploys firewall rules. Managed WordPress hosts roll out patched PHP.

6. 24 Oct 2026

   Where things stand

   Exploitation attempts are widely reported; no successful compromise has been publicly confirmed, and neither CVE is in CISA's KEV catalog.

Is it being exploited? CISA KEV status

This is where reports conflict, so it’s worth being precise about what is and isn’t known as of 24 October 2026.

• Attempts: yes. Amazon logged an attempt on 17 October, before the patch. Cloudflare reported attempts rising from thousands to millions around disclosure. watchTowr observed scanning and attempts via honeypots from 21 October.
• Some CERTs say “exploited in the wild.” HKCERT wrote on 22 October that both CVEs are being exploited; NCSC-NL said it was investigating first signs of successful misuse.
• Confirmed successful compromise: none published. In the sources reviewed up to 24 October, no successful breach had been publicly confirmed. watchTowr said circulating proof-of-concepts it saw did not achieve code execution, and VulnCheck reported at least one failed web-shell attempt. Fake and prank “PoCs” also circulated on GitHub.

The honest summary: heavily probed, not yet proven to have produced a public breach, and squarely worth patching now rather than waiting for KEV to catch up.

What a WordPress owner should do

You don’t need to understand allocator internals to act. The fix is the same regardless of mechanism: get a patched PHP build and restart PHP. Answer three questions and the checker below tells you where you stand — it runs entirely in your browser.

1. Find your PHP version in Tools › Site Health › Info › Server (it also shows your SAPI).
2. Compare it with the fixed releases above. If you’re on managed or shared hosting, ask your host to confirm both CVEs are patched; if you run the server, follow how to check and update your PHP version.
3. After updating, restart PHP-FPM / Apache / LiteSpeed — the old code stays in memory until workers restart — then re-check Site Health. If you were exposed and unpatched, rotate your secrets because of the 109619 memory-disclosure risk.

For the full checking, patching and “was I hacked?” workflow, see the main PHP2Shell and WordPress guide and our WordPress security guide.

If a stack with no PHP to patch sounds appealing, check your site with the migration tool. It only reads your public pages and lists what would move over; it never changes anything on your current host.