Critical PHP RCE Vulnerabilities: CVE-2026-109618 & CVE-2026-109619 Explained

On October 21, 2026, the PHP project disclosed two critical vulnerabilities in the language's core interpreter: CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS base score of 9.8 (v3.1) — 9.2 under CVSS v4.0 — and both allow remote code execution without authentication. Given that PHP still powers a large share of the web, these are the kind of flaws that warrant same-week attention from any team running PHP in production.

This post breaks down what each vulnerability actually does, why the blast radius is so large, who is exposed, and how to respond.

What the two vulnerabilities are

Both bugs are memory-corruption flaws in how PHP handles request memory — the kind of low-level issue that turns a crash into attacker-controlled code execution. They share the same weakness classes: use-after-free (CWE-416), improper handling of exceptional conditions (CWE-755), and access of an uninitialized pointer (CWE-824).

CVE-2026-109618 — uninitialized memory on out-of-memory

PHP handles an out-of-memory (OOM) condition by using longjmp() to jump straight out of the current context and abort the request, skipping the normal unwinding. The problem is that some code paths do not account for that early exit. They leave request memory in a half-initialized state, and the cleanup routine that runs next reads — or makes control-flow decisions on — those uninitialized bytes.

Crucially, an attacker can trigger the OOM condition on demand, and there are multiple reliable strategies to do so from an ordinary request. By steering what ends up in that memory, an attacker can consistently turn the resulting corruption into remote code execution.

CVE-2026-109619 — stale global state into freed request memory

PHP keeps a handful of global pointers that, during a request, point into memory owned by that request. Normally those are reset when the request ends. In the vulnerable paths, they either are not reset cleanly or get repopulated after the reset — so a global ends up referencing request memory that has already been freed.

A subsequent request can then read or branch on that stale pointer before it is properly re-initialized. This is a textbook use-after-free, and like its sibling it can be shaped across requests into remote code execution without any credentials.

Why the blast radius is so large

Most high-profile vulnerabilities live in a single plugin, library or application. These two are different: they live in the runtime every PHP site shares. A memory-corruption bug in the core interpreter is not contained to one app's code — it is a property of the engine underneath all of them.

That matters because of where PHP sits. It is still one of the most widely deployed server-side languages on the internet, and it usually runs on hosts that are directly reachable from untrusted networks. When the vulnerable component is the interpreter itself and the exposure is internet-facing, the population of affected systems is enormous.

CVE-2026-109619 adds a second wrinkle: cross-request state. The damage does not stay in the request that caused it — a malicious request can poison state that a later, innocent request trips over. That makes the issue harder to reproduce in testing and easier to miss in logs.

Who is affected

If you run PHP anywhere that accepts input from untrusted sources, assume you are in scope until you have confirmed your version is patched. In practice that includes:

• WordPress, Drupal, Magento, Joomla and other PHP CMS platforms — the vulnerability is in the engine they all run on, independent of plugins or themes. If you run WordPress, see our companion guide on WordPress security.
• PHP frameworks and custom applications — Laravel, Symfony and bespoke code are equally exposed.
• Internet-facing PHP APIs and admin panels — anything that parses untrusted request data.

The affected component is the PHP interpreter, so the deciding factor is the PHP version you run, not the application framed on top of it.

How to respond

1. Inventory where PHP actually runs. You cannot patch what you cannot see. Find every host, container and managed service running PHP, and record the exact version of each.
2. Upgrade to the patched PHP release. This is the only complete fix for both CVEs. Prioritize internet-facing hosts and anything processing untrusted input first.
3. Harden where you cannot patch immediately. For CVE-2026-109618, capping per-request memory and concurrency makes the OOM condition harder to drive on demand. These are interim measures that reduce exploitability — they do not replace the upgrade, and no configuration workaround fully closes a use-after-free.
4. Reduce exposure. Put PHP front-ends behind strict input validation, restrict who can reach admin surfaces, and keep untrusted traffic away from hosts that cannot yet be patched.
5. Verify after patching. Confirm the running interpreter version on every host post-upgrade — not just the package manifest — so a missed restart or a stale container image does not leave you exposed.

How Rainforest helps

The hardest part of a core-runtime CVE is rarely the patch itself — it is knowing where the vulnerable runtime actually reaches you across a sprawling estate. Rainforest's platform continuously inventories your stack and correlates it against vulnerability intelligence, so when a flaw like CVE-2026-109618 or CVE-2026-109619 lands, you can see which hosts and applications run an affected PHP version and prioritize the ones that are genuinely reachable — instead of guessing. If you build on PHP, our guide on developing safer applications with PHP is a good next step, or book a demo to see how Rainforest maps critical CVEs to your environment.