Detecting exploitation attempts against CVE-2026-109618 without a public exploit
The PHP advisories published on 21 October 2026 do not include a proof of concept. That makes detection harder than it would be with published exploit code, and it makes the choice of indicators more important than usual.
What is known
CVE-2026-109618 is a critical PHP core vulnerability rated 9.2 under CVSS v4.0, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. It permits unauthenticated remote code execution. CVE-2026-109619, fixed in the same release, carries the same rating. Both were announced on 20 October 2026 and patched the next day.
The behaviour worth watching
The Cypriot CSIRT advisory describes CVE-2026-109618 as memory corruption triggered when the memory_limit abort fires during request construction. PHP abandons the request through longjmp(), cleanup then processes uninitialised fields, and memory previously holding attacker-influenced content may be released and reused.
That gives defenders something concrete to reason about even without a signature. Reaching the vulnerable state requires a request that drives allocation past the configured ceiling while the interpreter is still assembling request data. In practice that means large or malformed request bodies aimed at endpoints that parse them.
What follows the trigger is less predictable, because the outcome depends on allocator behaviour. The advisory's stated consequence is code execution, but a failed attempt is more likely to look like a crash.
Indicators that do not depend on a signature
Watch worker termination rates on endpoints that accept uploads or large bodies. A spike in segfaults or abrupt process exits, especially on a single endpoint, lines up with attempts to reach the abort path.
Watch repeated 5xx responses where the request body is unusually large or the multipart structure is malformed. Normal user traffic rarely produces a stream of oversized multipart requests to the same handler.
Watch the process model. PHP-FPM respawning workers in a tight loop is a capacity problem and a signal at the same time. Correlate that with request logs rather than treating it as infrastructure noise.
Watch for outbound connections from the web server that the application does not normally make. Code execution in the interpreter's context has to reach an attacker-controlled endpoint eventually, and that is the step least able to hide behind normal traffic.
Why the absence of a PoC does not mean quiet
A vulnerability of this severity with no public exploit tends to attract research before it attracts mass scanning. Quiet attempts against a small number of targets are the expected pattern, and they produce few requests. Log retention and body capture matter more than alert tuning in that phase, because the evidence of interest is a handful of unusual requests rather than a volume spike.
Impact and affected scope
Successful exploitation yields code execution as the web server user, exposing application configuration, credentials and any internal service reachable from the host. 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, with 8.1 and older out of support.
Exposure context
ZoomEye recorded 94,382,282 matches for app="PHP" during this analysis. Fingerprint matches do not resolve to patch level, so the figure describes how much work remains in verifying versions, not how many hosts are exploitable.
Remediation remains the primary control
Upgrade to a fixed build and confirm the running service reports it. Cap request body size at the reverse proxy so oversized payloads never reach the interpreter, which removes most of the reachable trigger path for the sibling defect. Isolate internet-facing PHP applications from internal networks while the rollout is in progress. Check embedded PHP copies in appliances against the NCSC-NL repository referenced by the advisories.
Top comments (0)