The second PHP core vulnerability fixed on 21 October 2026 is the one that is easier to overlook. CVE-2026-109619 involves internal request state that stays reachable after the memory backing it has been released, and the advisory treats it as a remote code execution flaw rated 9.2 under CVSS v4.0.

Overview

PHP published patches in 8.5.12, 8.4.27, 8.3.36 and 8.2.35 for both CVE-2026-109618 and CVE-2026-109619. Neither requires authentication. The two were announced together on 20 October 2026 and fixed the next day.

Stale state after teardown

The Cypriot CSIRT description states the problem plainly. Internal state belonging to a request can remain active even after the memory it depends on has been released, with a fatal error named as one way to reach that condition.

That ordering is the whole defect. Cleanup releases a structure, and something still points at it. When the engine later reads or writes through that pointer during the same request lifecycle, it is operating on memory that the allocator considers free and may already have reissued.

Fatal errors are a common event in production PHP. They occur when a script exhausts its allowed execution, when a required file fails to load, or when an uncaught exception reaches the top level. The advisory names the trigger class without publishing a proof of concept, so the precise sequence that turns a stale reference into controlled execution remains described only in general terms.

Exploitation conditions

An attacker needs a request that ends in the abnormal termination path, at a point where the attacker has influenced the contents of the memory that gets released. No credentials are involved. The parameters that matter are whether the target exposes code paths that produce fatal errors under remote input, and whether the freed memory can be reallocated with attacker-chosen content before the stale reference is used.

Applications that log and recover from fatal errors are not immune. The reference lives inside the request lifecycle, which continues through shutdown functions and output handling after a fatal error in many configurations.

Impact

The advisory classifies the outcome as remote code execution. Where exploitation is not achieved, the same condition produces crashes and worker restarts, which degrade availability under repeated triggering.

In a hosting context, code execution inside the interpreter reaches every secret the application can read, including database credentials, session keys and files in the application directory. The host boundary usually survives, but the data boundary does not.

Affected products and scope

Affected ranges match the sibling flaw: PHP 8.5 below 8.5.12, 8.4 below 8.4.27, 8.3 below 8.3.36 and 8.2 below 8.2.35. PHP 8.1 and earlier are end-of-life, and the project's ordinary update path does not reach them.

Because the defect lives in the interpreter's request lifecycle, the affected population is every deployment using an unpatched build, including applications that never call the parser involved in CVE-2026-109618. Teams that triaged only the memory-limit issue should recheck their inventory, because one interpreter upgrade resolves both and a partial response does not.

Exposure context

A recorded ZoomEye search for app="PHP" returned 94,382,282 assets. That number measures the interpreter's fingerprint footprint, not the number of exploitable deployments. It does establish that the patch window covers a large, mostly unmanaged population, since PHP rarely announces itself as a named product with a version string.

Remediation

Install the fixed release for the branch in use, or move off an end-of-life branch. Distribution and LTS vendors had the patches ahead of publication, and the PHP security team published minimal retrospective fixes for 7.4, 8.0 and 8.1 for organisations that build from source.

Beyond patching, the operational controls that reduce this class of risk are worth keeping. Isolate public-facing PHP applications from internal networks when the update cannot land immediately. Watch worker crash rates and 5xx spikes as a signal that abnormal termination paths are being exercised. Review whether error handling in custom code leaves references alive after a fatal error, since application-level cleanup that assumes a clean teardown compounds the interpreter 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

  • PHP release archive: https://www.php.net/archive/2026.php