The share of security fixes on GitHub requiring a follow-up advisory for a failed patch within 90 days jumped to 2.3 percent in 2026, up from about 0.2 percent between 2019 and 2025, according to a report published October 19 by Terra Security, an AI penetration-testing startup. After six years of relatively stable numbers, the firm found a distinct pattern emerging this year: "A fix would ship, a bypass would be found, and another fix would go out." The researchers say the timing isn't accidental—AI-powered vulnerability discovery and patching also surged in 2026.
Terra's researchers examined every published CVE record and GitHub-reviewed advisory looking for broken fixes. Vulnerabilities whose patches were later bypassed showed up on the US Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities list about four times as often as other bugs affecting the same vendors, according to Terra. Server-side request forgery fixes and prototype-pollution patches break the most: compared with their share of all CVEs, prototype-pollution vulnerabilities were roughly 11 times as common among broken-fix CVEs, while server-side request forgery vulnerabilities were 4.6 times as common. Linux kernel vulnerabilities also prove troublesome—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 report cited Russian government cyberspies exploiting a zero-day Windows Shell security bypass bug, CVE-2026-21510, at least a month before Microsoft patched the flaw in February. Microsoft's patch was incomplete and left a second flaw—a zero-click authentication coercion vulnerability (CVE-2026-32202)—that was also found and abused before the company fixed it in April.
The report attributes the high failure rate for certain bug classes to the way developers fix them: 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. This approach leaves gaps that adversaries can exploit by finding alternate encodings or edge cases the original patch didn't anticipate.
The researchers call the findings a wake-up call for software vendors and network defenders to abandon the "patch and move on habit." Before shipping patches, software vendors should consider three questions: Does it fix the root cause? Does it cover the whole bug class? Does it break something else? System administrators and patch managers should ask the same questions before applying fixes. "If a vendor fixes an exploited bug, assume someone is reading the patch for a way around it," the pen testers advise. The takeaway is clear: security teams can no longer treat patching as a one-and-done task when attackers now have automated tools to spot weaknesses in the fixes themselves. Organizations that treat every patch as potentially incomplete may need to monitor for exploitation attempts even after updates are applied, fundamentally changing the operational calculus around vulnerability management.