Exploit for Improperly Controlled Sequential Memory Allocation in Php

A reproducible lab for answering one question a legacy PHP app: **am I exposed to the October 2026 PHP critical release (CVE-2026-109618 / CVE-2026-109619), and will a given mitigation hold without breaking my app?**

Three framework stacks, each pinned to PHP 7.4 (end-of-life Nov 2022, no official fix for this release), **each runnable on both web-server paths**, because exposure and mitigation depend on the SAPI as much as on the version:

| Framework | Apache + mod_php | nginx + php-fpm |

| CodeIgniter 3.1.13 | | |

| Laravel 6 | | |

| Fat-Free 3.7 | | |

- **mod_php** runs PHP in-process inside Apache. Mitigations: Apache directives, `php.ini`, module disable.

- **php-fpm** runs PHP as a separate FastCGI pool behind nginx (or Apache `mod_proxy_fcgi`). Mitigations differ: pool config, the nginx/Apache FastCGI rewrite rules (themselves a historic RCE surface, see CVE-2019-11043), and where a WAF sits.

A third real-world path, **Apache + php-fpm via `mod_proxy_fcgi`**, is documented as a variant on the `mitigate/*` branches rather than run by default, to keep the default `up` small.

docker compose --profile apache up # all three mod_php stacks (8081-8083)

docker compose --profile nginx up # all three nginx+fpm stacks (8091-8093)

docker compose --profile ci3 up # both paths for CodeIgniter 3

docker compose --profile all up # everything

All services bind to `127.0.0.1` only. This is a controlled target; never expose it.

inventory/inventory.sh ci3-apache # inside the mod_php container

inventory/inventory.sh ci3-fpm # inside the php-fpm container

inventory/inventory.sh 127.0.0.1:8091 # over HTTP (server + SAPI inference)

for p in 8081 8082 8083 8091 8092 8093; do inventory/inventory.sh 127.0.0.1:$p; echo; done

It reports PHP version, the **serving SAPI** (apache2handler vs fpm-fcgi, not the CLI), loaded extensions, and whether the branch is EOL. Detection only.

- No working exploit code for the CVEs, in any branch, ever. For a critical RCE with no PHP 7 patch, a public PoC across the common frameworks is a mass-targeting tool. Reachability confirmation against a real app is a private, offline assessment, not this repo.

- The exploit mechanism is not published here even after details are out (Oct 21, 2026, 14:00 UTC). This repo is detection, mitigation testing, and port rehearsal.

docker-compose.yml profiles per framework and per server

apps//Dockerfile.fpm php-fpm build (app baked to /opt/app)

fpm-entrypoint.sh syncs app into the shared docroot volume nginx mounts

nginx/.conf FastCGI vhost per framework

inventory/inventory.sh version + serving-SAPI + extension + reachability

docs/mitigation-decision.md decision table, mitigations split by SAPI

demos/ runnable mitigation demos (see below)

`demos/` is a small, self-contained stack (plain PHP on the same PHP 7.4 / php-fpm

runtime as the Laravel 6 app, behind an OpenResty edge, with Redis) that

demonstrates the three mitigations from the blog post, all of which live outside

MODE=mitigated docker compose -f docker-compose.demo.yml --profile demo up --build -d

./01-multipart-block.sh # §1 edge blocks multipart except on /upload (415 vs 200)

./02-upload-rate-limit.sh # §4 Redis in-flight budget sheds a flood with 429

./03-oom-above-fpm.sh # §3 cgroup OOM-kills a hungry worker; FPM respawns it

MODE=baseline docker compose -f docker-compose.demo.yml --profile demo up -d # before/after

Same charter as the rest of the repo: these demonstrate mitigations, not the

vulnerability. The §3 demo uses an ordinary allocation loop to show the cgroup

reaping a worker, not any corruption. See `demos/README.md`.

A fourth demo (series part 2, *"Put your unpatchable PHP in a box"*) is a separate

stack that isolates a legacy PHP 7.4 CLI worker behind a patched 8.3 front, so the

vulnerable parse never runs on the old interpreter:

docker compose -f docker-compose.cli-isolation.yml --profile cli up --build -d

./04-cli-isolation.sh # multipart upload hits the 8.3 front; legacy runs as cli

docker compose -f docker-compose.cli-isolation.yml --profile cli down -v

- `main` — six stacks (3 frameworks x 2 SAPIs), inventory tooling, no mitigations

- `mitigate/isolate` — edge auth / allowlist / VPN; compose overlay with an authenticating reverse proxy (SAPI-independent, fastest)

- `mitigate/apache` — mod_php mitigations: Apache directives, `php.ini`, module disable, with smoke tests

- `mitigate/fpm` — php-fpm + nginx mitigations: pool config, FastCGI rewrite hardening, and the `mod_proxy_fcgi` variant

- `mitigate/waf` — ModSecurity/Coraza placed correctly for each SAPI; virtual-patch rule depends on the advisory

- `mitigate/backport` — distro/vendor backport tracking (Debian LTS, Ubuntu ESM, Remi, TuxCare, Zend); no interpreter patch in-repo

- `port/php82` (per framework) — the real fix: upgrade path, deprecations, test strategy