CVE-2026-109618 & 109619: the PHP bugs you can't code your way out of

Two bugs, one patch

The 22 October 2026 PHP release (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12) fixes two separate, critical memory-corruption flaws in the interpreter. Both reach unauthenticated remote code execution as the web-worker account. NVD scores each 9.8 (CVSS 3.1); PHP's own CNA scores them 9.2 (CVSS 4.0). The two systems disagree on one axis worth noting — NVD rates attack complexity Low, PHP rates it High — which matches the picture below: network-reachable and unauthenticated, but not yet push-button reliable. The 109619 advisory says to follow 109618's remediation as well, and vice versa, because an attack on one tends to touch the other.

The official php.net changelog confirms the shared fix: each release carries one Core entry, "Fixed GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp (Avoid state corruption via bailout)." The changelog cites the advisory IDs rather than the CVE numbers; the CVE IDs and scores below come from the advisories themselves.

109619: stale global state

Persistent SAPIs (mod_php, PHP-FPM) reuse worker processes across requests. Some engine-global state (error, session, object and extension bookkeeping) can still point into the previous request's heap after that request has ended and its memory has been released. If the stale state is touched before request initialisation resets it, the worker dereferences freed memory. That causes memory disclosure at best, and code execution at worst.

109618: OOM corruption

PHP uses longjmp() to abandon a request when it runs out of memory. In some code paths request memory is reachable before its setup finishes; if an allocation fails there, the jump leaves that memory half-built, and request shutdown then reads or branches on it. The demonstrated trigger is forcing an out-of-memory condition during input processing. The full RCE was validated against Apache mod_php, which the advisory notes "unconditionally invokes the request shutdown procedure" even when startup failed; PHP-FPM, FrankenPHP and LSAPI are assessed as likely susceptible but were not demonstrated.

Because both bugs are in the engine, application code is irrelevant to exposure. Exposure depends on the PHP build plus the reachable trigger features, which is why the lab has no "vulnerable app". It runs an unpatched engine with the trigger settings on.

Affected and fixed versions (both CVEs)

Reachable trigger paths

Detection in four layers

There's no fixed exploit byte signature for a memory-corruption race, so these detections focus on exposure (what can be hit), preconditions (what an attacker must do to set it up) and side effects (what a failing exploit leaves behind).

Layer 1: Fleet exposure scanner

scan_fleet.py is a Python 3 script with only standard-library dependencies. It reads the PHP version from X-Powered-By, falls back to Server and then the HTML body, and classifies each host as AFFECTED, EOL, PATCHED or UNKNOWN. Exit codes are designed for CI or a scheduled job.

$ python3 scan_fleet.py -f hosts.txt --csv before.csv
TARGET                  PHP       VERDICT
----------------------------------------------
http://127.0.0.1:8080   8.4.26    ❌ AFFECTED  (fixed in 8.4.27)
http://127.0.0.1:8085   8.5.11    ❌ AFFECTED  (fixed in 8.5.12)

Summary: 2 affected/EOL, 0 errors, 0 patched.     # exit 1

# ...after upgrading both containers...
http://127.0.0.1:8080   8.4.27    ✅ PATCHED  (fixed in 8.4.27)
http://127.0.0.1:8085   8.5.12    ✅ PATCHED  (fixed in 8.5.12)
Summary: 0 affected/EOL, 0 errors, 2 patched.     # exit 0

Layer 2: Host posture check

check_mitigations.sh runs on the PHP host and reads the live version and INI settings from php itself. It reports the 109619 toggles (session.upload_progress.enabled, fatal_error_backtraces) and the 109618 surface (memory_limit, post_max_size, and the input/nesting/upload caps), and warns against capping memory with RLIMIT_AS/RLIMIT_DATA — which itself triggers 109618.

The exit code tracks the patch status plus the 109619 toggles, which are clean on/off settings. 109618 has no single safe value, so its settings are advisory and don't change the code.

Layer 3: Network rules (Suricata)

php2shell.rules holds eight heuristic rules in the local SID range 1026001–1026008: one for 109619, five for 109618's input-amplification paths, a crude oversized-body rule, and a shared crash signal. Treat them as tunable starting points, not turnkey IOCs. SID 1026003 in particular will fire on any noisy app until you baseline it.

The 109618 rules target the advisory's real trigger: input that is small on the wire but expensive for PHP to decode. An attack can stay well under any byte-size threshold, so a size rule alone (1026002) misses it; these catch the shape instead.

alert http any any -> $HOME_NET any ( \
    msg:"PHP2SHELL CVE-2026-109619 upload_progress field burst (possible UAF grooming)"; \
    flow:to_server,established; http.method; content:"POST"; \
    http.request_body; content:"PHP_SESSION_UPLOAD_PROGRESS"; nocase; \
    threshold:type both, track by_src, count 30, seconds 10; \
    classtype:attempted-admin; sid:1026001; rev:2; )

# 109618: multipart part carrying an abnormal number of headers
alert http any any -> $HOME_NET any ( \
    msg:"PHP2SHELL CVE-2026-109618 multipart part header flood"; \
    flow:to_server,established; http.method; content:"POST"; \
    http.content_type; content:"multipart/form-data"; nocase; \
    http.request_body; content:"Content-Disposition"; nocase; \
    pcre:"/(?:\r\n[A-Za-z0-9-]{1,64}:[^\r\n]{0,256}){50}/"; \
    threshold:type limit, track by_src, count 1, seconds 60; \
    classtype:attempted-admin; sid:1026005; rev:1; )

# Shared crash signal (both CVEs)
alert http $HOME_NET any -> any any ( \
    msg:"PHP2SHELL possible exploitation side effect: HTTP 500 burst from PHP host"; \
    flow:to_client,established; http.stat_code; content:"500"; \
    threshold:type both, track by_dst, count 20, seconds 10; \
    classtype:web-application-attack; sid:1026003; rev:2; )

The full eight-rule set is in php2shell.rules. On an internet-facing sensor, scope the inbound rules to $EXTERNAL_NET any -> $HOME_NET.

Layer 4: Log and SIEM detections

Network rules show attempts. Logs show consequences. A healthy PHP fleet almost never segfaults a worker, so a spike in segfaults is the strongest single indicator. Full query set: log_detections.md.

# mod_php (Apache error_log)
grep -E "child pid [0-9]+ exit signal Segmentation fault \(11\)" /var/log/apache2/error.log

# PHP-FPM
grep -E "child [0-9]+ (exited on signal 11|SIGSEGV)" /var/log/php*-fpm.log

# Splunk-style: segfaults per host per minute
index=web ("exit signal Segmentation fault" OR "exited on signal 11")
| bin _time span=1m | stats count by host, _time
| where count > 3

How we validated it

Every artifact on this page was run, not just written. All testing took place in an isolated Docker lab bound to 127.0.0.1 on an internal network.

The raw output

Not a slide that says "Pass" — the actual console output from those runs.

Fleet scanner — the same command before and after the patch, against the live lab:

$ python3 scan_fleet.py http://127.0.0.1:8080 http://127.0.0.1:8085
http://127.0.0.1:8080   8.4.26    ❌ AFFECTED  (fixed in 8.4.27)
http://127.0.0.1:8085   8.5.11    ❌ AFFECTED  (fixed in 8.5.12)
Summary: 2 affected/EOL, 0 errors, 0 patched.          → exit 1

# ...after upgrading both hosts to the fixed builds...
http://127.0.0.1:8080   8.4.27    ✅ PATCHED  (fixed in 8.4.27)
http://127.0.0.1:8085   8.5.12    ✅ PATCHED  (fixed in 8.5.12)
Summary: 0 affected/EOL, 0 errors, 2 patched.          → exit 0

Suricata — all eight rules on a 103 MB capture of real mod_php traffic (0 packets dropped by the kernel):

$ suricata -r lab-real.pcap -S php2shell.rules \
    --set vars.address-groups.HOME_NET=[172.16.0.0/12]
  1  [1:1026001]  CVE-2026-109619  upload_progress field burst
  1  [1:1026002]  CVE-2026-109618  repeated oversized POST (crude OOM)
  1  [1:1026004]  CVE-2026-109618  chunked multipart
  1  [1:1026005]  CVE-2026-109618  multipart part header flood
  1  [1:1026006]  CVE-2026-109618  multipart empty file-control flood
  1  [1:1026007]  CVE-2026-109618  deeply nested multipart field name
  1  [1:1026008]  CVE-2026-109618  deeply nested urlencoded field name
  1  [1:1026003]  (both)           HTTP 500 burst — real mod_php 500s
→ 8 / 8 rules fired, once each.   Benign control requests: 0 alerts.

Host posture check — run inside the live 8.5.11 container:

$ docker exec php2shell-85 bash check_mitigations.sh
CVE-2026-109618 / 109619 mitigation check
  PHP version : 8.5.11
  Fixed in    : 8.5.12  ->  AFFECTED ❌
  session.upload_progress.enabled : On
  fatal_error_backtraces          : On
  memory_limit : 128M   post_max_size : 8M   max_input_nesting_level : 64
→ exit 1

All of this reproduces from the repo: docker compose up, then the three commands above.

Remediation

1. Upgrade to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or later). This single update fixes both CVEs and is the only complete fix.
2. If you can't patch yet (109619), set session.upload_progress.enabled=0, and on 8.5 also set fatal_error_backtraces=0. Then restart every worker: the settings only apply to new workers.
3. If you can't patch yet (109618), the advisory's primary (still incomplete) config mitigation is memory_limit=-1; also keep post_max_size tight and cap max_input_vars, max_input_nesting_level and max_file_uploads. Do not cap process memory with RLIMIT_AS/RLIMIT_DATA — that makes allocations fail and triggers the very bug.
4. Verify: check_mitigations.sh should exit 0 on each host, the fleet scan should exit 0, and segfault counts should return to baseline. All interim steps reduce exposure but don't remove it.
5. Retire PHP ≤ 8.1. There is no full upstream fix for those branches.

Scope and limitations

• No exploit is published here, on purpose. The lab demonstrates exposure and patch verification, which is the deliverable defenders need.
• The network rules are heuristics. They catch setup patterns and side effects, not the corruption itself. Tune thresholds to your traffic.
• Version fingerprinting can't see hosts with expose_php=Off, and some vendors backport fixes without changing the version string. Confirm with the vendor's package changelog.
• The 109618 rules are tuned to Suricata 7's PCRE step limit; widening their repetition bounds can make them silently stop matching, so retest after any change (the rule file notes where).
• Version and advisory data come from the two php-src advisories (109619, 109618) and were cross-checked against the php.net changelog (22 Oct 2026 releases). Re-check php.net for any later point releases before acting on it.
• CVSS scores are as published: NVD's CVSS 3.1 9.8 is the primary score (109618, 109619); PHP's CVSS 4.0 9.2 is the secondary score from its advisories.

Downloads