On October 21, 2026, PHP shipped fixes for two critical remote code execution bugs: CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2, both potentially unauthenticated. The fixes are in 8.2.35, 8.3.36, 8.4.27, and 8.5.12. If you run a supported branch, update today — it’s a one-liner and you’re done.
If you’re on PHP 7.4, 8.0, or 8.1, this is the post I’m sorry to be writing. Those branches are end-of-life and get no official fix. The affected code is old enough that your version has it too, and the entry point is a plain multipart/form-data upload reaching a default php-fpm or mod_php setup — not an exotic configuration. You are exposed, and nobody upstream is coming to patch it.
This is the overview — what shipped and who’s affected. Two companion posts go deep on what to actually do: mitigating it today when you can’t upgrade, and containing the unpatchable interpreter behind a modern runtime.
What the two bugs are
Both are memory-safety failures in PHP’s request-handling core, reachable through the multipart form parser that runs during request startup — before any of your application code executes.
- CVE-2026-109618 — corruption via the out-of-memory bailout. When PHP runs out of memory mid-request, it historically aborts by jumping straight out of the current operation. If that jump fires while a request’s internal state is only half-built, later request shutdown trusts the half-built state. An attacker who can drive memory pressure at the right moment can turn that into code execution.
- CVE-2026-109619 — stale request state. Error, session, and serializer state left over from a request that died early gets read by the next request’s early startup work. Leftover state the engine assumes is clean, isn’t.
Both are triggered through multipart/form-data request bodies, parsed in main/rfc1867.c. That makes them reachable on the common web stacks — Apache mod_php and nginx + php-fpm — on default configs. (Pure CLI usage doesn’t run that parser, which is the seed of the containment approach in the second companion post.) CERT-EU’s advisory 2026-018 states that every PHP version from PHP 5 onward is affected.
If you’re on a supported branch (8.2–8.5): update now
The fixed versions are 8.2.35, 8.3.36, 8.4.27, 8.5.12 (the last releases before the fix were 8.2.34 / 8.3.35 / 8.4.26 / 8.5.11, from September 24). Pick your platform:
- Docker official images: bump the tag (
php:8.3.36-fpm,php:8.4.27-fpm, …) and rebuild. Don’t float on8.3-fpmand assume — pin and verify. - Debian / Ubuntu (deb.sury.org or distro):
apt update && apt upgradethephp*packages. - RHEL / Alma / Rocky (Remi):
dnf update php\*against the Remi repository. - macOS dev (Homebrew):
brew upgrade php.
Then verify with php -v and confirm the patch version matches the list above — not just the branch. Restart php-fpm / Apache so running workers pick it up.
If you’re on PHP 7.4, 8.0, or 8.1: the uncomfortable part
PHP 7.4 reached end of life on November 28, 2022. PHP 8.0 on November 26, 2023. PHP 8.1’s security support ends December 31, 2025. None of them get an official fix for this. A very large number of CodeIgniter 3 and Laravel 5/6 apps are pinned to exactly these versions, and they all get nothing from upstream.
Your options, in order of how fast each one buys you safety:
- Isolate it. The fastest risk reduction: take the app off the public internet, or put it behind authentication at the edge, while you decide what’s next. Nothing else you do is faster.
- Watch for a distro/vendor backport — but don’t plan around one. Debian LTS, Ubuntu ESM, TuxCare, Zend, and Remi sometimes backport to EOL branches. For this fix it’s a long shot: it rewrites PHP’s out-of-memory bailout and relies on PHP 8 machinery 7.x doesn’t have, so it isn’t a clean cherry-pick. Check your vendor; assume the answer is no.
- Mitigate at the edge, as a stopgap. You can meaningfully shrink the attack surface today without touching application code — block multipart where it isn’t needed, disable
session.upload_progress, and fix your memory posture. The full, tested playbook is the first companion post. None of it makes you safe — that’s PHP’s own framing — but it reduces exposure while you plan the real fix. - Port to a supported PHP 8. The only complete fix. For a 7.x CodeIgniter or Laravel monolith that’s the migration you’ve been deferring — and if the jump is a genuine climb, wrapping the legacy interpreter behind a patched modern runtime can buy you a safe runway to do it on.
How to find out if you’re actually exposed
You can’t mitigate PHP you forgot you were running. Before anything else, inventory:
- Where PHP runs that you’ve forgotten about — a cron box, an internal admin tool, an old microservice behind the load balancer.
- Which SAPI each one serves — mod_php (apache2handler) vs php-fpm (fpm-fcgi). The serving SAPI, not the CLI you get from
php -v, determines reachability. - Which routes accept uploads, because that’s the trigger surface.
I built an open lab to make this concrete: php-cve-lab stands up CodeIgniter 3, Laravel 6, and Fat-Free on PHP 7.4 across both Apache mod_php and nginx + php-fpm, with an inventory script that reports the PHP version, the serving SAPI, and the loaded extensions for a target, a mitigation decision doc, and runnable demos of each mitigation (edge multipart blocking, a Redis in-flight upload budget, cgroup OOM handling, and CLI-isolation of the legacy interpreter). Stand up your framework version and find out whether a given mitigation breaks your app before you ship it to production.
It carries no exploit code for these CVEs, and it never will. A public proof of concept for an unpatched RCE with no PHP 7 fix is a mass-targeting tool, not a teaching aid. The lab is detection, mitigation testing, and port rehearsal only.
What I’m doing about it
To be straight with you: I’m in the middle of exactly this with a client — a CodeIgniter app pinned to PHP 7.4 where the jump to 8.x is a real project, not a weekend. Right now that means inventorying its actual exposure (which SAPI, which reachable routes) and testing which mitigations hold without breaking the app, as a private assessment. I’ll publish the detection and mitigation findings. I won’t publish a working exploit, and there’s no client name here.
If you have a PHP 7 app and need a plan this week — not a lecture about technical debt — the Modernization Roadmap is a fixed-scope engagement: your real exposure, a mitigation stopgap, and a port strategy you can hand to your team.
I help teams modernize legacy systems with AI-assisted development guardrails that keep the agents productive and the production safe. fitzpatricksoftware.com
