Security updates are vital in keeping software secure and users safe, but they could also act as a map for hackers to find weak spots in code, including subsequent patches.

That’s according to research from Terra Security, which said the rate of patches later reported to be broken has surged from a “low, steady rate” by eight times.

“Software security fixes are both bug closers and maps: they show where a given bug used to live and how the developer chose to close it,” Terra security researcher Oren Yomtov noted in a blog post. “Narrowing down the fix so that it only blocks the reported case can point the next attacker toward undefended gaps around the repair.”

While Terra didn’t pin the leap in patches needing patching on AI directly, the jump happened this spring, as security models such as Anthropic’s Claude Mythos and OpenAI’s GPT-5.5-Cyber were announced, though were only released later and in a restricted way to approved partners.

That said, AI has unquestionably led to a boom in the number of flaws being spotted this year.

Spotting broken patches

Terra noted this pattern of patches requiring subsequent fixes in its own efforts over the last year, with bypasses quickly found, necessitating yet another patch. To check that this wasn’t simply the company’s own experience, Terra researchers looked at every flaw listed in the CVE system as well as GitHub advisories.

Researchers noted it wasn’t just Terra seeing an increase in patches requiring fixes.

“Broken fixes have been reported for years at a low, steady rate until 2026, when the share of open-source fixes on GitHub later reported broken rose about eightfold,” Yomtov said.

A chart shared in Yomtov’s blog post showed reports of open source fixes that needed their own patches within 90 days jumped from below 0.5% to 2.3% in a matter of months, with the leap happening after March 2026.

“The CVE record database gives much wider coverage than our GitHub data and shows the same jump in the same year,” Yomtov added.

He added that patches for bugs on the known-exploited list are four times as likely to be reported as broken as flaws from the very same vendors.

“The likely reason is attention: exploited bugs draw more researchers, who study the patch and find what it missed,” he added.

What can be done?

Security teams should be aware that patched flaws may still remain a vulnerability, according to Yomtov.

“The upshot is that the “patch and move on” habit is a bad one, especially for the bugs that matter most,” he noted.

Yomtov added that one of the most common types of broken fixes are server-side request forgery and prototype pollution, where the usual solution is to create a list of inputs to automatically reject.

“The reason is simple: if the blocklist doesn’t foresee every encoding of a bad input, the attacker only needs to find one,” Yomtov added.

Beyond that, this technique for addressing flaws highlights what’s broken to would-be attackers. As Yomtov noted, a patch that only blocks reported inputs can “give the impression the bug is addressed”, even if it’s still present in the underlying code.

“It functions as a map for attackers, marking out both vulnerable code and what the defender thought the bug was.”

That means that security professionals should look “just outside the diff” – as opposed to looking only at the code that was changed – in order to spot potential problems. Calling it the “cheapest form of bug hunting,” Yomtov added: “We believe a growing share of attacker effort, and AI tokens, goes into exactly this.”

Because of that, he advises security pros should “diff-hunt your own fix before shipping it,” as attackers certainly will, taking into consideration whether the patch actually fixes the root cause – rather than merely blocking one input – and whether it covers the whole bug class or might break anything else.

“The same goes for patches you install,” he adds. “If a vendor fixes an exploited bug, assume someone is reading the patch for a way around it.”

FOLLOW US ON SOCIAL MEDIA