Summary
- AI penetration-testing firm Terra Security found that GitHub security advisories reporting a failed patch within 90 days jumped from roughly 0.2 percent (2019–2025) to 2.3 percent in 2026.
- Vulnerabilities with bypassed fixes are approximately four times more likely to appear on CISA’s Known Exploited Vulnerabilities list than other bugs from the same vendors.
- Server-side request forgery and prototype-pollution patches fail most often, largely because blocklist-based mitigations cannot anticipate every encoding of a malicious input.
- Linux kernel fixes introduce new CVEs at a rate of 3.2 percent overall, rising to around 10 percent in high-activity subsystems such as fs/smb and net/sched.
- Terra researchers advise treating every patch for an actively exploited bug as a target for immediate bypass research — because adversaries already are.
The numbers behind a quiet trend
For six years, the rate at which published security fixes were subsequently bypassed held steady at a low baseline. That changed markedly in 2026. Terra Security, an AI-focused penetration-testing startup, reviewed every published CVE record and GitHub-reviewed advisory searching for broken fixes, and found what it describes as a distinct pattern: the share of GitHub security fixes that required a follow-up advisory within 90 days — indicating the original patch had failed — climbed from approximately 0.2 percent to 2.3 percent this year. The researchers note it is not coincidental that AI-assisted vulnerability discovery and patching also accelerated in the same period.
A concrete example
The research points to a real-world illustration. Russian government cyber-espionage actors exploited a zero-day Windows Shell security bypass, CVE-2026-21510, for at least a month before Microsoft issued a patch in February. That fix turned out to be incomplete. It left a second vulnerability — a zero-click authentication coercion flaw tracked as CVE-2026-32202 — which was itself discovered and exploited before Microsoft addressed it in April. The sequence, patch followed by bypass followed by another patch, is precisely the pattern Terra’s broader data captures.
Which bug classes break the most
Not all vulnerability types are equally prone to incomplete fixes. According to Terra, prototype-pollution vulnerabilities appear among broken-fix CVEs at roughly 11 times the rate their overall share of CVEs would predict. Server-side request forgery patches break at 4.6 times the expected rate. The underlying reason is structural: both classes are commonly mitigated using reject-lists — blocklists of hostnames, paths, or object keys — rather than fixes that address the root cause. As the researchers put it, if the blocklist does not anticipate every encoding of a bad input, an attacker only needs to find one that slips through.
The Linux kernel’s particular challenge
The Linux kernel presents an additional dimension of the problem. Based on kernel CNA records as of 8 October, Terra found that 3.2 percent of kernel CVEs were themselves introduced by the fix for a prior CVE. In busier subsystems — specifically fs/smb and net/sched — that figure rises to around 10 percent. For organisations running Linux infrastructure, this means that applying a patch can, in a non-trivial proportion of cases, introduce a new exposure rather than simply remove one.
The exploitation premium on broken fixes
Perhaps the most operationally significant finding for CISOs is the relationship between patch quality and exploitation rates. Terra found that CVEs whose fixes were later bypassed were about four times as likely to appear on CISA’s Known Exploited Vulnerabilities list as other bugs affecting the same vendors. This suggests adversaries are actively scrutinising patches — particularly for high-profile or widely deployed software — looking for residual attack surface the fix left behind.
What Terra recommends
The researchers frame the problem as a cultural one as much as a technical one: both vendors and network defenders need to move past what they call the ‘patch and move on’ habit. For software vendors, they propose three questions before shipping a fix: Does it address the root cause? Does it cover the entire bug class, not just the reported instance? Does it introduce new problems? For patch managers and sysadmins, the same questions apply before deploying a vendor fix. The overriding principle the researchers offer is direct: if a vendor fixes an exploited bug, assume someone is already reading that patch looking for a way around it.
Why it matters
CISOs have long treated patching as the definitive response to a disclosed vulnerability. This analysis challenges that assumption. A rising share of patches — particularly for high-severity, actively exploited bugs — are incomplete, and the window between patch release and bypass discovery appears to be compressing as AI tooling improves adversary research capability. The fourfold exploitation premium on broken fixes means that vulnerability management programs built around CVSS scores and patch cadence alone may be systematically underestimating residual risk. Organisations that apply a fix and remove an asset from their watch list may be doing so prematurely.
What to do now
- After applying a vendor patch for any actively exploited vulnerability, retain that asset on your monitoring and threat-hunting list rather than closing the ticket — assume the fix may be incomplete.
- When evaluating patches for server-side request forgery or prototype-pollution vulnerabilities, scrutinise whether the fix addresses root cause or relies solely on a blocklist, and apply additional controls accordingly.
- Track CISA’s Known Exploited Vulnerabilities list with specific attention to CVEs that have already had one patch cycle, as these carry a meaningfully higher exploitation risk per Terra’s findings.
- For Linux environments, review kernel CNA records before deploying kernel patches, paying particular attention to updates affecting the fs/smb and net/sched subsystems given the elevated rate of fix-introduced CVEs in those areas.
- Raise the question of fix completeness — root cause addressed, full bug class covered, no regressions — as a standard part of your patch review process before deployment.
