Security Patches Are Breaking 10x More Often - Why ‘Patch and Move On’ No Longer Works

For six years, security patches that needed patching were rare. AI penetration–testing firm Terra Security reviewed every published CVE record and GitHub–reviewed security advisory and found that, between 2019 and 2025, roughly 0.2% of fixes needed a follow–up advisory reporting a failed patch within 90 days. In 2026, that figure jumped to 2.3% — more than ten times higher. Terra summarised the pattern bluntly: “A fix would ship, a bypass would be found, and another fix would go out.”

The finding that matters most for defenders is what happens to those bugs next. Vulnerabilities whose fixes were later bypassed were about four times as likely to appear on the US Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities list as other bugs from the same vendors. Reporting on the research links the jump to attackers using AI to examine patches the moment they ship; Terra’s data shows the pattern clearly, while the cause remains an inference. Either way, the practical conclusion for UK businesses is the same, and it is not “stop patching” — patching remains essential. It is that “patch and move on” is no longer enough for the bugs that matter most. When a vendor fixes something that is being actively exploited, Terra’s advice is to “assume someone is reading the patch for a way around it”.

What Terra Security found

Terra’s headline measure is simple. For each published fix, did a follow–up advisory appear within 90 days reporting that the patch had failed? From 2019 to 2025 the answer was yes for about one fix in five hundred. In 2026 it was yes for about one in forty. The rise came after six years of stable, low numbers, which is what makes it notable: this is not a gradual trend but a step change.

Broken fixes are not evenly distributed. Fixes for server–side request forgery (SSRF) and prototype pollution broke most often. Prototype–pollution vulnerabilities were about 11 times as common among broken–fix CVEs as their share of all CVEs would predict, and SSRF vulnerabilities about 4.6 times. Terra attributes this to a common way of fixing them: a reject–list of inputs such as hostnames, paths and object keys. “If the blocklist doesn’t foresee every encoding of a bad input, the attacker only needs to find one.”

Fixes can also introduce new problems. Terra found that 3.2% of Linux kernel CVEs were introduced by the fix for another CVE, rising to about 10% in busy subsystems such as fs/smb and net/sched. In other words, in the most active parts of the kernel, roughly one vulnerability in ten was created by a previous security fix.

The real–world example cited in the reporting shows the cycle in action. Russian government cyberspies, according to the reporting, exploited a zero–day Windows Shell security bypass, CVE–2026–21510, at least a month before Microsoft patched it in February 2026. That patch was incomplete. It left a second flaw — a zero–click authentication coercion vulnerability, CVE–2026–32202 — which was also found and abused before Microsoft fixed it in April 2026. For organisations that applied the February patch and considered the matter closed, the exposure continued for another two months.

Terra’s recommendations are the same three questions for vendors and for the people applying patches: does the fix address the root cause, does it cover the whole bug class, and does it break something else? For patch managers, it adds a working assumption for any fix to an exploited bug: someone is reading the patch for a way around it.

How the patch cycle changed

The chronology below combines Terra’s data with the Windows Shell example from the reporting. It shows a long, stable period followed by a sharp change.

The Windows Shell case is the clearest illustration of why this matters to an ordinary business. The first patch was real and worth applying; it closed the original hole. But it was not the end of the exposure, and the gap between the first and second fixes was long enough for attackers to use. A patch management process that recorded the February update as “done” had no reason to look again. One that treated an exploited bug as an open item until the vendor had stopped issuing related fixes would have been watching.

What helps once a patch is applied

The chart below is an indicative planning model — not measured data — ranking practices by how much they reduce exposure to incomplete or bypassed fixes, particularly for bugs that are already being exploited.

The top two bars are the direct response to Terra’s findings. Patching quickly still matters most — nothing in the research suggests waiting — but for bugs that are being exploited, the patch becomes the start of a watch period rather than the end of the task. A follow–up advisory within 90 days is exactly what Terra measured, and checking for one is how a business finds out that a fix it already applied was incomplete.

The fourth bar addresses the reject–list problem. If a vendor fixes an SSRF or input–handling flaw by blocking known bad inputs, the risk is that an attacker finds an encoding the list did not anticipate. Keeping other layers in place — restricting what the affected system can reach, filtering traffic, limiting exposure to the internet — means that a bypass of the patch does not immediately become a breach. Compensating controls are often removed once a patch is applied; Terra’s data is a reason to leave them on for longer.

The sixth bar reflects Terra’s third question, about side effects. The Linux kernel finding — that in busy subsystems around one CVE in ten was introduced by a previous fix — is a reminder that patches can introduce problems as well as remove them. For most small businesses, the practical form of this is testing important updates on a non–critical system first where possible, without letting testing become a reason for long delays on exploited bugs.

One in ten, in the busiest parts of the kernel

The most striking number in Terra’s research is not about bypasses at all. It is about fixes that create new vulnerabilities.

Across the Linux kernel as a whole, Terra found that 3.2% of CVEs were introduced by the fix for another CVE. In the busiest subsystems, the figure rose to about one in ten. That is not evidence that patching is harmful — the vulnerabilities being fixed are real and usually more serious than the side effects. It is evidence that complex, heavily changed code is hard to fix without creating new problems, and that the most active parts of a system are where that risk concentrates.

For a business, the implication is about where to pay attention. Not every patch deserves the same scrutiny. The ones that do are fixes to exploited bugs, fixes in heavily used and frequently changed components, and fixes for bug classes that Terra identifies as prone to incomplete repair — SSRF and prototype pollution, typically fixed with reject–lists. Those are the cases where a follow–up advisory is most likely, and where keeping compensating controls in place is most worthwhile.

It also explains why Terra’s three questions are aimed at both vendors and patch managers. A vendor can ask whether its fix addresses the root cause and the whole bug class before shipping. A business applying the fix cannot audit the code, but it can ask the practical version of the same questions: has the vendor said this is a complete fix? Is this a bug class known for incomplete repairs? And have we checked that the update has not broken something important?

Where UK businesses are exposed

The rows below reflect where patch–management assumptions typically leave a UK SME exposed to incomplete or bypassed fixes, with badges indicating how much attention each usually needs.

The last row is marked low not because delay is unimportant but because it is the wrong lesson to draw from this research, and worth calling out explicitly. Terra’s findings do not support waiting to patch in case the fix is incomplete. An incomplete fix still closes part of the exposure, and a bypass usually needs further work by an attacker. The right response is to patch exploited bugs promptly and keep watching, not to hold back.

The third row is where many organisations quietly reintroduce risk. During an active exploitation scare, they add temporary protections — blocking access to a service, restricting it to certain networks, adding filtering rules. When the patch arrives, those protections are removed to restore normal operation. Terra’s data suggests that, for exploited bugs, it is often worth keeping them for some weeks after patching, until it is clear the vendor’s fix has held.

What a better patch process costs

The bands below are indicative planning figures for UK businesses adapting patch management to the risk of incomplete fixes — not quotes.

The bottom row is free and directly reflects Terra’s 90–day measure. Take the exploited vulnerabilities your organisation has patched recently — the ones that came with urgent advisories — and check whether the vendor has published anything further about them. Most of the time there will be nothing new. Occasionally there will be a follow–up fix you did not know about, and finding it this way is far better than finding it through an incident.

Two ways to manage patches

The right–hand column does not ask a small business to analyse patches or second–guess vendors. It asks for two things the left–hand column lacks: memory and depth. Memory, in the sense of remembering that a critical bug was exploited and checking back on it. Depth, in the sense of not relying on a single fix as the only thing standing between an attacker and the system. Both are ordinary disciplines; Terra’s data simply makes them more important than they were a year ago.

Why this changes the economics of patching

For years, patch management has been framed as a race: how quickly can an organisation apply a fix after it is released? That framing is still correct as far as it goes. Terra’s findings add a second dimension. For a growing share of the most important vulnerabilities, the first fix is not the last, and the period after patching is a period of continued risk rather than safety.

The reporting connects this to attackers using AI to examine patches as soon as they are published. A patch is, among other things, a precise description of where a vulnerability was. Comparing the code before and after a fix has long been a technique for understanding what was wrong; tools that make that comparison faster and more thorough make it more likely that any gap left by the fix is found quickly. Terra’s data does not prove that mechanism, but it is consistent with it, and the defensive response is the same either way.

There is a parallel with other list–based defences. Terra’s explanation for why SSRF and prototype–pollution fixes break — reject–lists that do not anticipate every encoding of a bad input — is the same weakness as browser lookalike–domain checks that are bypassed by characters nobody listed. Defences that enumerate what is bad are always one discovery behind. Defences that restrict what is allowed, or that add independent layers, hold up better.

For organisations pursuing Cyber Essentials, the scheme’s requirement to apply high–risk and critical updates promptly remains the foundation, and nothing here weakens it. What Terra’s research adds is a reason to treat a critical update as a continuing item rather than a single event — checking for follow–up fixes and keeping the secure configuration and boundary controls that the scheme also requires in place, so that one incomplete patch does not become an open door.

The story at a glance

This story connects to several we have covered recently. The Cisco email gateway zero–day was the second similar email–to–root flaw in the same product in two months — a reminder that critical products can need repeated emergency attention. The actively exploited Citrix NetScaler flaws showed exploitation beginning before disclosure. The Chromium lookalike–domain research is the clearest parallel to Terra’s reject–list finding: defences that list known–bad inputs are always one discovery behind. Our piece on the end of security through obscurity covers how AI changes what attackers can find. The building–system ransomware piece concerns systems that are hard to patch at all. And the ConnectWise suspension shows why cleanup after a compromise must go further than removing the obvious entry point.

Frequently asked questions

Cloudswitched

London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.