Skip to main content
a promotional graphic telling you that PCI Compliance is no longer an annual exercise and that continuous monitory must be built in
Two Citrix Flaws Join CISA's KEV: What Went WrongPrivacy and Security
5 min readFor Risk Managers

Two Citrix Flaws Join CISA's KEV: What Went Wrong

The Challenge

When CISA added CVE-2026-88771 and CVE-2026-88772 to its Known Exploited Vulnerabilities (KEV) Catalog, organizations using Citrix NetScaler faced an urgent problem: moving from awareness to remediation before threat actors exploit these vulnerabilities.

These vulnerabilities, one involving improper input validation and the other concerning memory buffer operations, are flagged as frequently exploited. For any organization running NetScaler, their addition to the KEV Catalog signals active exploitation, not just theoretical risk.

The challenge isn't technical complexity. You know you need to patch. The real issue is prioritizing within an already overwhelmed vulnerability management queue. Most security teams track hundreds or thousands of CVEs. Without a systematic triage approach, critical vulnerabilities compete for attention with lower-risk issues that simply arrived first.

The Environment and Constraints

Federal Civilian Executive Branch agencies follow Binding Operational Directive 26-04, which mandates rapid remediation of high-risk vulnerabilities, especially those in CISA's KEV Catalog on publicly exposed assets. Lower-risk vulnerabilities can be deferred.

For non-federal organizations, there's no such mandate. You're left to build your own prioritization framework, often relying on CVSS scores or vendor ratings. These methods don't account for active exploitation, the most predictive factor for impact.

Constraints include limited patch windows, production dependencies, change management requirements, and the risk of disrupting critical services. NetScaler devices often sit at network perimeters or handle authentication flows, requiring careful coordination across teams. You can't just push updates during business hours.

Meanwhile, threat actors don't wait. Evidence of active exploitation means attackers have working code and are scanning for vulnerable instances. The window between KEV addition and widespread exploitation can be days, not weeks.

The Approach Organizations Should Take

The KEV Catalog provides a clear signal: CISA confirms active exploitation. Your response should treat KEV additions differently from routine disclosures.

First, set up an automated alert for KEV updates. CISA publishes the catalog in machine-readable formats. Your vulnerability management platform should ingest KEV data and flag any CVEs in your environment that match new additions. Manual monitoring introduces dangerous delays.

Second, create a separate remediation track for KEV vulnerabilities that bypasses standard queues. BOD 26-04's approach is a useful model: vulnerabilities on publicly exposed assets that grant total control post-exploitation get immediate attention. For the Citrix flaws, identify every internet-accessible NetScaler instance and treat those as priority-one targets.

Third, implement pre-patch compromise assessment. BOD 26-04 expects agencies to check for compromises before applying patches. This isn't paranoia; it's recognizing you might be responding to an incident, not just a vulnerability. Review authentication logs, check for unauthorized changes, and examine outbound connections from affected devices before patching.

Fourth, document your asset inventory with enough detail to answer "do we run this?" within hours. When CISA adds a Citrix vulnerability to the KEV, you need to know immediately if you operate NetScaler devices, which versions, and whether they're internet-facing. Configuration management databases and asset inventories are only useful if they're current and queryable.

Results and What's Measurable

Organizations adopting KEV-driven prioritization can measure several outcomes. Time-to-remediation for KEV vulnerabilities should be faster than your average patch cycle. If your standard patching SLA is 30 days but KEV vulnerabilities still take 28 days, you haven't changed your approach.

Track the percentage of KEV vulnerabilities in your environment. Not every KEV addition will affect you, but the ratio of KEV CVEs to total vulnerabilities tells you about your exposure to actively exploited vectors. A high ratio suggests you're running technologies attackers frequently target.

Pre-patch compromise assessments should occasionally yield findings. If you never detect exploitation evidence before patching KEV vulnerabilities, either you're patching extraordinarily fast or not looking carefully enough. Threat actors scan for vulnerable systems within hours of public disclosure; some of your instances will be probed before you can patch them.

What Organizations Get Wrong

The most common mistake is treating KEV additions like any other vulnerability disclosure. You run your scanner, the CVE appears in your queue, and it gets prioritized alongside everything else based on CVSS score or asset criticality. This approach ignores the fundamental signal: active exploitation.

Another failure is patching without investigation. You identify vulnerable systems, schedule maintenance, apply patches, and move on. If threat actors already compromised the system, patching removes their initial access vector but doesn't evict them. You need forensic review before remediation, not after.

Organizations also underestimate the KEV Catalog's value for non-federal entities. BOD 26-04 applies only to FCEB agencies, but CISA encourages all organizations to adopt the same risk-based approach. You don't need a federal mandate to recognize that actively exploited vulnerabilities deserve urgent attention.

Takeaways for Your Team

Integrate KEV monitoring into your vulnerability management workflow. CISA maintains the catalog to help prioritize remediation based on real-world threat activity. Use it.

Establish a separate remediation track for KEV vulnerabilities that doesn't compete with routine patching. Your standard change management process wasn't designed for emergencies. Create an expedited path that maintains appropriate controls but recognizes urgency.

Investigate before you patch. Pre-patch compromise assessment should be standard for KEV vulnerabilities, especially on internet-facing systems. Logs, configuration baselines, and network traffic analysis can reveal exploitation attempts or successful compromise.

Maintain an asset inventory that supports rapid queries. When a new KEV vulnerability drops, you need to answer "are we vulnerable?" within hours. If it takes three days to identify affected systems, you've already lost the race against attackers.

Finally, if you're aware of an exploited vulnerability not in the KEV Catalog, submit it through CISA's KEV Nomination Form. Potential additions must have a CVE ID, evidence of exploitation, and clear mitigation guidance. The catalog's value grows when organizations contribute intelligence about active threats.

The KEV Catalog won't solve your vulnerability management challenges, but it provides the clearest signal about which vulnerabilities attackers are exploiting right now. Ignore it at your own risk.

Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide

You Might Also Like