CVE-2026-109618 / CVE-2026-109619 patches for end-of-life PHP (7.3 on EL7, 5.4 / 5.3 on Amazon Linux)

Unofficial backports of the PHP security team's minimal mitigation for the two critical, unauthenticated remote code execution vulnerabilities announced on 2026-10-21:

CVE	Advisory	Summary
CVE-2026-109618	GHSA-w8hw-w9fx-j79w	RCE via out-of-memory corruption (CVSS 4.0: 9.2)
CVE-2026-109619	GHSA-6wmf-4rv5-p3rp	RCE via stale global state (CVSS 4.0: 9.2)

Upstream fixed PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, and published source-only minimal mitigations for 7.4, 8.0 and 8.1. Nobody publishes a fix for the platforms below, so this repository provides patches and reproducible build scripts for them.

Not affiliated with the PHP Group, Remi Collet, or Amazon. No warranty. Read Limitations before deploying.

Why trust this

Independent cross-check. Sury's Debian/Ubuntu php7.3 7.3.33-35 contains a separate 7.3 port of the same upstream commit. The EL7 patch here changes the same 17 files, and the core changes are line-for-line identical (details in docs/TESTING.md).
Source only, no binaries. You build the packages yourself from vendor-signed source RPMs; the build scripts verify those signatures before patching.
Reproduced from a clean checkout. All three builds were rerun from scratch using only this repository's scripts, and tests/verify.sh reported PATCHED for each.
Small, reviewable patches with SHA-256 checksums in SHA256SUMS and in each release.

Which file do I need?

Your system	PHP package source	What to use
CentOS 7 / RHEL 7	Remi `php73` (e.g. `php-7.3.33-14.el7.remi`)	`patches/php-7.3.33-remi22-el7-…` + `build/el7-php73/build.sh`
Amazon Linux 2	Amazon `php-5.4.16-46.amzn2.*`	`patches/php-5.4.16-amzn2-…` + `build/amazon-linux/build.sh amzn2`
Amazon Linux 1 (AMI 2017.03 / 2018.03)	Amazon `php-5.3.29-1.8.amzn1`	`patches/php-5.3.29-amzn1-…` + `build/amazon-linux/build.sh amzn1`
Ubuntu / Debian with the Sury PPA, PHP 7.3 / 7.4 / 8.0 / 8.1	`deb.sury.org`	Nothing from here. Upgrade to Sury `7.3.33-35`, `7.4.33-31`, `8.0.30-25` or `8.1.34-9` (or later). They already contain the fix (`debian/patches/*-Avoid-state-corruption-via-bailout.patch`), even though their changelogs do not mention the CVEs.
Ubuntu 24.04 distro `php8.3`	Ubuntu archive	Upgrade to `8.3.6-0ubuntu0.24.04.13` or later.
PHP 8.2 or newer from any source	—	Upgrade to 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or later.

Quick start

Requires Docker on the build machine (any OS). Builds run entirely inside containers of the target distribution, so the resulting RPMs install with a plain yum localinstall.

git clone https://github.com/leonlai-tw/php-eol-cve-2026-109618-109619.git
cd php-eol-cve-2026-109618-109619

# CentOS 7 / RHEL 7 + Remi PHP 7.3   -> ./work-el7/out/
build/el7-php73/build.sh

# Amazon Linux 2 + PHP 5.4           -> ./work-amzn2/out/
build/amazon-linux/build.sh amzn2

# Amazon Linux 1 + PHP 5.3           -> ./work-amzn1/out/
build/amazon-linux/build.sh amzn1

The resulting packages are versioned <vendor version>.cvefix1 (for example php-7.3.33-22.cvefix1.el7, php-5.4.16-46.amzn2.0.7.cvefix1), so they always sort newer than the vendor package they replace.

Install only the packages you already have, then restart PHP:

# on the target host, inside the directory holding the built RPMs
yum localinstall $(for p in $(rpm -qa 'php*' --qf '%{NAME}\n'); do ls ${p}-[0-9]*.cvefix1*.rpm 2>/dev/null; done)
systemctl restart php-fpm      # or: apachectl graceful   (mod_php)

Long-running PHP processes (Swoole/Octane, queue workers, cron daemons) must also be restarted; otherwise they keep running the old binary.

Verify

rpm -q php-cli                  # must end in .cvefix1
tests/verify.sh                 # prints PATCHED / NOT PATCHED

tests/verify.sh runs one CLI process with a 16 MB memory limit and checks the minimal mitigation's observable behaviour: on out-of-memory the process exits with code 1 without running shutdown functions (unpatched PHP exits 255 and runs them).

To confirm a running PHP-FPM uses the new binary:

p=$(pgrep -o -f 'php-fpm: master'); sha256sum /proc/$p/exe /usr/sbin/php-fpm   # hashes must match

What the patch changes

Same design as upstream commit 712e60f9ed ("Avoid state corruption via bailout", branch PHP-7.4-CVE-2026-109618-109619):

Out-of-memory no longer long-jumps into request shutdown (CVE-2026-109618). The allocator prints the fatal error to stderr and terminates the process with _exit(1); PHP-FPM / Apache start a fresh worker. The same applies to the "Possible integer overflow in memory allocation" errors.
Multipart parsing keeps only Content-Disposition and Content-Type part headers and ignores duplicates, so a small request can no longer make PHP allocate huge amounts of memory.
session.upload_progress is disabled (the confirmed producer for CVE-2026-109619).
Request-owned global state is reset at shutdown (superglobals, SAPI auth/content-type fields, modules_activated, executor exception/error-handling state, linked-list heads), so a following request cannot observe freed state.

Details per file and how each port was made: docs/PROVENANCE.md. Test results: docs/TESTING.md.

Limitations

This is the minimal mitigation, not the full fix shipped in PHP 8.2+. It blocks the published attack paths; it does not audit every extension for leftover state. Upgrading to a supported PHP version remains the real fix.
Behaviour changes (all inherited from the upstream mitigation):
- a request that exhausts memory_limit terminates its worker process; with mod_php the client sees a dropped connection instead of an HTTP 500 page;
- register_shutdown_function() callbacks do not run after an out-of-memory error;
- session.upload_progress no longer reports progress.
The EL7 build is based on Remi's 7.3.33-22 source. If you currently run Remi's last EL7 binary (7.3.33-14), you also receive Remi's security backports from -15 to -22 (CVE-2024-4577, CVE-2024-8925/8926/8927, CVE-2024-8929, CVE-2024-11233/11234/11236, CVE-2025-14178, CVE-2026-6735, CVE-2026-14355, CVE-2026-7260, CVE-2026-17543 and others).
The Amazon Linux 1 build is made in the amazonlinux:2018.03 image and requires openssl ≥ 1.0.2k (libcrypto.so.10(OPENSSL_1.0.2)). Hosts still on openssl 1.0.1k must upgrade openssl from amzn-updates first.
PHP 5.x has no other security support at all. Treat these hosts as needing migration.

Status

Built and deployed in production by the author on 2026-10-22 (CentOS 7 / PHP-FPM web servers, Amazon Linux 2 and 1 / mod_php). Issues and pull requests are welcome; there is no support commitment.

Most Popular

php-eol-cve-2026-109618-109619