It's never just a patch: the human side of a critical security fix

On 21 October, the PHP project announced fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that could let anyone on the internet run code on a web server without logging in (PHP security advisory). CERT-EU went further than usual, advising organisations that could not patch quickly to take affected websites offline.

PHP sits underneath a large share of the web, so a lot has already been written about the technical fix. This post is about the other half of the response: how we kept clients informed, the decisions we asked them to make and how the team worked through it. That half is easier to overlook, but it is what decides whether clients feel looked after.

Everyone heard from us, affected or not

When news like this breaks, every client with a website wonders whether it applies to them. We record runtime versions in the technical documentation for every platform we support. Our developers used that to identify which systems were likely to be affected, then confirmed the PHP version actually running on each one. We contacted every client the same day, whether they were affected or not.

For clients who were affected, the first message set out what we knew, what we were doing and what we needed from them. For clients who were not, it was a short note to say we had checked, they were not affected and no action was needed.

That note was short, but it meant those clients didn’t have to chase us and could answer their own leadership with confidence.

‘It’s just a brochure site’ is not low risk

Several of the affected systems were informational websites, with no logins or transactions. That didn’t make them low risk. The vulnerabilities were in PHP itself, so a compromised site could be defaced, used to serve malware under a trusted name or used as a way into whatever else the server could reach.

We treated every affected site with the same urgency.

Regular updates, and decisions that belong to the client

Affected clients heard from us as the work progressed, not just at the start and the end. Each update covered where their system stood, what we were doing next and when they would hear from us again. We kept to those times, even when there was little new to report.

While we waited for the fixes to be released, we put interim mitigations in place on affected systems to reduce their exposure. Some decisions were not ours to make, though. Where a site was still exposed, we set out the options - including temporarily replacing it with a holding page - the risks of each and our recommendation, and recorded each client’s decision. Every client chose to keep their website live, and some also took separate, higher-risk services offline until they were fixed.

Our 24x7 clients already have emergency contacts and approvals agreed. For clients on office-hours support, we asked each to name someone who could approve an emergency change that evening. Sorting that out early meant no one was waiting on an approval once the fix was ready.

No shortcuts, even under pressure

Under this kind of pressure, the temptation is to push the update straight to production and hope. We didn’t.

Every fix went through our secure development lifecycle. Each update was tested by QA, backed up so it could be rolled back, and smoke tested once live. The process is there precisely for days like this, when a rushed change is most likely to break something.

This was beyond what our support rota is sized for, so we brought in additional developers and QA to work alongside the rota team, and people across the company stepped in without being asked twice. The last affected system was confirmed fixed within eight hours of the fixes being released.

Once every system was patched, we reviewed server logs and files for signs that the vulnerabilities had been used before the fix. We found no evidence of exploitation.

This is becoming the norm

On the same day as the PHP fixes, Node.js released fixes for ten vulnerabilities across its supported versions. Days like this are becoming more common. AI tools can now scan source code for flaws at a scale that wasn’t possible before. Palo Alto Networks’ Unit 42 reported finding more than 14,000 previously unknown vulnerabilities in open-source projects in two months, and the CNCF has warned of the strain this is putting on the people who maintain that software. The same tools are available to attackers.

For anyone running a website, that means more frequent security releases, less time between a fix being published and someone trying to exploit the flaw, and less room for software that has fallen behind. The preparation that helped us on 21 October is what will matter each time.

What made the difference

Most of what helped on the day was in place long before it:

• Supported versions only. We advise clients to keep their software up to date and don’t let products we support run on end-of-life versions. Every affected system was already on PHP 8.4, so an official fix was available the moment it was released.

• Up-to-date technical documentation. Runtime versions are recorded for every platform we support, so identifying affected systems was quick.

• Emergency arrangements already agreed. Our 24x7 clients have contacts and approvals in place. Extending that to office-hours clients for one evening was the exception.

• A fallback for deployments. When a third-party service we use for deployments had an outage, we had an alternative route ready and would have switched to it if the delay had gone on.

Marino Software designs and builds intelligent software, to the standards regulated work demands, for critical contexts: healthcare, finance, the public sector and transport. Keeping applications secure, trustworthy and available is part of our “Software, made human” promise. Contact us to discuss your next project or roadmap.

Hero image: The AI Race by Gloria Mendoza, via Better Images of AI. Licensed under CC BY 4.0. Cropped.