CVE-2026-109618 and CVE-2026-109619 landed on php.net on October 21, 2026. Both are critical, both live in the runtime itself, and both let an attacker run code on your server without logging in first. My first thought had nothing to do with the bug class. I was picturing all the Slack threads that started at 9:14 that morning with "quick q, what PHP are we on in prod?" and then sat unanswered while somebody hunted down the right SSH key.

So here's my position. If figuring out which PHP version handles your live requests takes a human, a terminal and a guess, you have an inventory problem, and the next runtime advisory will find it for you whether you're ready or not. Every deploy should record that version as a fact, right next to the commit hash and the Composer lock. It should never be tribal knowledge.

The guess part matters more than most of us admit. On a typical box I've seen `php -v` print one minor version while the FPM pool behind nginx happily runs another, because a distro package, a PPA and a Docker base image each had their own opinion about it. The CLI is whatever happens to be first in PATH. Your visitors are hitting whatever the pool config points at. Run a cron job, a queue worker and a web request on the same host and that can mean three different interpreters, and only one of them may have picked up the patch.

The fix I'd like to see in every codebase is boring on purpose. At build time, write `PHP_VERSION` and `PHP_SAPI` into a small artifact. At runtime, have each SAPI you use report the same values to an internal health check, and alert whenever the two disagree or fall below a floor you set in config. Once you have that, advisory day turns into a dashboard query. You get a list of hosts that need attention in about four minutes, where before you had an afternoon of archaeology.

The best argument against this deserves a straight answer: publishing your exact runtime version is reconnaissance gift-wrapped for an attacker. That's the whole reason `expose_php` exists and the reason sensible people switch it off. I agree completely. Nothing I'm describing should show up in a public header or on an unauthenticated route. The data goes to your metrics stack or a token-protected endpoint that only your monitoring can reach. An attacker can fingerprint your stack with or without your help anyway. The person who can't is you, on a Tuesday, with a CVE open in another tab.

There's a second objection: on managed platforms the runtime isn't your job. Fine, it may not be your job to patch it, but the risk is still yours to know about. If your vendor really does keep PHP current, your health check will say so, and it costs you nothing. If they don't, you learn it from your own telemetry instead of from somebody else's incident report. Honestly, this is one spot where the Go folks have it a little easier, since the runtime gets baked into the binary they ship. We get to swap the interpreter underneath running code, which is a real advantage, as long as we keep track of which interpreter is in there.

PHP has a predictable release and security cadence, and it's one of the quiet strengths of the ecosystem. The weak link is the gap between a fixed tarball on php.net and the process actually answering port 443. So tell me how you close that gap. Does your team track the serving PHP version per host automatically today, and if so, where does that number live: in your deploy log, your APM, or still in somebody's head?