Terra Security, a penetration testing firm, went through every published CVE record and every GitHub-reviewed security advisory looking for one pattern: a fix ships, then a later advisory says that fix was incomplete or could be bypassed. The Register covered it yesterday under the headline "Patches need patches now that attackers have AI".

What the research found

For several years, broken fixes were reported at a low, steady rate. In 2026 that changed. According to Terra, the share of open-source fixes on GitHub later reported as broken rose about eightfold.

A few other numbers stood out to me:

  • Fixes for bugs that were already being exploited (the ones on the US CISA Known Exploited Vulnerabilities list) were later reported broken about four times as often as the same vendors' other bugs.
  • In the Linux kernel, about 3.2% of CVEs were introduced by the fix for another CVE. In some busy parts of the kernel it's closer to 10%.
  • Two types of bug, server-side request forgery and prototype pollution, turn up far more often among broken fixes than you'd expect.

The Register links the timing to the surge this year in AI being used to find vulnerabilities. More eyes, and more automated eyes, are reading every patch that goes out. Terra's advice to anyone installing updates is blunt: when a vendor fixes an exploited bug, "assume someone is reading the patch for a way around it."

Why fixes go wrong

The explanation is refreshingly unglamorous. A lot of broken fixes block the exact thing that was reported, rather than the underlying problem.

Here's a simple example of the kind of thing the research describes. Say your app fetches a web address supplied by a user, and someone shows it can be tricked into reading your own internal server at 127.0.0.1. The quick fix is to block "127.0.0.1". But the same address can also be written as 127.1, or 2130706433, or as a domain name that points back to it. Block one spelling and the attacker just uses another.

That's a blocklist, and blocklists are only as good as your imagination on the day you wrote them. Terra puts it well: if the list doesn't foresee every encoding of a bad input, the attacker only needs to find one.

What this means if you're a small business

You're probably not patching the Linux kernel yourself. But if you have a bespoke system, a Shopify app someone built for you, or an app you put together with an AI tool, the same thinking applies. Here's what I'd take from it.

Fix the class, not the instance. When a bug turns up in your own software, the useful question isn't "is this input blocked now?" It's "what kind of mistake let this happen, and where else have we made it?" If one form can be abused, check the others that use the same code.

Be wary of fixes that just add to a list. If the fix for a security problem is a list of banned values, ask whether it could be turned round into a list of allowed ones instead. Only accepting what you expect is much harder to get round than trying to reject everything you don't.

Be specific when you ask AI to fix things. If you're using an AI coding tool, "fix this bug" will get you a fix for the bug in front of it. Ask it to find every other place the same pattern appears, and then check that it actually did. Better still, get a human who understands the code to look at anything security related before it goes live.

One update isn't the end of it. If a library, plugin or server package you rely on gets an urgent security fix, expect there may be a follow-up. Keep an eye on it for the next few weeks rather than ticking it off and forgetting about it. This is where patching on a schedule beats patching when someone remembers.

Test after the scanner says you're fine. Terra makes this point too. A clean scan tells you the known problem has gone. It doesn't tell you the hole is closed.

The boring bit that actually matters

None of this needs a big security budget. It needs someone who knows your systems, looks at updates when they land, and asks the awkward "what else?" question when something gets fixed. In a big company that's a whole team. In a firm of 20 people it's often nobody in particular, which is how things slip.

That's the gap our software support and maintenance plans are there to fill: security patching for frameworks and dependencies, monitoring, and tested backups, with a named person who knows your code. If it's servers rather than code, our Linux server management applies security updates on a schedule. And if you've built something with Lovable, Bolt, Cursor or similar and you're not sure how well its security fixes hold up, an AI code audit gives you a plain-English report and a prioritised list of what to fix.

If you'd rather just have a chat about where your software stands, drop us a line or give us a ring on 01474 639 089. No hard sell, I promise.

Cheers, Rob