CISA Has Not Issued a 21-Day Patch Deadline Since March. 126 KEV Entries Later, the Median Window Is Three Days.
- Patrick Duggan
- 3 hours ago
- 6 min read
On July 30 we published a piece about CVE-2026-63077, an unauthenticated remote code execution bug in the protocol JetBrains TeamCity build agents use to phone home. CVSS 9.8. We had searched GitHub that night and found no public proof-of-concept; our exploit harvester held nothing either. The advice was to patch immediately, on the grounds that the quiet week before someone publishes an exploit is the cheapest time a defender ever gets.
The quiet week lasted six days.
On August 5, CISA added CVE-2026-63077 to the Known Exploited Vulnerabilities catalogue. It was the only CVE added that day. The remediation deadline for federal civilian agencies was August 8 — three days.
On August 7, Rapid7 published a working proof-of-concept: write a .JSPWS file, execute an arbitrary command, delete the file.
Read that order again. CISA confirmed real-world exploitation on the 5th. Public exploit code appeared on the 7th. The exploitation came first. Whoever was using this had done original work against a proprietary binary protocol rather than running somebody's script — which is the difference between a targeted operation and a commodity one, and it is the reason the KEV entry says the threat actors are unknown and the scale is unknown.
That is a good story about one build server. But when we went to check the three-day deadline against the rest of the catalogue, we found something larger that nobody appears to have written down.
We pulled the whole catalogue and measured the deadline
We took all 1,662 entries in CISA's published KEV feed and computed, for each one, the number of days between dateAdded and dueDate. That is the window a federal civilian agency has to remediate.
For most of the catalogue's life the answer is a single number: 21 days. It appears 1,025 times. It is the number every vulnerability-management program, every SLA, every board slide and every compliance report is built around. Twenty-one days is what "KEV deadline" means to most people who use the word.
Here is what the last eighteen months actually look like, by month of listing:
Through all of 2025 the 21-day window is essentially the only window. January through June 2025: zero entries with a deadline of three days or less. A handful appear in July and September 2025 and then stop.
Then 2026 turns over. January, two fast entries. February, six. March, five — and March is the month the long windows start disappearing. April, eight fast and zero long. May, seven and zero. June, seventeen and zero. July, twenty-two and zero. August so far, six and zero.
The last KEV entry carrying a remediation window of fifteen days or more was [CVE-2023-41974](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2023-41974), Apple iOS and iPadOS, added March 5, 2026, due March 26.
Since that entry, CISA has added 126 vulnerabilities to KEV. Not one of them has a window of fifteen days or more. Sixty-five have three days. Sixty have fourteen. One has five. The median is three.
The 21-day deadline is not shortened. It is gone. It has not been used once in five months.
Why this happened, and why nobody announced it
The mechanism is visible in the KEV entries themselves. The TeamCity record's required action no longer cites BOD 22-01. It cites BOD 26-04, "Prioritizing Security Updates Based on Risk," and adds a forensics-triage requirement, and tells the agency it is responsible for evaluating each asset's internet exposure.
That is a different model. BOD 22-01 was a schedule: everything on the list, twenty-one days, go. BOD 26-04 is a risk assessment applied per entry, and when the assessment says an internet-facing unauthenticated RCE is being exploited right now, the number it produces is three, not twenty-one.
There is nothing improper about this. It is arguably a better policy, and the directive is public. But the transition happened entry by entry over about five months rather than as a single announcement, which means the change is invisible to anybody who reads advisories one at a time and never looks at the distribution. You cannot feel a median move. It only appears if you count.
We publish a lot about measuring our own systems because green dashboards lie. This is the same failure mode pointed outward: every individual KEV entry was correct and public, and the aggregate fact — the deadline regime changed — was not in any of them.
What this actually costs you
If your vulnerability-management program encodes 21 days, you are now, on the median entry, eighteen days late by design. Not late because of a missed ticket or a slow change-advisory board. Late because the number in your policy document is a number CISA stopped issuing in March.
And the three-day tier is not a rounding error. It is the single most common window in 2026: 71 of 178 entries listed this year, roughly forty percent, and it has been the majority every month since June.
Three days is shorter than a lot of organisations' change windows. It is shorter than most emergency-change approval cycles. It does not survive a long weekend. TeamCity was listed on Wednesday August 5 and due Saturday August 8 — a deadline that lands on a weekend, on a build server, which is exactly the asset class where an unplanned restart requires the most coordination.
The federal deadline is not legally your deadline if you are a private company. It has never been. But it has always been read as a proxy for "how fast does the government think an attacker will get here," and that proxy just moved by a factor of seven while most people's policies did not.
What the TeamCity case shows about the shape
Come back to CVE-2026-63077, because it is the worked example of every part of this.
JetBrains published on July 27. We wrote on July 30 that there was no public exploit and told people to patch anyway, on the reasoning that the barrier at that moment was "do original research against a proprietary protocol" and would soon become "run a script." Six days later CISA said people were already through the first barrier. Two days after that, the script arrived.
The window between "the vendor told you" and "everyone can do it" was eleven days. The window between "the government confirmed exploitation" and "the exploit is public" was two.
We do not claim we detected the exploitation — we did not, and we have no first-party telemetry on this one. What we did was read the advisory, check whether weaponisation had happened yet, find that it had not, and say so with a date on it. That is the whole method: publish before the outcome is known, then let the record grade you. On this one the record graded us in six days, and the answer was that the quiet week we described was real and shorter than the phrase implies.
What to change this week
Reprice your SLA against the actual data, not the folklore. If your standard is 21 days for KEV, it matches nothing CISA has issued since March 5. Three days is the median and the mode. Pick a number deliberately, and if three is impossible for you, say so and staff the exception — do not leave a policy in place that is silently wrong.
Watch the deadline field, not just the CVE. The dueDate in the KEV feed is now carrying risk information it did not carry a year ago. A three-day entry is CISA telling you something about exposure and exploitation that the CVSS score does not. It is free, it is in the JSON, and almost nobody parses it.
Patch TeamCity if you have not. 2026.1.3 or 2025.11.7. There is now public exploit code, confirmed in-the-wild exploitation, and a federal deadline that expired on August 8. If you run build agents, restrict who can reach the agent polling port as well — that channel talks to a known, enumerable set of hosts and has no business accepting connections from the general network.
And go count something you assumed. The 21-day window was true for years, and it stopped being true without anyone telling us. That is not a CISA failure; it is what happens to any number you learned once and never re-measured. We only found this because a three-day deadline on a single JetBrains entry looked wrong, and we checked instead of shrugging.
Measurements in this piece were taken August 11, 2026 against CISA's published `known_exploited_vulnerabilities.json` feed (catalogue release 2026-08-10, 1,662 entries), computed as `dueDate` minus `dateAdded`. The TeamCity proof-of-concept is Rapid7's. Our July 30 TeamCity piece is on this site and is dated; we are comparing our own publication date against CISA's listing date, not claiming detection of the exploitation itself.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=kev-21-day-window-is-gone-126-entries-zero
Comments