CVSS 9.2, twice, and the first thing half of us typed on October 21 was php -v. I did it too, in a terminal on a box I was fairly sure mattered, and I got back a reassuring number that told me almost nothing. That command reports the CLI binary on your shell's PATH. It says nothing about the FPM pool behind nginx, or the container image somebody baked three weeks ago, or the queue worker that Supervisor started on a Tuesday in August and has kept alive ever since.

Upgrading to the fixed release is the cheap part of this week. The expensive part is that most teams I talk to can't produce, from memory or from a file in a repo, the full list of PHP processes that answer network traffic on their behalf. Without that list, the patch is a hope. You upgraded the machines you remembered, and the attacker gets to work on the ones you forgot.

The facts, briefly, because they explain why this one goes below your framework. CVE-2026-109618 sits in the engine's handling of requests that blow through their memory ceiling, and CVE-2026-109619 is a use-after-free that a fatal error can set up for whatever runs next. Both are runtime bugs, so your Laravel middleware and your carefully written FormRequest classes are standing in the wrong room. The PHP team says there are no complete workarounds either, so you won't find an ini flag to flip while you wait for a maintenance window. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and that's the whole menu.

The thing that worries me most is process lifetime. A package manager can finish its upgrade cleanly while the old engine keeps running in memory, because nothing told the FPM master to reload. php artisan queue:work under Supervisor, Horizon, Octane workers: all of these are designed to stay up for weeks, and that's a good property right up until the code they loaded is the code you need gone. Our Go friends at least get one smug advantage here: when they redeploy a static binary, the thing running is the thing they built. We get apt reporting success at 14:02 and a worker that's been alive for 41 days still serving the old runtime at 14:03.

The strongest pushback I've heard this week is fair. Most of us run on a distro, a managed platform or a provisioning tool precisely so that nobody on the team has to babysit runtimes, and those vendors shipped fixed packages fast. Better still, distros often backport security fixes into an older version number, so a Debian or Ubuntu box can be safe while php -v prints something that looks stale. Agreed, and that cuts both ways. If the version string can mislead you in the reassuring direction, it can mislead you in the dangerous direction too, and the only check that settles it is one taken from inside the process that serves requests, after it restarted.

So what I'd actually build this week is boring and small. Give every app an internal-only health endpoint that reports PHP_VERSION and the process start time from inside FPM, not from a shell, and have your monitoring flag anything older than the fix. Make CI refuse base images below the patched release for your branch. Keep one file, per team, listing every host, image and worker that runs PHP, and treat it as code. It pays off twice before New Year: PHP 8.2 hits end of life on December 31, 2026, and that same file tells you on day one who still has to move.

None of this replaces looking for trouble. Six days have passed since the release, the flaws are reachable without logging in, and a clean upgrade proves nothing about what happened before it. Read the FPM logs for crash spikes, check for files and admin accounts you didn't create, and rotate credentials if anything looks off. That's ordinary incident hygiene, and it gets much easier when you already know which machines to look at.

Here's what I'd genuinely like to hear from you under this piece: right now, without opening a terminal, could you say which PHP version served your production app's last request, and how you'd prove it? Do you check from inside the request, or do you trust that the pipeline did what it said? And if you run long-lived workers, do you restart them on every runtime patch, or only when someone remembers?