Who Is Patching Your Software? Why a Support Contract Matters

The cover image for this post is by Gabriel Heinzer on Unsplash

⚠️ An evolving situation

This post was written on Friday, October 23rd, 2026, and its sources were last checked at 10:00 BST on Saturday, October 24th, 2026. PHP, Node.js and GitLab are all still publishing advisories about the vulnerabilities described below; PHP issued a follow-up two days after its main release, and Microsoft has not yet said whether .NET is affected by the Brotli vulnerability. Before acting on any version numbers here, check the linked advisories for anything newer.

Update, October 24th, 2026: on October 23rd, 2026, the Chrome Root Program told eMudhra that social media scrutiny and investor analysis “are not acceptable explanations for delayed responses”, and Mozilla said that eMudhra had not yet answered the questions it sent on October 20th, 2026.

On Thursday, October 22nd, 2026, I spent the day at Leeds Cyber Security Conference, an event I’ve written about before. None of the talks were about PHP, and yet PHP was everywhere. One of the guest panellists had been swapped at the last minute, because the original panellist was busy dealing with a PHP vulnerability for several clients. Throughout the day, people slipped out of talks to work on the same incident for their own clients and customers. There was even an informal “PHP2Shell survivors quiet room” for anyone who needed some space and calm, whether to keep working or to recover from the week they’d had. That building was full of people whose job is security, and many businesses running a PHP website have nobody like that at all.

In the space of seven days, PHP, Node.js and GitLab all released fixes for serious flaws, on the same day, and a company that vouches for the security of websites announced it was leaving that business. None of it was caused by anyone reading this. All of it created work, and in a lot of businesses nobody has been told that the work is theirs. I’d like this post to start a conversation about that, and about what a support contract is for, built around one question you can take to whoever built your website or application: who is keeping it safe, now that it’s finished?

What Happened This Week, in Plain English

PHP: Most of the Web, and a Lot of It Out of Date

PHP is the programming language behind a large share of the websites you visit. According to W3Techs, PHP is used by “69.3% of all the websites whose server-side programming language we know”, and WordPress, which is built on PHP, runs on 39.6% of all websites. If your business has a website, there’s a good chance it runs on PHP, whether or not anyone has ever mentioned it to you.

On October 21st, 2026, the PHP project released fixes for two vulnerabilities that researchers have nicknamed php2shell (CVE-2026-109618 and CVE-2026-109619, using the Common Vulnerabilities and Exposures numbering that the industry uses to track flaws). PHP rated both as critical, with a score of 9.2 out of 10, and both let an attacker run their own code on a web server without logging in. In practice, that means taking control of the website and anything it can reach.

Tanya Janca, the application security educator who publishes as SheHacksPurple, made a point in her video on the vulnerabilities, published the day after the fixes, that should reassure every business owner: the flaws are in PHP itself, so the people who built your site could have done everything right.

You could have done every single thing right as a developer. You could have perfect input validation, parameterized queries, strong access control, and great secure coding practices, and your application could still be vulnerable.

PHP released fixes for the versions it still supports: 8.2, 8.3, 8.4 and 8.5. For 7.4, 8.0 and 8.1, which it no longer supports, the PHP security team published what it called “minimal source-backports”: source code changes for people who compile PHP themselves; there’s no official release. According to AWS, older versions back to PHP 5.4 have no fix from the PHP project at all. That matters, because W3Techs reports that 34.7% of websites using PHP are on PHP 7 or older, and that figure doesn’t include sites on the unsupported 8.0 and 8.1.

The advice from the US Cybersecurity and Infrastructure Security Agency (CISA) was blunt:

Organizations that cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated.

The UK’s National Cyber Security Centre (NCSC) issued its own alert. Amazon reported that one of its honeypots, a decoy system built to attract attackers, recorded an exploitation attempt on October 17th, 2026, four days before the vulnerabilities were made public; Amazon says it’s unclear how the attacker got the details. And on October 23rd, 2026, two days after the fixes, PHP published a further advisory asking administrators to change a setting until its next regular release, and said it would publish the details of one more vulnerability, CVE-2026-115560, alongside that release.

For anyone on a supported version, this meant an urgent update, followed by a second advisory to act on. For anyone on an older version, it meant a choice between an emergency upgrade and taking the site offline.

GitLab: Twice in Nine Days

GitLab is a platform many development teams use to store their code and run their automated builds. Some pay GitLab to host it; others run their own copy on their own servers. On October 21st, 2026, GitLab released a fix for CVE-2026-110264, rated 10 out of 10, which “could have allowed an unauthenticated user to execute arbitrary code on the GitLab server”: in other words, anyone could take it over without logging in. It affected every version since 7.0, released in June 2014, and arrived in a release containing fixes for 12 vulnerabilities.

Nine days earlier, on October 12th, 2026, GitLab had fixed a different 10 out of 10 flaw, CVE-2026-97229, and that earlier update doesn’t protect against the new one. For the teams running their own GitLab servers, this meant two urgent upgrades in nine days, on top of whatever else they had planned.

eMudhra: When a Supplier Leaves

I wrote about eMudhra in detail on Friday, October 23rd, 2026. In short, eMudhra is a certificate authority: one of the organisations that vouch for websites so that your browser can show the padlock. Eight of its signing keys turned out to be guessable, the browsers blocked them, and on October 22nd, 2026, eMudhra announced it would leave the global website certificate business.

eMudhra’s own account deserves to be heard fairly. In its announcement, its chairman said the company revoked the affected certificates “within 14 hours of discovery”, that the business line contributed “about 1% of the global revenue”, and that large providers issuing certificates free of charge had reduced its returns. It has committed to keep existing certificates working through the transition, and to replace affected certificates free of charge through partners.

Even so, the people hit hardest had done everything right. InCommon, which provides certificates to universities and research institutions in the United States, formed a group in 2023 to redesign its certificate service. According to its transition guide, it surveyed nearly 500 of the people who manage certificates, then chose eMudhra’s US subsidiary as the provider “built to meet those requirements for the next 15 years”. It finished moving over in July 2026. Three months later, its universities are moving again. A well-handled incident at a supplier still creates work, and someone on your side has to own it.

The Line Nobody Shows You

Every piece of software has a support window: the period during which its makers fix security problems. When the window closes, the software keeps working exactly as before, and nothing changes on the screen. The only difference is that the next time someone finds a serious flaw, there won’t be a fix.

That’s the line php2shell drew this week. Sites on supported versions got an update; sites on the wrong side of the line got advice to go offline. And the line moves. PHP 8.2’s security support ends on December 31st, 2026, so a website that was on the safe side this week will join the unsupported group in ten weeks, without anyone changing a thing.

The same thing happens in every technology. Last year I wrote about the “Funky Chunks” vulnerability in .NET, CVE-2025-55315, which was rated 9.9 out of 10 and fixed for .NET 8, 9 and 10 only. Older versions were just as vulnerable, with no fix, and there was a less obvious problem: security scanners often didn’t flag them, because the official vulnerability listing only named the supported versions. Hayden Barnes put it plainly when I interviewed him about it on The Modern .NET Show:

Your scanner is not going to report the CVE in .NET 6 because the CVE doesn’t have 6 listed in the affected versions.

Over the next three months, four end-of-support dates arrive for widely used technologies:

• ✅ .NET 8 and .NET 9: November 10th, 2026
• ✅ PostgreSQL 14: November 12th, 2026
• ✅ PHP 8.2: December 31st, 2026
• ✅ Windows Server 2016: January 12th, 2027

The Modern .NET Show’s episode on the .NET 8 and .NET 9 deadline includes a summary written for exactly the people this post is for, and what it says applies to every date on that list:

On 10 November 2026, Microsoft stops publishing security fixes for .NET 8 and .NET 9. Applications built on those versions keep running. Nothing switches off, nothing expires, and no licence lapses. What stops is the supply of patches for problems found after that date.

Every one of those dates was published years in advance. With someone watching for them, they become planned upgrades with a budget and a timetable; one small business I worked with saved £25,000 by working through its options before Windows 10’s support deadline arrived. With nobody watching, each date turns into unplanned, urgent work.

That first deadline may matter sooner than it looks. On October 21st, 2026, the same day as php2shell, Node.js released a fix for CVE-2026-111497, which has been nicknamed Node2Shell. The flaw is in Brotli, a widely used library from Google for decompressing data. According to the Node.js security release, an attacker who can get an application to decompress specially crafted data “can corrupt process memory, which can lead to a crash, disclosure of process memory, or remote code execution”. According to GitHub’s advisory, Python’s Brotli packages were affected too, and fixed versions are available.

.NET bundles its own copy of Brotli, and according to the .NET runtime’s own source code, the copies in .NET 8, .NET 9 and .NET 10 all fall inside the affected range. At the time of writing, Microsoft hasn’t said whether .NET is affected, and hasn’t published a fix. If a fix is coming, its timing matters. As I pointed out in that episode of The Modern .NET Show, November 10th, 2026 is a Patch Tuesday, Microsoft’s regular monthly release day, as well as the day .NET 8 and 9 leave support. Microsoft’s end-of-support announcement says:

November 10th is a Patch Tuesday release day. .NET 8 and .NET 9 may each receive one final update on that day if there is a known critical issue.

If a fix for .NET arrives on or before that day, .NET 8 and 9 may get it. If it arrives later, they won’t. Someone in your business needs to know which of those versions you’re running.

“But We Paid Someone to Build It”

Most businesses that commission a website or application have no idea what it’s built on, and there’s no reason they should. You hired experts so that you wouldn’t need to know. The project ends, the invoice is paid, the site goes live, and as far as anyone in the business is concerned, the job is done.

The software keeps ageing after handover, though. A build contract pays for something to be made. Unless it says otherwise, nobody is being paid to watch for security advisories, apply updates, or warn you when a support window is about to close. The supplier assumes you’ll get in touch if you need anything; you assume the supplier would tell you if something were wrong. Both assumptions are reasonable, and the gap between them only becomes visible in a week like this one.

Some businesses have closed that gap without thinking of it in those terms. In a second video, Tanya Janca explained that websites hosted by WordPress.com were already protected, because WordPress.com had worked with the PHP security team ahead of the announcement. She hosts her own site there, and drew the conclusion I’d draw:

This is one of the reasons that managed hosting can be really valuable. Someone else is responsible for maintaining, patching, and staying up all night to make sure my infrastructure is safe.

A support contract closes that gap by writing down who does what. It can be small. What matters is that it names someone, says what they’ll watch, and agrees in advance what happens when something like php2shell lands on a Wednesday afternoon.

How Long You Have

When a serious flaw is made public, attackers move quickly. Patchstack, a company that sells protection for WordPress sites (so it has an interest in the answer), found that the most heavily targeted WordPress vulnerabilities of 2025 were typically under attack at scale within five hours of being made public, and that “approximately half of high impact vulnerabilities get exploited within 24 hours”.

Google’s Mandiant team goes further: its M-Trends 2026 report estimates the mean time to exploit at minus seven days, “meaning exploitation is routinely occurring before a patch is even released”. That figure is driven largely by attacks on network equipment using previously unknown flaws, so I’d read it as a direction of travel, and as a reason to patch quickly.

AI will speed this up, though probably less dramatically than some headlines suggest. In 2024, researchers at the University of Illinois found that an AI agent built on GPT-4 could exploit 87% of a set of 15 real vulnerabilities when it was given the public description of each one, and 7% without it. It was a small study, but the gap between those two numbers is the point: once a vulnerability is published, the description itself becomes the instructions. The same capability works for defenders. OpenAI was among the organisations that reported php2shell to PHP, Tanya Janca notes that researchers at Wiz used AI models to help find and validate the flaws, and the PHP project says it used AI tools in its own security work.

The NCSC’s assessment is more measured than most. It expects AI to make existing attack techniques faster and more effective, “rather than creating novel threat vectors”, and makes this judgement:

As there is a remote chance of universal access to AI for cyber security defence by 2027, there will almost certainly be a digital divide between systems keeping pace with AI-enabled threat, and a large proportion that are more vulnerable.

Whether your own systems keep pace depends mostly on whether somebody is watching them.

When the Argument Gets Stuck

Knowing about a vulnerability and getting a business to act on it are two different problems, and the second is often harder.

A previous client of mine had several .NET Core 2.1 applications among their systems, and almost all of them were reachable from the internet. When the Funky Chunks vulnerability was published, I suggested they look at upgrading the affected services. The first response was that nothing had been hacked yet, so there was no need. When I pointed to the severity score, the response was that the advisory only listed .NET 8, 9 and 10, so it wasn’t relevant to them.

Both objections were reasonable from where the client was sitting, and both were wrong. The advisory didn’t list .NET Core 2.1 because 2.1 was out of support, not because it was safe, and, as Hayden Barnes explained when I interviewed him about this vulnerability on The Modern .NET Show, their scanners were unlikely to flag it either. So I stopped arguing and showed them. Using a publicly available reproduction of the vulnerability, I demonstrated that their services were affected. (This kind of test should only ever happen with the system owner’s written permission and an agreed scope; done any other way, it’s an attack.) Then I wrote a ticket for each affected service, and attached a prompt for an AI coding agent that would explore each service’s code and plan its upgrade.

Only then did the client approve the work. The team lead had been convinced that upgrading everything would take several sprints, the two-week blocks many development teams plan their work in. It was finished in an afternoon.

What changed the client’s mind was evidence: their own systems, demonstrably vulnerable, with the work already broken down and sized. I’ve argued before that security can’t be a final exam you sit once a year, and this is why. Had nobody been watching for that vulnerability, nobody in the business would have known the upgrade was needed at all.

What a Support Contract Actually Covers

The details will differ between businesses, but a useful support arrangement covers at least these:

• ✅ An inventory. What your systems are built on, which versions, and where they run. If nobody has ever written this down, a software bill of materials is a good place to start.
• ✅ Someone watching. A named person or team who follows security advisories for the components in that inventory.
• ✅ A definition of urgent. Which issues count as emergencies, and how quickly someone responds when one arrives.
• ✅ Planned upgrades. Work scheduled and budgeted ahead of each end-of-support date, so that it never becomes an emergency.
• ✅ Tested restores. Backups that someone has actually restored from, recently.
• ✅ Authority to act. Who can decide to take a system offline, and who needs to be told when they do.

For UK businesses, much of this is also what Cyber Essentials expects. Under its current requirements, which apply to assessments started after April 26th, 2026, software must be “licensed and supported”; updates that the vendor describes as “critical or high risk” must be installed within 14 days of release; and software that becomes unsupported must be removed, or cut off from all traffic to and from the internet. A website still running PHP 8.1 couldn’t pass if it’s within the assessment’s scope, and php2shell, which PHP rated critical, falls squarely inside the 14-day rule.

Most businesses aren’t there yet. The government’s Cyber Security Breaches Survey 2025/2026 found that only 25% of businesses had a formal incident response plan, falling to 21% of micro businesses, while the share of businesses reporting that a breach or attack had led to a loss of revenue or share value rose from 2% to 5% in a year.

Questions to Take to Your Next Meeting

You don’t need to understand the technology to ask these. Take them to your next meeting with whoever built or looks after your website or application:

• ✅ Who watches security advisories for our systems, and how would they tell us about one that affects us?
• ✅ What are our systems built on, and which versions are we running?
• ✅ When does each of those leave support, and what’s the plan for each date?
• ✅ What counts as urgent, and how quickly do you respond to it?
• ✅ Who can decide to take something offline, and who needs to know?
• ✅ Is any of this in our current contract, and if not, what would it cost?

💭 Thought

When did anyone last restore your website or application from a backup, to prove that it works?

Find Out, Then Decide

None of this week’s incidents were anyone’s fault on the receiving end, and many businesses will come through them without harm. But each one was a reminder that software keeps needing care after it’s finished, and that the care only happens when someone has been asked to provide it. The answers to those six questions might be reassuring. They might show a gap you didn’t know you had. Either way, you’ll be deciding with the facts in front of you, instead of finding out in the middle of the next incident.

If you’d like help with that first conversation, or someone on your side of the table while you have it, I’d be happy to talk it through.