Last week, two memory-safety vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619) made the rounds.
The TL;DR: PHP manages background processes that handle web requests. Under certain conditions, those processes can end up in a broken enough that someone with no credentials can walk right in and run their own code on your server, or read memory they shouldn’t be able to see.
Real flaws. We patched them Wednesday morning, October 21st, when the patches first became available.
Then we spent the rest of the week answering emails.
What actually happened
The flaws were legitimate. Unauthenticated remote code execution is never a great thing to see in a CVE, and the memory disclosure side added another angle worth worrying about. These weren’t edge cases nobody would ever hit.
But they were patchable. These were both a known CVE with a vendor-issued patch, in a runtime with a massive and active maintenance community behind it. This is exactly what routine security hygiene is built to handle. Patch management does its thing, you verify, you move on. For us, the window between disclosure and remediation was short enough that it never became a real exposure.
Why everyone got nervous anyway
PHP runs something like 70% of the web, as I’m sure most of the community was reminded. WordPress, for example, powers a huge chunk of the sites regular, non-technical people use every day. So when PHP has a vulnerability, the story writes itself. Everything is at risk. Act now.
But scale cuts both ways: PHP being everywhere also means PHP has mature patch infrastructure and an extremely active community. For anyone running a managed environment or a real deployment pipeline, updates are close to automatic.
The attack surface is large and so is the maintenance apparatus around it.
Think about something like the log4j vulnerability in 2021 by comparison. That was a zero-day hiding inside a dependency quietly embedded across millions of systems for years before anyone knew to look. Nobody had a patch because nobody knew the problem existed. That’s a different category of scary. These PHP flaws were serious but they came with a fix.
Let’s be honest about the incentives
Pretty much every security firm in my feed posted some version of “are you protected?” last week. We did too. Part of that is good faith. If your clients might be exposed, you should say something. But it’s also a reliable playbook. A high-profile CVE is a built-in reason to send a timely email and remind people you exist.
Not judging it. We’re in the business and we benefited. Worth calling it out though.
The security industry has a complicated relationship with fear. Uncertainty is the product. A slow news week is genuinely bad for business in a way it just isn’t for most other professions.
What the noise actually revealed
We fielded somewhere between twenty and thirty emails last week from clients, plus a handful from friends and family. All some version of “should I be worried about this?”
That’s not a PHP problem. That’s a trust problem.
If your clients need a news cycle to feel confident they’re covered, the gap isn’t in your security stack. It’s in how well they understand what you’re doing for them on any given week. The patch went in Wednesday morning before most of them had even seen the first article. They had no way of knowing that.
That’s on us as much as anything.
The vulnerabilities were real. The patch was there. For anyone running a maintained environment the risk window was small. But the emails were useful in their own way. They made visible how much ambient anxiety sits underneath all of this, waiting for something to attach to.
Good security posture should make things like this boring. The harder problem is making that boringness legible to the people counting on you.
I’m the Development Lead at First Ascent Design, a web and digital agency in Wilmington. The trust-and-communication problem at the end of this post is a lot of what we work on.