The Challenge
In early 2025, CISA added six vulnerabilities to its Known Exploited Vulnerabilities catalog. What stood out wasn't the number of vulnerabilities, but their age. Four of the six CVEs dated back to 2015, 2019, and 2021. The oldest, CVE-2015-3246 and CVE-2015-5287, were a decade old.
For federal agencies under Binding Operational Directive 22-01, this meant addressing vulnerabilities that should've been patched years ago. CISA set remediation deadlines of August 29, 2026, for CVE-2019-1068 and CVE-2026-8452, and September 9, 2026, for the remaining four. That's a 22-month window to fix problems that have existed for up to ten years.
The technical scope was broad: Red Hat libuser race conditions, privilege escalation in Red Hat's Automatic Bug Reporting Tool, remote code execution in Microsoft SQL Server, deserialization flaws in Ajax.NET Professional, out-of-bounds writes in the Linux Kernel, and memory buffer issues in Citrix NetScaler ADC and Gateway. Each represented a different attack surface, but they shared a common trait: they were all exploitable, all known, and all still present in production environments.
The Environment and Constraints
Federal agencies operate under constraints that private organizations don't face. BOD 22-01 isn't a suggestion, it's a binding directive. When CISA adds a vulnerability to the KEV catalog, agencies must remediate it by the specified deadline. There's no negotiation or risk acceptance memo that makes the requirement go away.
The constraint isn't just regulatory. It's operational. These vulnerabilities exist in systems that often can't be patched without significant planning. A race condition in libuser affects authentication workflows. A SQL Server RCE flaw sits in databases supporting mission-critical applications. NetScaler appliances handle production traffic that can't tolerate unplanned downtime.
The 22-month timeline reflects this reality. Patching a 2015 Red Hat vulnerability in 2025 isn't just running an update script. It requires testing, change windows, rollback plans, and coordination across teams that may not have touched those systems in years.
For organizations pursuing SOC 2 Type II or ISO/IEC 27001 certification, this scenario exposes a gap between vulnerability scanning and vulnerability management. Your scanners find CVE-2015-3246. Your dashboard shows it as critical. But your remediation queue is sorted by CVSS score or exploit availability, not by whether the vulnerability appears in a regulatory catalog. By the time CISA adds it to the KEV, you're already behind.
The Approach Taken
CISA set staggered deadlines based on exploitation status. CVE-2019-1068 (the SQL Server RCE) and CVE-2026-8452 (the NetScaler memory buffer flaw) received the earlier August 29, 2026, deadline. CVE-2026-8452 "has been observed under active exploitation in the wild," explaining the prioritization.
The remaining four vulnerabilities, the two 2015 Red Hat flaws, the Ajax.NET deserialization issue, and the Linux Kernel out-of-bounds write, received the September 9, 2026, deadline. This 11-day gap signals that active exploitation drives urgency, but presence in the KEV catalog means remediation is mandatory regardless of whether you've seen exploit attempts in your environment.
Federal agencies responding to this directive need to:
- Inventory affected systems across their infrastructure
- Assess whether compensating controls reduce immediate risk
- Schedule patches in testing environments
- Coordinate change windows with application owners
- Execute remediation before the deadline
- Document completion for compliance reporting
This isn't just a vulnerability management workflow, it's a compliance-driven remediation project with a fixed deadline and regulatory consequences for failure.
Results and Metrics
The source article doesn't provide outcome data because these deadlines extend into 2026. What we know is the requirement: federal agencies must address these vulnerabilities by the specified dates to protect their networks against exploitation.
The effectiveness of this approach depends on two factors. First, whether agencies actually remediate the vulnerabilities before the deadline. BOD 22-01 created accountability, but compliance rates aren't published. Second, whether the 22-month timeline was sufficient given the operational constraints agencies face when patching legacy systems.
What's measurable now is the gap. If your organization runs Red Hat systems, Microsoft SQL Server, Ajax.NET Professional, Linux kernels, or Citrix NetScaler appliances, you can determine whether these six CVEs exist in your environment. That assessment takes hours, not months. The remediation is what consumes the timeline.
What They Would Do Differently
The federal government can't change its approach, BOD 22-01 is the framework. But organizations not bound by federal directives can learn from this scenario.
If you're managing compliance to ISO/IEC 27001 Clause 8.8 (management of technical vulnerabilities) or SOC 2 CC7.1 (detection of security events), your control design should account for regulatory catalogs like the KEV. Scanning for vulnerabilities is essential. Prioritizing remediation based on CISA's KEV additions, even if you're not a federal agency, aligns your risk treatment with observed threat activity.
The 22-month timeline also highlights a control design issue. If it takes your organization nearly two years to patch a known exploited vulnerability, your change management process (ISO/IEC 27001 Clause 8.32) or your configuration management controls (SOC 2 CC6.1) need revision. The timeline shouldn't be "how long until the deadline", it should be "how quickly can we reduce exposure after a vulnerability is confirmed exploited."
Organizations pursuing certification should also reconsider how they handle legacy systems. The two 2015 Red Hat vulnerabilities were a decade old when added to the KEV. If your asset inventory includes systems running software from 2015, your risk treatment plan needs to address why those systems can't be upgraded and what compensating controls you've implemented.
Takeaways for Your Team
Map your vulnerability management process to regulatory catalogs. CISA's KEV isn't just for federal agencies. If a vulnerability is actively exploited, it's a priority regardless of your industry. Your scanning tools should flag KEV-listed CVEs automatically, and your risk treatment plan should document how you respond when new entries appear.
Test your remediation timeline against realistic constraints. The 22-month deadline for these six vulnerabilities reflects the operational reality of patching production systems. If your documented vulnerability management procedure claims you'll remediate critical vulnerabilities within 30 days, test that claim against a legacy system running a decade-old OS. The gap between policy and capability is where audit findings live.
Treat legacy systems as a compliance risk, not just a security risk. ISO/IEC 27001 Clause 5.1 requires top management to demonstrate leadership and commitment to the ISMS. If your organization is operating systems from 2015 that can't be patched without multi-year planning, that's a risk treatment decision that belongs in your risk register, with documented acceptance and compensating controls. It's not an IT operations issue, it's a governance issue.
Don't wait for CISA to tell you what's exploited. The NetScaler vulnerability was already under active exploitation when added to the KEV. Your threat intelligence feeds and your security monitoring should detect exploitation attempts before a regulatory catalog formalizes the priority. If you're learning about active exploitation from CISA announcements, your detection controls need strengthening.
The six vulnerabilities CISA added to the KEV catalog aren't remarkable because they're sophisticated or novel. They're remarkable because they're old, exploitable, and still present in production environments. That's the compliance challenge: not discovering new threats, but finally addressing the ones you've been carrying for years.
