What Happened
CISA recently added three vulnerabilities to its Known Exploited Vulnerabilities Catalog: CVE-2026-20349 affecting Cisco Secure Firewall ASA and FTD products, CVE-2026-68820 in Windows Ancillary Function Driver for WinSock, and CVE-2026-72898 in Metabase. These additions confirm active exploitation in the wild.
The pattern is clear: organizations continue to leave known, exploited vulnerabilities unpatched on internet-facing systems, even when these vulnerabilities allow attackers total control.
Timeline
This isn't about a single incident but a recurring cycle affecting many organizations:
Day 0: Vendor publishes CVE and patch
Days 1-30: Vulnerability researchers and threat actors analyze the patch and develop exploits
Days 30-90: Exploitation begins in targeted campaigns
Day 90+: CISA adds the CVE to the KEV Catalog after confirming active exploitation
Months later: Organizations still haven't patched affected systems
By the time a vulnerability is in the KEV Catalog, you're already behind. The exploitation window has been open for weeks or months. Starting your patch evaluation when CISA publishes the KEV entry means your vulnerability management program has failed its primary function.
Which Controls Failed or Were Missing
The control failure is clear: organizations lack a risk-based vulnerability management process that prioritizes internet-facing systems and critical-severity issues.
Failures include:
Asset inventory deficiency: Teams didn't maintain an accurate, real-time inventory of internet-facing assets. You can't patch what you don't know exists. If your asset discovery process runs quarterly, you're working with stale data. Firewall appliances often live outside standard vulnerability scanning because teams treat them as infrastructure rather than endpoints.
Patch prioritization breakdown: Organizations used a calendar-based patch schedule instead of a risk-based one. Patching "the second Tuesday of each month" is inadequate for internet-facing assets with known exploits.
Exposure validation gap: Teams didn't verify which systems were publicly accessible. A vulnerability scanner might flag CVE-2026-68820 on a Windows server, but if that server sits behind three layers of network segmentation, it's not your immediate crisis. The same CVE on a jump box accessible from the internet is.
Compensating control absence: Where patching wasn't immediately feasible, organizations failed to implement temporary mitigations. Virtual patching through web application firewalls, network segmentation, or access restrictions could have reduced exposure while permanent patches were tested and deployed.
What the Relevant Standard Requires
Binding Operational Directive 26-04 establishes the federal expectation, and it's instructive even if you're not a federal agency. The directive requires:
Rapid remediation of high-risk vulnerabilities: CVEs listed in CISA's KEV Catalog on publicly exposed assets that grant total control post-exploitation must be prioritized. BOD 26-04 sets aggressive timelines tied to risk.
Compromise assessment before patching: If you're patching a system weeks or months after exploitation began, check whether threat actors already compromised it. Applying a patch to an already-compromised system doesn't remove the attacker's persistence mechanisms.
Risk-based prioritization over calendar-based patching: The directive tells agencies to defer action on lower-risk vulnerabilities while focusing resources on high-risk ones. This is the opposite of how many patch management programs work.
For non-federal organizations, ISO/IEC 27002 Control 8.8 requires you to obtain timely information about technical vulnerabilities, evaluate exposure, and take appropriate measures. The NIST Cybersecurity Framework 2.0 function "Protect" includes vulnerability management as a core component. SOC 2 criteria CC7.1 expects you to identify, report, and act upon security incidents and vulnerabilities.
None of these standards specify exact timelines, but they all require a risk-based approach. If you're treating a KEV-listed vulnerability on an internet-facing system the same as a medium-severity issue on an internal workstation, you're not meeting the control objective.
Lessons and Action Items for Your Team
If you're conducting an internal audit of vulnerability management, verify the following:
Check your asset inventory accuracy: Pull your list of internet-facing assets. Run an external port scan and compare results. Any discrepancies indicate your inventory is incomplete. Your vulnerability management program can't protect assets it doesn't know about.
Audit your patch timelines for KEV vulnerabilities: Review the last six months of KEV additions. For each one affecting your environment, document the date CISA added it to the catalog and the date you completed remediation. If you're consistently taking weeks to patch KEV vulnerabilities, your process needs restructuring.
Verify your risk scoring methodology: Many teams rely entirely on CVSS base scores, which don't account for whether a system is internet-facing or whether exploitation is occurring. Your risk model should weight exploitability and exposure alongside severity.
Test your compensating controls: For systems that can't be patched immediately due to operational constraints, document what temporary mitigations you deployed. Then test whether those mitigations actually work. A firewall rule that's supposed to block access but has an exception for "legacy applications" isn't a control.
Review your compromise assessment process: When you patch a system months after a vulnerability became known, do you check for indicators of compromise first? If not, you're potentially leaving attackers in place while congratulating yourself for patching.
The KEV Catalog isn't just a resource. It's a curated list of vulnerabilities that attackers are actively exploiting. If your patch management program treats KEV additions as routine updates rather than emergency response triggers, you're accepting unnecessary risk.
Start by subscribing to the KEV Catalog RSS feed. When a new entry appears that affects your environment, your security team should evaluate exposure within hours, not days. That's the operational tempo required to stay ahead of exploitation.
