Patching CVE-2026-109618 across a fleet: where PHP actually hides in your inventory

The advisory for CVE-2026-109618 names four fixed versions and leaves the hard part to the reader. Working out which of your systems run an affected interpreter is a discovery problem, because PHP is usually present as a dependency rather than as a product anyone tracks.

Overview

CVE-2026-109618 is a critical PHP core vulnerability rated 9.2 under CVSS v4.0, fixed on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. It allows remote code execution without authentication. CVE-2026-109619 was fixed by the same release and carries the same rating.

How the defect works

PHP enforces the per-request memory_limit through longjmp(). When an allocation would exceed the configured ceiling, the engine jumps back to a recovery point instead of returning an error through the normal path.

The Cypriot CSIRT advisory explains why that matters. The abort can occur while the request's internal structures are only partially initialised, with form upload parsing given as the example. Cleanup code then runs against data that was never set up, treats it as valid, and releases memory this request never allocated. That memory can still hold content from earlier allocations, and an attacker able to shape those earlier allocations can influence the corrupted state.

Why inventory is the real work

The patched versions are simple to state. Finding the unpatched interpreters is not, because the same source tree gets redistributed in several forms.

Distribution packages. The advisory notes that Linux distributions and LTS providers received the fixes ahead of publication. A dnf or apt upgrade pulls the patched build, but only if the host is pointed at a repository that has published it, which is frequently not true of long-lived virtual machines.

Container images. The interpreter sits in the base layer. Rebuilding an application image does not always rebuild its base, and pinned digests keep the old interpreter running long after the tag has been updated.

Embedded copies. Appliances, network devices and packaged software frequently ship their own PHP build. These do not follow upstream release timing, and the advisory points to the NCSC-NL repository as the place to check which third-party products are affected.

Exploitation conditions

An attacker needs network reachability to a PHP execution path and the ability to drive memory allocation to the limit mid-request. A valid login is not required. Reverse proxies that reject oversized bodies before the request reaches the interpreter reduce exposure considerably, which makes the proxy configuration part of the true inventory.

Impact

Code execution runs in the web server account's context, giving access to application secrets, adjacent virtual hosts in shared environments, and internal services reachable from the host. Repeated triggering of the abort path also degrades availability.

Affected scope

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 are affected. PHP 8.1 and older are end-of-life; the security team published minimal retrospective fixes for 7.4, 8.0 and 8.1 for source-builders and organisations without an LTS provider.

Exposure context

A ZoomEye search for app="PHP" recorded 94,382,282 assets. PHP fingerprints are coarse, and the figure indicates the size of the population worth checking rather than the number of exposed hosts. Treat it as a reason to look, not a measurement of the problem.

Remediation checklist

Refresh distribution packages and confirm the running service reports the new version rather than only the on-disk binary. Rebuild container base images from patched layers and verify the image digest of what is actually running. Contact vendors for appliances that embed PHP and ask for their backport status. For end-of-life branches, either take the retrospective fixes published by the PHP security team or plan a migration.

While the rollout is incomplete, restrict public reachability of PHP applications, cap request body sizes at the edge, and watch for abnormal worker termination on upload endpoints. Those controls are temporary and do not remove the need for the interpreter update.