Two critical PHP core vulnerabilities were fixed in the same patch set on 21 October 2026, and the national CERT advisories treat them as a pair. They share a severity rating and a fixed-version list, but the underlying defects are different, which matters when deciding how to respond.

The pair

CVE-2026-109618 is memory corruption during out-of-memory handling. CVE-2026-109619 is stale internal state that survives after the memory behind it has been released. Both permit unauthenticated remote code execution and both are rated 9.2 under CVSS v4.0.

Affected releases are PHP 8.5 before 8.5.12, 8.4 before 8.4.27, 8.3 before 8.3.36 and 8.2 before 8.2.35. The fixes arrived on 21 October, one day after the project's pre-announcement.

Two different failure modes

For CVE-2026-109618, the engine's memory_limit enforcement path is the problem. PHP uses longjmp() to abandon a request that exhausts its memory, and that jump can interrupt request construction while internal fields are only partly populated. The Cypriot CSIRT advisory describes cleanup code then mistaking uninitialised data for real state and releasing memory that was never allocated, which may still contain attacker-influenced content from earlier allocations.

For CVE-2026-109619, the defect is about lifetime rather than interruption. Internal state belonging to a request can stay active after the memory it depends on has been released. The advisory uses a fatal error as the example of how a request reaches that condition. Anything that later uses the surviving reference acts on freed memory that the allocator may have reissued.

The first defect needs memory pressure inside a specific window. The second needs the abnormal termination path plus a stale reference. An attacker facing one hardened condition may find the other cheaper.

Impact and conditions

Neither flaw requires credentials. Both yield code execution in the interpreter's security context, which in practice means access to application secrets and any internal service the host can reach.

Reachability is the practical filter. For the first flaw, a target must accept requests large enough to cross the memory ceiling. For the second, a target must expose code paths that end in fatal errors under remote input. Reverse proxies that reject oversized or malformed request bodies before PHP processes them reduce the first; nothing at the edge removes the second.

Affected scope

Both defects live in the interpreter, so the affected population is every deployment using an unpatched build, including software that bundles its own PHP. Advisories point to the NCSC-NL repository for a list of affected third-party products. PHP 8.1 and older get no ordinary project updates, though limited retrospective fixes were published for 7.4, 8.0 and 8.1 for organisations compiling from source.

Exposure context

A recorded ZoomEye search on app="PHP" returned 94,382,282 matching assets. The figure counts systems with a PHP fingerprint and does not resolve to patch level, so it should be read as the scale of the update exercise.

Remediation

One upgrade covers both issues, which is the simplest part of the response. Install 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then confirm the running service reports the new build. Distribution and LTS vendors had the patches in advance, so refreshing packages is usually faster than compiling.

Where the update cannot land immediately, restrict public reachability of PHP applications, cap request body size at the proxy, and watch worker crash rates. Repeated abnormal terminations on input-driven endpoints are the cheapest available signal that someone is testing either defect.

References

  • CSIRT.CY: https://csirt.cy/en/cve/2026/critical-vulnerabilities-in-the-php-core-engine

  • CERT.RS: https://cert.rs/rs/preporuka/1625-Kriti%C4%8Dne-ranjivosti-u-PHP-u-%28PHP2Shell%29.html