PHP Dropped Two Critical RCEs This Morning — and the Patch Isn't Available Yet. Here's What You Do in the Gap.

At 9:00 this morning Central time — 14:00 UTC — the PHP project shipped security releases across all four supported branches: 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Not routine ones. Each fixes the same two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2, and both allowing unauthenticated remote code execution. The project's own advisory says it plainly: "There are no complete mitigations, updating is the only safe choice."

Here's the part the headlines skip: on patch day, the patch isn't necessarily available to you. The client platforms we manage run on AWS, and as of this writing the patched PHP builds haven't landed in AWS's package repositories. "Just update" isn't on the menu yet.

That gap — between the advisory and the moment your platform's packages actually exist — is where operations discipline either shows up or doesn't. Here's what our morning looked like inside it.

Why these two are genuinely scary

Most PHP vulnerabilities need your application to do something specific — deserialize untrusted input, pass user data to the wrong function. These two don't.

The first, CVE-2026-109618, lives in out-of-memory handling: PHP can be interrupted while a request's internal data is only partially initialized, and cleanup then treats that invalid data as valid. Per the advisory, the risk is highest under mod_php, where an unauthenticated request can trigger the attack before any application code runs. Your codebase can be perfect; it never gets a vote.

The second, CVE-2026-109619, is stale global state: request-owned internal state can survive after its memory has been freed, and a later request handled by the same worker can use it before initialization resets it. Again — not an application bug. A runtime bug, on every PHP site on the internet, in every branch from 8.2 up.

The morning, in order

Yesterday, 20 October: the PHP security team published advance notice — two critical vulnerabilities, CVSS 9.2, fixes landing Wednesday at 14:00 UTC. That notice is the most valuable document of the whole event, because it converts an emergency into an appointment. We read it, confirmed our runtime inventory was current, and knew before going to bed which platforms were exposed and in what order they'd get attention.

9:00 AM: releases land. First read is the advisory, not the download page — you respond differently when the worst case is "unauthenticated RCE before application code runs" than when it's a hardening fix.

9-something: the inventory check nobody enjoys — are the fixed builds actually available where you need them? For the AWS-hosted runtimes we manage for clients: not yet. Upstream source releases exist; the distribution packages those servers install from don't. This is normal, it's usually measured in days, and it changes the job from "patch now" to "shrink the attack surface until you can."

So the mitigation went to the edge. The client platforms we manage sit behind Cloudflare, and Cloudflare moved fast on these CVEs — WAF rules to help blunt the known attack patterns went in front of every exposed PHP surface we manage. We layered on the advisory's partial hardenings where they fit our stacks. And we set a standing watch on the package repositories: the moment AWS ships the patched builds, they roll out, with verification against the live processes — not just the CLI binary, but the worker pools actually serving traffic.

One thing we won't pretend: the advisory is explicit that there are no complete mitigations, and we treat the WAF exactly that way — as exposure reduction that buys down risk during the gap, not as safety. Updating remains the only real fix, which is why the repo watch matters as much as the rules.

And if we operate your platform: everything above is already done for you. You don't need to know what PHP version your server runs or follow AWS release notes — that's the job you hired us for. Mitigation is in place, your runtimes are on the patch watch, and you'll hear from us when it's patched, not when you should worry.

The gap is won months earlier

Nothing about this morning was clever. It was calm because of things that were already true at 8:59:

• A current inventory. You cannot protect what you don't know you run. We keep a live roster of every runtime we manage for clients — version, host, owner, exposure. The first hour of a bad patch day is usually spent building that list; ours was built years ago and maintained since.
• An edge you can program in minutes. A WAF in front of your platforms is worth little if nobody can write a rule under pressure. Having Cloudflare already in the path meant mitigation was a morning's work, not a migration project.
• Someone actually on the pager. Advance notice only helps if somebody reads it. "We take the pager" isn't a slogan on our Platform Operations page; it's why yesterday's notice became this morning's calendar block instead of next week's incident.
• Monitoring that would tell us if we were wrong. During the gap, observability is the difference between "mitigated" and "hoping."

One more date from today's announcements: PHP 8.2 reaches end of life on December 31, 2026. After that it gets no security fixes at all — and anything older already gets at most minimal source backports. Our clients don't need to mark that calendar; version-lifecycle planning is part of what we carry. But if nobody carries it for your platform, days like today are a preview of what unsupported costs — and the upgrade isn't a someday project anymore.

If you're not sure where you stand

Three questions tell you most of what you need to know: What PHP versions are serving your production traffic right now? What stands between the internet and those runtimes while you wait for a patch? And who, specifically, was responsible for acting on this morning's release? If any answer is fuzzy, that's fixable — it's precisely the unglamorous work our Platform Operations practice exists for. And in keeping with how we price everything: if you ask us to take it on, you'll get a written quote before we touch anything.