Hit a KEV deadline

The CISA Known Exploited Vulnerabilities catalogue is the rare security list with a date attached. For US federal agencies it is binding; for everyone else it is the strongest available public signal that something is being used against real systems right now.

What has been added

What was added to the KEV catalogue recently?

vulnetix_kev:

{
  "count": 1247,
  "sources": ["CISA", "vulnetix", "enisa", "vulncheck"],
  "items": [
    {
      "cveId": "CVE-2026-XXXXX",
      "vendor": "Microsoft",
      "product": "Windows",
      "dateAdded": "2026-08-10T06:01:14Z",
      "dueDate": "2026-08-31T00:00:00Z",
      "knownRansomware": "Known",
      "requiredAction": "Apply mitigations per vendor instructions..."
    }
  ]
}
Warning Only CISA-sourced entries carry a dueDate. VulnCheck- and ENISA-derived rows record membership but set no deadline. A null dueDate means “this source does not issue one”, not “no deadline exists”. If you are subject to BOD 22-01, the CISA row is the one that binds you.

Does it apply to you

A KEV entry for a product you do not run is noise. The catalogue has over a thousand entries; a handful will be yours.

Cross-reference against what you have:

/mcp__vulnetix__vulnetix_kev_watch --since 2026-08-01

The prompt pulls recent additions and greps your lockfiles, so what comes back is the intersection, not the catalogue.

For a single advisory, vulnetix_kev_status is the cheap direct check:

Is GHSA-jfh8-c2jp-5v3q in KEV, and by when?

Order by what is due

Sort by dueDate, not by severity. A CVSS 7.5 due in six days outranks a CVSS 9.8 with no deadline, and that is the whole point of the catalogue.

For each KEV entry affecting our dependencies, give me the due date, days remaining, whether ransomware use is known, and whether a fixed version exists. Order by days remaining.

The agent chains vulnetix_kev → vulnetix_package_vulns → vulnetix_remediation, which is exactly the sequence you would run by hand.

The overdue ones

vulnetix_remediation surfaces overdue entries explicitly:

"kevEntries": [{
  "dateAdded": "2021-12-10T00:00:00Z",
  "dueDate": "2021-12-24T00:00:00Z",
  "daysUntilDue": -1691,
  "overdue": true,
  "knownRansomwareCampaignUse": "Known"
}]

daysUntilDue: -1691 is not a rounding error. Overdue KEV entries are common, and being able to name them precisely is more useful than a dashboard colour.

Turning it into a plan

For each overdue or due-within-30-days KEV entry affecting us, give me the package, the current version, the fixed version, and the single command that closes it. Order by days remaining.

Then apply and confirm:

/mcp__vulnetix__vulnetix_fix CVE-XXXX-XXXXX
/mcp__vulnetix__vulnetix_verify_fix CVE-XXXX-XXXXX

verify_fix re-scans and records the verdict in .vulnetix/memory.yaml, which is what makes it evidence instead of a claim.

When you cannot make the date

Sometimes the answer is no. Make that a documented position instead of a silence:

  1. vulnetix_workarounds for mitigations that need no patch
  2. vulnetix_detection_rules for detection while you are exposed
  3. vulnetix_vex_publish to record the justification as a VEX attestation

A documented, mitigated, monitored exception is defensible. An undocumented miss is not.