Security patches need patches now that attackers have AI

Terra finds sharp rise in GitHub security fixes reported broken within 90 days

Updating your software only gets you so far. A scary scenario - security fixes themselves being bypassed - is becoming more common, according to AI penetration-testing startup Terra Security, which found a sharp rise in reported patch failures in 2026 after years of relatively low numbers.

And no, it’s not a coincidence that AI vulnerability discovery and patching also exploded this year.

For example, Russian government cyberspies exploited a zero-day Windows Shell security bypass bug, CVE-2026-21510, at least a month before Microsoft patched the flaw in February. Redmond’s patch, however, was incomplete, and left a second flaw - a zero-click authentication coercion vulnerability (CVE-2026-32202) - that was also found and abused before Microsoft fixed it in April.

REG AD

Terra researchers reviewed every published CVE record and GitHub-reviewed advisory looking for broken fixes, and found a distinct pattern. After six years of relatively few patch bypasses, this changed in 2026: “A fix would ship, a bypass would be found, and another fix would go out.”

REG AD

The share of GitHub security fixes that required a follow-up advisory reporting a failed patch within 90 days remained at about 0.2 percent between 2019 and 2025. This year, this figure had jumped to 2.3 percent, according to the researchers.

Meanwhile, vulnerabilities whose fixes were later bypassed were about four times as likely to appear on the US Cybersecurity and Infrastructure Security Agency's (CISA's) Known Exploited Vulnerabilities list as other bugs affecting the same vendors, according to Terra.

Of these, server-side request forgery fixes and prototype-pollution patches break the most. Compared with their share of all CVEs, prototype-pollution vulnerabilities were about 11 times as common among broken-fix CVEs, while server-side request forgery vulnerabilities were 4.6 times as common, according to Terra.

This has to do with the way these types of bug classes are fixed: using a reject-list of inputs such as hostnames, paths, and object keys. There’s a “simple” reason for this, according to Terra.

“If the blocklist doesn't foresee every encoding of a bad input, the attacker only needs to find one,” the researchers said.

Fixes for Linux kernel vulnerabilities are also more likely to cause new bugs, according to kernel CNA records as of October 8.

“In fact, 3.2 percent of kernel CVEs were introduced by the fix for another CVE, and about 10 percent in busy subsystems like fs/smb and net/sched,” the bug hunters noted.

The silver lining in all of this, we’re told, is that it should be a wake-up call for software vendors and network defenders to break the “patch and move on habit.” Instead, before shipping patches, software vendors should consider three questions:

REG AD

1. Does it fix the root cause? 

2. Does it cover the whole bug class? 

3. Does it break something else? 

And for sysadmins and patch managers: consider the same things before applying the fix. “If a vendor fixes an exploited bug, assume someone is reading the patch for a way around it,” the pen testers advise. ®