Exploit for Improperly Controlled Sequential Memory Allocation in Php

| CVE-2026-109618 | GHSA-w8hw-w9fx-j79w | Out-of-memory handling can interrupt PHP while request data is only partially initialized; request cleanup may then treat invalid data as valid. |

| CVE-2026-109619 | GHSA-6wmf-4rv5-p3rp | Request-owned internal state can survive after its memory is freed (use-after-free), so a later request on the same worker may use stale state. |

**Affected:** all PHP installations serving web requests (PHP-FPM, Apache

`mod_php`, `php-cgi`, FrankenPHP, LiteSpeed). `mod_php` is rated highest risk.

PHP 8.1 and older are end-of-life upstream; minimal source backports exist for

7.4 / 8.0 / 8.1, and many distributions ship their own backports. **Updating is

the only complete fix**; the advisory's interim mitigations do not make an

### 1. `php_patch_check.c` — network banner probe

A C program that makes one harmless HTTP `GET` per site, reads the PHP version

advertised in the `X-Powered-By` / `Server` response headers, and compares it

to the fix table. Use it to **sweep many sites quickly** and find the obvious

Verdicts per site: `PATCHED`, `VULNERABLE?`, `UNKNOWN` (no version advertised),

### 2. `php_patch_check_server.sh` — on-server authoritative check

A POSIX shell script you run **on the server** (e.g. over SSH). It:

- discovers every PHP SAPI present (CLI, versioned CLIs, `php-fpm`, `php-cgi`,

- reads each real installed version and compares it to the fix table;

- reads the **installed package's changelog** (`dpkg` / `rpm`) to detect

**vendor backports** — fixes shipped without bumping the upstream version;

- reports the advisory's interim mitigation settings

(`session.upload_progress.enabled`, and `fatal_error_backtraces` on 8.5).

Verdicts per SAPI: `PATCHED`, `LIKELY PATCHED via vendor backport`,

Exit code: `0` all clear, `1` a genuine vulnerability found, `2` an unknown

(with `1` taking precedence) — suitable for cron / monitoring.

Requires OpenSSL development headers for HTTPS.

cc -O2 -Wall -Wextra -D_GNU_SOURCE -o php_patch_check php_patch_check.c -lssl -lcrypto

./php_patch_check

If you cannot install the OpenSSL headers, a headers-free build is available for

cc -O2 -Wall -Wextra -D_GNU_SOURCE -DNO_TLS -o php_patch_check_notls php_patch_check.c

./php_patch_check_notls

No build step; needs only a POSIX shell. Copy it to the server and run:

ssh user@your-server 'sh -s' < php_patch_check_server.sh

1. Run `php_patch_check` from your machine to sweep all sites and flag anything

that is not a clean `PATCHED` (expect many `UNKNOWN`s — well-configured hosts

set `expose_php=Off` and advertise no version).

2. For each flagged or unknown host, run `php_patch_check_server.sh` on the

server for the authoritative answer, including backport detection.

3. Update any host that is not patched to the fixed release for its branch (or

- **Authorization.** Only probe or run these against systems you own or have

explicit permission to test. Scanning third-party hosts may be unlawful.

- **`UNKNOWN` is not "safe."** It means the version could not be determined —

verify another way (`php -v`, `phpinfo()`, control panel).

- **Version strings lie (backports).** Distributions patch security bugs

*without* changing the upstream version number. A `VULNERABLE?` verdict from

the network probe is only a hint; confirm with the on-server script or your

- **`LIKELY PATCHED via vendor backport` is strong evidence, not proof.** The

server script matches a CVE string in the installed package's changelog. For a

hard guarantee, confirm the exact package version against your vendor's

security advisory (Ubuntu USN, Debian DSA, RHEL errata, your host's changelog).

- **These tools only check PHP.** They do not detect WAF rules, proxy-level

limits, or whether mitigations were actually effective.

- **Not a substitute for updating.** Per the advisory, interim mitigations do