What Are CISA Known Exploited Vulnerabilities and How Do They Affect Your Website?

TL;DR: The CISA Known Exploited Vulnerabilities (KEV) catalog is a public, curated list of software flaws that attackers are actively exploiting in the wild — not theoretical risks. For federal civilian agencies, Binding Operational Directive 22-01 makes remediating KEV entries mandatory on a fixed timeline. State and local governments aren’t legally bound by it, but the KEV catalog is the best free prioritization list in existence: if a vulnerability is on it, fix it now. Outdated WordPress, Drupal, and their plugins are common ways a government website ends up running KEV-listed code. Check your CMS and component versions against the catalog, patch, and monitor continuously so new exposures don’t sit unnoticed.

Most government web teams have more “critical” security alerts than they can ever act on. A typical vulnerability scanner flags hundreds of findings, each labeled high or critical, with no clear way to tell which one a real attacker is actually using to break into sites today. The CISA Known Exploited Vulnerabilities catalog exists to cut through that noise. It is a short, authoritative list of the vulnerabilities that matter most right now — the ones being weaponized against real organizations — and it should sit at the top of every government web team’s patching priorities. This guide explains what the KEV catalog is, the legal weight it carries, how an ordinary government website ends up exposed, and exactly how to check and fix your own.

If your agency runs a public website on a content management system — and almost all do — KEV is not an abstract federal-cybersecurity topic. It is a direct, practical checklist for the software your site depends on.

What the KEV Catalog Is

The Known Exploited Vulnerabilities catalog is maintained by the Cybersecurity and Infrastructure Security Agency (CISA), the federal agency responsible for defending civilian government networks and critical infrastructure. It is a continuously updated, publicly available list of specific software vulnerabilities that CISA has confirmed are being actively exploited by threat actors.

The key word is exploited. Tens of thousands of new vulnerabilities are disclosed every year, each assigned a CVE identifier (for example, CVE-2023-1234). The overwhelming majority are never used in a real attack. The KEV catalog filters that flood down to the small fraction that attackers are genuinely abusing. As of 2026 the catalog contains roughly 1,200 entries — a manageable number compared to the tens of thousands of CVEs published annually.

For a vulnerability to be added to KEV, CISA applies three criteria:

1. It has an assigned CVE ID — it’s a formally tracked, disclosed vulnerability.
2. There is reliable evidence of active exploitation in the wild — not just a proof-of-concept, but real attacks.
3. There is a clear remediation action — typically a vendor patch or a defined mitigation.

Each KEV entry includes the CVE, the affected vendor and product, a short description, the required action, and a due date for federal agencies. The entire catalog is published as a web page and as machine-readable JSON and CSV feeds, so it can be wired directly into vulnerability scanners and monitoring tools.

This builds on CISA’s broader role in government cybersecurity, which we cover in our overview of CISA cybersecurity recommendations for government websites. KEV is arguably the most operationally useful thing CISA publishes: it answers the question “of everything I could patch, what should I patch first?”

Why KEV Matters: BOD 22-01 and the Legal Picture

The KEV catalog is not just advice. For federal civilian executive branch agencies, it is backed by a Binding Operational Directive: BOD 22-01, issued in November 2021 and titled “Reducing the Significant Risk of Known Exploited Vulnerabilities.”

A Binding Operational Directive is a compulsory instruction CISA can issue to federal civilian agencies. BOD 22-01 requires those agencies to:

• Remediate any vulnerability on the KEV catalog by the due date CISA assigns to it. Vulnerabilities discovered before the directive’s baseline got a six-month window; newer additions typically get two weeks from the date they’re added.
• Maintain a process for ongoing remediation of future KEV entries.
• Report remediation status through CISA’s continuous monitoring infrastructure.

Those two-week and six-month deadlines are tight on purpose. When CISA adds something to KEV, it’s because attackers are already using it.

What about state, local, and higher education?

Here’s the part that trips up many public-sector teams: BOD 22-01 does not legally bind state governments, county and city governments, public universities, or libraries. Binding Operational Directives apply only to federal civilian executive branch agencies.

But that legal distinction is almost irrelevant in practice. The vulnerabilities on the KEV catalog are exploited indiscriminately — automated attack tools scan the entire internet, and a county website is just as reachable as a federal one. State CISOs, the MS-ISAC (Multi-State Information Sharing and Analysis Center), and cyber-insurance underwriters all treat KEV remediation as the baseline standard of care. Several state governments have formally adopted KEV-based timelines for their own agencies.

The practical rule for any government web team is simple: treat the KEV catalog as mandatory regardless of whether a directive technically binds you. If a vulnerability you’re running is on KEV, you are vulnerable to attacks that are happening today, and “we weren’t legally required to patch” is not a defense you want to give the public, a journalist, or your insurer after a breach.

How an Ordinary Government Website Ends Up on KEV

It’s tempting to think the KEV catalog is about exotic, nation-state-grade exploits. Some entries are. But a large share of the catalog covers exactly the software that runs ordinary public-sector websites: content management systems, their plugins and modules, web servers, and the libraries underneath them. Here’s how a typical government site ends up exposed.

Outdated WordPress core and plugins

WordPress powers a huge portion of government websites — city halls, libraries, departments, elected officials’ pages. WordPress core itself is reasonably well-maintained and auto-updates minor releases, but the plugin ecosystem is where KEV-listed vulnerabilities concentrate.

The KEV catalog has repeatedly included WordPress plugin flaws. A well-known example is the file-upload vulnerability in older versions of certain form and media plugins that allowed unauthenticated attackers to upload web shells. When a plugin like that is abandoned by its developer, or simply never updated by a busy web team, the site keeps running vulnerable code indefinitely. Government sites are especially prone to this because:

• Plugins get installed for a one-time need (an event-registration form, a PDF viewer) and then forgotten.
• The person who installed a plugin has left the agency, and no one knows whether it’s safe to update.
• A theme or plugin was customized, so staff are afraid an update will break the site.

Outdated Drupal core (“Drupalgeddon”)

Drupal runs many larger state agency and university sites. The catalog includes several Drupal core vulnerabilities, most famously the remote-code-execution flaws nicknamed Drupalgeddon (CVE-2014-3704) and Drupalgeddon2 (CVE-2018-7600). These were mass-exploited within hours of disclosure. A Drupal 7 site that was never upgraded — and Drupal 7 reached end of life in January 2025 — may be running code with multiple KEV entries and no vendor patches available at all.

Web servers, libraries, and appliances

Beyond the CMS, KEV regularly lists vulnerabilities in:

• Web and application servers (Apache, Nginx, IIS, and notably Apache Log4j — the Log4Shell vulnerability, CVE-2021-44228, was a flagship KEV entry).
• TLS/SSL libraries and frameworks that your site or its build tooling depends on.
• Network appliances in front of the site — VPN gateways, load balancers, and firewalls from vendors like Fortinet, Citrix, and Ivanti have appeared on KEV repeatedly and are a common breach entry point for government networks.

The common thread: the vulnerable component is often not the part of the site anyone is actively working on. It’s infrastructure that’s quietly out of date.

How to Check Your Website’s KEV Exposure

You don’t need a security operations center to get started. Work through these steps.

1. Inventory your software and versions

You can’t check what you don’t know you’re running. Build a simple inventory:

• CMS and version — WordPress 6.x, Drupal 10, etc. In WordPress, the version shows at the bottom of the Dashboard > Updates screen; in Drupal, under Reports > Status report.
• Every active plugin/module and its version, plus whether each has pending updates.
• Themes, including custom ones.
• The web server and PHP version (often visible in the same status reports or via your hosting control panel).
• Front-end libraries bundled into the site (jQuery, etc.).
• Network appliances and CDNs in front of the site.

For many small agencies this inventory has never existed. Creating it once is one of the highest-value security tasks you can do.

2. Cross-reference against the KEV catalog

Open the official KEV catalog and search by vendor and product. Search for “WordPress,” “Drupal,” “Apache,” and any plugin or appliance vendor in your inventory. The catalog tells you the affected versions and the required fix.

For automated cross-referencing, point a vulnerability scanner at your site. Tools that map findings to KEV include:

• CISA’s own free services for SLTT (state, local, tribal, territorial) governments — CISA offers free vulnerability scanning to public-sector organizations through its Cyber Hygiene services. Many agencies don’t realize this is available at no cost.
• Commercial scanners (Tenable Nessus, Qualys, Rapid7) that tag findings with a KEV flag.
• WordPress/Drupal-specific scanners like WPScan or the Drupal security advisories feed, which flag vulnerable plugins and modules directly.

3. Confirm before you panic

Scanners produce false positives. Before you treat a finding as real, confirm the affected version range actually matches what you’re running, and check whether a backported patch (common on managed hosting) has already closed the hole. The KEV entry’s description and the vendor advisory are the authoritative references.

How to Fix and Stay Fixed

Patch on the KEV timeline

Adopt the BOD 22-01 timelines as your own internal policy even if you’re a city or a university: KEV entries get patched within two weeks, ideally faster for anything internet-facing and unauthenticated. Document the policy so it survives staff turnover.

For CMS updates specifically:

• WordPress: enable automatic updates for minor core releases and for plugins where you can tolerate it. Update or remove abandoned plugins — an unmaintained plugin is a standing liability. Use a staging environment to test major updates.
• Drupal: subscribe to Drupal security advisories, apply security releases promptly, and prioritize getting off any end-of-life version (Drupal 7 and earlier). Drupal’s policy of pre-announcing the timing of security releases lets you schedule the work.

Reduce the surface area

Every plugin, module, and appliance you remove is one fewer thing that can land on KEV later. Audit your installed components and delete anything you don’t actively use. This pairs well with hardening the site’s HTTP response, covered in our guide to security headers for government websites — defense in depth means an attacker who finds one gap still hits other barriers.

Build it into a checklist

KEV remediation is one line item in a broader posture. Fold it into your recurring review alongside accessibility, privacy, and performance using a government website compliance checklist, so it doesn’t get dropped when staff are busy.

Monitor continuously, not annually

The single biggest weakness in government vulnerability management is timing. The KEV catalog updates constantly — CISA adds new entries multiple times per week. A vulnerability you checked for in January can be added to the catalog in March, and if your next review isn’t until the following year, your site runs exposed for months. Manual, point-in-time scanning simply can’t keep pace with a list that changes weekly.

This is the same regression problem that affects every kind of web compliance: the site that was clean yesterday isn’t clean today, because the threat landscape (or your own content) changed. We explore that pattern in depth in what continuous compliance monitoring means for government websites.

A Quick Reference

The KEV catalog is the rare security resource that’s both authoritative and genuinely actionable: a short list, updated constantly, of the exact flaws attackers are using today. The catch is that “updated constantly” means a one-time check goes stale within weeks. Government web teams that rely on annual audits will always be remediating yesterday’s news. Govzu continuously monitors your government website’s accessibility, privacy, security, and performance posture — so when a new exposure or regression appears, your team is alerted while there’s still time to fix it, not after it becomes an incident.