Most vulnerability programmes end the same way. The scanner stops reporting the CVE, the ticket closes, and the dashboard turns green. New research suggests that for the bugs attackers care about most, that's exactly the moment to start paying attention.
On 19 October, Oren Yomtov at Terra Security published a study of security fixes that didn't work, covered by Help Net Security the next day. He went through published CVE records and GitHub-reviewed advisories looking for one pattern: a fix ships, then a later advisory says it was incomplete or could be bypassed. Two findings stand out.
- Fixes for bugs on CISA's Known Exploited Vulnerabilities (KEV) catalogue are later reported broken about four times as often as fixes for other bugs from the same vendors.
- In 2026, the share of open-source fixes later reported broken rose about eightfold, after years at a low, steady rate.
The likely explanation for the first is attention. When a bug is being exploited, attackers and researchers read the patch closely. A fix tells you exactly where the problem was and how the developer closed it. If it only blocked the reported case, the neighbouring cases are a short walk away.
What a broken fix looks like
The study's Windows example is a useful one for anyone running a Microsoft estate. CVE-2026-21510, a Windows Shell flaw exploited by APT28, was patched in February. Akamai then found that a crafted Control Panel item could get around the fix and make Windows connect to an attacker's server, leaking the user's NTLM hash. Microsoft fixed the bypass in April as CVE-2026-32202, which also went on the KEV list. The new advisory didn't mention the old CVE.
That last detail matters more than it looks. To a patch-tracking process, CVE-2026-32202 is just another April update. Nothing tells you that the February fix you marked as done had stopped working, or that attackers already had a working technique against it.
The open-source example follows a pattern you'll recognise. A fix for server-side request forgery blocked links to 127.0.0.1 and nothing else. It missed the same address written in decimal, hex or shortened form, and domain names that resolve to it. Three more CVEs followed over the next five months. Blocklist-style fixes like this are heavily over-represented among the broken ones.
Why this changes how we think about patching
We argued last week that patch lists don't scale and exploitability does: with well over a thousand CVEs a month, the question is which ones attackers are actually using. This research adds a second half to that argument. The bugs that are being exploited are also the ones most likely to need patching twice.
So for a KEV-listed vulnerability, "patched" should mean something different from "the scanner is happy". Our view is that it should mean three things:
- The fix is installed. That's the part everyone already measures.
- The behaviour is still being watched. The detection you put in place while the bug was unpatched shouldn't be switched off when the patch lands. If the fix is bypassed, the attacker's next move will look much like their last one. In the Windows Shell case, an unexpected outbound SMB or WebDAV connection to the internet is the tell either way.
- The control has been tested since. Re-running the technique, or a close variant of it, against a patched system is the only way to know the patch does what you think.
None of that needs exotic tooling. It needs the habit of treating a patch for an exploited bug as the start of a test, not the end of a task.
What to do this quarter
- Keep a list of the exploited bugs you've patched in the last 12 months. When a new CVE arrives in the same component, check whether it's a bypass before you file it as routine.
- Keep the hunting queries and analytic rules you wrote for exploited bugs running after the patch. Retire them on evidence, not on a calendar.
- Prefer root-cause mitigations over blocklists where you have a choice. Blocking outbound SMB to the internet, for example, defuses a whole family of NTLM-leak bugs, patched or not. We explained why in The October Update Didn't Break Your Wi-Fi.
- Test controls against techniques, not CVE numbers. Breach and attack simulation and purple team exercises check whether the attack still works, which is the question that matters.
- Ask your software suppliers how they review fixes for exploited bugs. Root cause, whole bug class, and what else the change touches are reasonable questions.
Where a managed SOC fits
A green dashboard is a statement about patches. A SOC's job is to make a statement about attacks. When an exploited bug is patched, our analysts keep watching for the behaviour it enabled, and when a bypass is published we hunt for it across your estate rather than waiting for the next patch cycle. Our SOCs are manned 24/7, with senior analysts and incident responders on shift around the clock, and CYBERSHIELD AI's Investigation Agent works each alert to a verdict in an average of 3m 30s.
If your patching reports look healthy but you're not sure the attacks they cover have actually stopped working, book a demo and we'll show you how we close that gap.