Wednesday Was A Tough Day: PHP CVEs and Running a Software Agency

II'll be honest with you - yesterday was one of the harder days I've had running Jump24 in a while. Not hard in a "we just lost a client" way or "the servers are on fire" way (though at points it felt close to the latter). Hard in that quiet, grinding, relentless way where every conversation you have is a difficult one.

Yesterday the PHP project released security patches for two critical remote code execution vulnerabilities - CVE-2026-109618 and CVE-2026-109619 - affecting PHP 8.2, 8.3, 8.4, and 8.5. Both vulnerabilities sit in the parts of PHP that nearly every single request touches: memory management and error handling. The kind of code that underpins essentially everything. Under the right conditions, an unauthenticated attacker could execute code remotely on your server. That’s about as bad as it gets.

What made it worse wasn't just the severity. It was the timing. The coordinated disclosure was disrupted when the CVE IDs leaked a day early, circulating online with an incorrect CVSS score of 10.0 (the real score is 9.2 - still critical, but the wrong number caused genuine panic). Then Chainguard broke the embargo more than six hours before the release, publishing patched images while the rest of us were still waiting for packages to land. By the time the official releases - PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 - were actually out, the internet had been in various stages of chaos for nearly 24 hours.

The reality of running an agency that uses PHP

Here's the thing most of the hot takes yesterday missed: our clients don't all run the same version of PHP. Of course they don't. We have clients on 8.2, clients on 8.3, clients on 8.4, legacy applications that are in the middle of upgrades, and a couple of projects where "getting to a supported PHP version" is still on the roadmap rather than done. In a perfect world everyone would be running the latest version of every piece of software they can but we don't live in a perfect world do we?

So my Tuesday evening went something like this: check twitter (X) and see lots of noise about 2 PHP CVE's that look serious, verify it's as serious as people are saying (it was), and then start working through a list of clients to figure out their exposure. Not just "what PHP version are they on" but "what’s the attack surface here, how is this deployed, are they on mod_php or FPM, are there any mitigations we can put in place while we wait for patches?"

And then on Wednesday come the calls.

Having to tell a client "there’s a critical vulnerability in PHP itself, not your application, and at the moment there's nothing we can except wait for the patch and potentially take the application offline in the meantime" is not a fun conversation. Not because clients are unreasonable - most of them are brilliant, and the ones I spoke to yesterday took it on the chin and understood why this needed to be done, but because as an agency you're in this frustrating position of having no fix to offer. There was no clever configuration tweak we could deploy, no emergency patch we could write ourselves. Just a waiting game, and that feels deeply uncomfortable when you're the person responsible for keeping someone's business running.

Taking things offline

For a couple of applications, we made the call with the client to bring them down temporarily. That decision is never easy. Even a short period of downtime has real business impact - lost sales, interrupted workflows, frustrated users. And you're making that call under significant time pressure, with incomplete information, while trying to have a calm and reassuring conversation with the person on the other end of the phone who is, quite understandably, stressed.

What I kept coming back to was this: the risk of staying online was higher than the risk of being offline. These are RCE vulnerabilities on widely-used infrastructure. Unauthenticated. Pre-application-code. We couldn't in good conscience leave certain applications exposed and just hope for the best.

Explaining that to clients in plain English - without drowning them in CVE numbers and CVSS scores they don’t need - is a skill in itself. "We're going to protect your application by taking it down until we can apply the fix" lands a lot better than a technical wall of text. But it still requires trust. I'm grateful we've built that trust with the clients we have.

The patch scramble

Then the patches landed, and the rest of the afternoon became a race. Not just us - everyone. Hosting providers were under enormous load, package mirrors were struggling, deployment pipelines were queuing up behind each other, and in a couple of cases we hit issues where the newly patched PHP version exposed an unrelated compatibility quirk in application code that had been quietly lurking.

That last one is particularly fun. "We're patching a critical security vulnerability and we've just found a new bug" is not the update call you want to be making at 5pm.

We got everything sorted. Everything is patched, everything is back online, and no clients were compromised. But it was a long day.

The social media noise

I want to address this directly because it was genuinely wearing by mid-afternoon: the pile-on from people who don't use PHP asking why anyone is still using PHP.

Look. I get it. Tribal instincts run deep in tech. But the "just move to [other language]" takes that flooded my timeline yesterday were reductive to the point of being useless.

Every major language runtime has had critical vulnerabilities. The question isn't whether PHP had a bad day - it did - it's whether the ecosystem is investing in the right things to prevent and respond to these issues. And actually, if you read the PHP Foundation's own post about what happened, the picture is more nuanced than "PHP is broken and you should leave."

The OOM vulnerability behind CVE-2026-109618 was first identified back in 2024 during PHP's first external security audit in years - funded by the Sovereign Tech Agency and carried out by Quarkslab. The delay in fixing it was a structural failure the Foundation openly acknowledges, and they've changed processes because of it. The Ecosystem Security Team was only created in May of this year. Multiple security engineers have been brought on. They're using AI tooling to help validate and triage reports. This is an organisation actively investing in making PHP safer.

That doesn't mean yesterday wasn't a mess. The leak, the embargo break from Chainguard, the cascading chaos of a disrupted disclosure process - all of that was genuinely damaging. But it happened against a backdrop of the ecosystem doing more security work than it's done in years. The two things can both be true.

The bit I keep thinking about

Running an agency means your clients trust you with their livelihoods. Their businesses run on software we've built and maintain. When something like yesterday happens - something completely outside anyone's control - you feel that responsibility acutely.

I don't have a neat takeaway. We handled it, we'll do a retrospective on the response, and we'll probably tighten up some of our incident communication processes as a result. But I think it's worth writing this down while it's still fresh, partly as a record, and partly because I suspect I'm not the only agency owner who had a quietly brutal Tuesday.

If you're in the same boat and want to compare notes, you know where to find me.

The PHP Foundation's full account of how these vulnerabilities were found, why disclosure was disrupted, and what they’re doing about it is well worth reading: thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security