The KEV clock went from 21 days to 3.

CISA’s Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with evidence of active exploitation. Each entry carries a due date by which federal civilian agencies are directed to remediate it. That due date used to be the least interesting field in the file. It is now the most important one.

What the catalog shows

We took the public catalog (version 2026.10.27, 1,760 entries) and measured the gap between the date each entry was added and its due date, month by month.

The shift was gradual, then sudden. The first entry with a window of a week or less was added on November 14, 2025, and three-day windows begin in January 2026. In March, 14-day windows arrived, and the last 21-day entry was added on March 5, 2026. Since April 1, 135 of 205 entries have a three-day window, 69 have 14 days, and 1 has five.

A note on method. “Window” here is the due date minus the date added, as printed in the catalog. October 2026 is a partial month, through October 27, 2026. We did not adjust for weekends or holidays, and we did not look at who fixed what or when. We read the catalog through its public GitHub mirror, and the figures will be recomputed as it grows.

The PHP case

On October 26, 2026, CISA added two PHP core vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both described as allowing unauthenticated remote code execution. Both have a due date of October 29, 2026: three days. PHP had shipped fixes on October 21, in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and CISA published an alert the same day.

Both entries also carry a field that did not exist a year ago: forensicTriage, set to Yes. 93 of the catalog’s 1,760 entries have it, the earliest added on June 25, 2026, and every one of them has a window of three days or fewer. The entries’ required action points to CISA’s BOD 26-04 and to its forensics triage requirements, and ends with this sentence:

Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.

That sentence is the operational problem in one line. The catalog gives you three days and tells you the exposure judgement is yours.

What a three-day clock needs

A three-day window is not a faster version of a 21-day one. In 21 days an ordinary change process works. In three, the work that used to hide inside the 21 days has to be done before the vulnerability is announced. This is our reading of what that means in practice:

• An inventory that answers “where does this run?” PHP is the textbook case. It sits inside web applications, appliances and third-party products, and the catalog entry itself notes that the flaw affects an open-source component that could be used by different products.
• An exposure map. Which of those instances can be reached from the internet? The catalog expects you to know.
• A change path that fits in 72 hours. Pre-approved emergency change procedures, tested rollback and named approvers. A change board that meets weekly fails at the first entry.
• A paper trail written as you go. The exposure determination, the patch or mitigation, the evidence, and for anything still open at the due date, a POA&M entry with a real plan. Assessors read these. It is continuous monitoring doing its job.
• Vendors on the same clock. The required action covers cloud services too: follow the directive’s guidance or discontinue use if mitigations are unavailable. Your SaaS and managed-service contracts should say how fast a provider tells you, and how fast it acts.

None of this is exotic. It is the discipline behind a continuous ATO, applied to a smaller clock. Programs that already run configuration and vulnerability management as live systems experience this as a busy week. Programs that run them as quarterly documents experience it as a missed deadline.

Watch it as it happens

Our threat globe plots each new catalog entry at its vendor’s headquarters, with its due date and an exploit-probability score, and refreshes every hour from the same catalog.

Common questions

Sources

1. CISA, Known Exploited Vulnerabilities CatalogCatalog version 2026.10.27, read through the public mirror github.com/cisagov/kev-data. Accessed Oct 27, 2026.
2. CISA, BOD 26-04: Prioritizing Security Updates Based on RiskLinked from the catalog entries. Read it for the exact requirements; this piece does not restate them.
3. CISA, BOD 26-04 implementation guidance (forensics triage requirements)Linked from the catalog entries.
4. CISA, Critical Vulnerabilities in PHP Require Immediate Patching (Oct 21, 2026)Linked from the catalog entries.
5. NIST NVD, CVE-2026-109618
6. NIST NVD, CVE-2026-109619

Share on LinkedInFollow AusperSubscribe by RSS

Related reading