The 2026 Verizon DBIR put the median remediation time for a known exploited vulnerability at 43 days, up from 32 the year before. Only 26 percent of KEV entries got fully remediated, down from 38 percent. Between 60 and 70 percent are still open at day seven after detection, and that number holds regardless of program maturity, tooling, or budget. The report treats it as a possible ceiling on what remediation processes can do.
CISA’s Binding Operational Directive 26-04, issued June 10, sets three calendar days for its highest risk tier.
Two KEV additions in August became the first well-documented tests of what that tier looks like when it fires against real infrastructure. Both landed on build and delivery systems.
What actually happened#
CVE-2026-63077 is an unsafe deserialization flaw in JetBrains TeamCity On-Premises, CVSS 9.8, sitting in the agent polling protocol that build agents use to check in with the server. An attacker who can reach the server over HTTP or HTTPS exploits it without credentials and runs operating system commands with whatever privileges the TeamCity server process holds. The vendor advisory landed July 27 and stated no known exploitation at the time. CISA added it to KEV on August 5 with a deadline of August 8.
The root cause is worth understanding because it explains why the exposure was total rather than partial. TeamCity built an allowlist of Java classes permitted during deserialization of unauthenticated agent requests, but added those classes on top of the deserialization library’s existing permissive defaults instead of clearing them first. The intended deny-by-default posture never took effect. The patch clears permissions before adding to them.
CVE-2026-8037 is an unauthenticated command injection in Progress LoadMaster, reachable through unsanitized input across several API endpoints. Progress published fixed releases in June. CISA added it to KEV on August 7 with a deadline of August 10. Internet scanning data put roughly 300 instances exposed at the time, though that count doesn’t separate honeypots or hosts already patched.
Both products sit in positions that make a compromise expensive. A load balancer terminates traffic in front of application infrastructure and holds certificates. A CI/CD server holds registry tokens, cloud credentials, and the signing material a pipeline uses to ship software under your organization’s name.
The requirement isn’t what most coverage said it was#
Nearly every writeup framed these entries as three-day patching deadlines. Read the KEV action text and that’s not what it says.
The action instructs organizations to apply vendor mitigations in accordance with BOD 26-04, and to follow CISA’s forensic triage requirements. Two obligations, not one. CISA’s stated reasoning is direct: applying a patch generally doesn’t evict a threat actor, so determining whether the system was already compromised is part of the response rather than a follow-up project.
That distinction is the entire operational change, and it’s the part that transfers cleanly outside federal scope.
Why the directive is built this way#
BOD 26-04 supersedes both BOD 22-01 and BOD 19-02. The flat model where every KEV entry inherited the same clock is gone. In its place is a decision model built on four inputs: whether the asset is publicly exposed, whether the vulnerability is being actively exploited, whether exploitation is automatable, and what the technical impact is. Sixteen combinations map to five remediation tiers, from three days at the top down to fix-at-next-upgrade at the bottom.
Two design details are easy to miss.
The clock starts when CISA adds the CVE to the catalog or when an agency identifies it on an asset in its own inventory, whichever comes first. Waiting for a KEV listing to start counting is not the model.
Where CISA hasn’t yet enriched the decision points, the directive defaults to a 60-day timeline, and it treats an asset of unknown exposure as publicly exposed. Not knowing what’s on the internet resolves against you.
There’s also a ratchet. CISA committed to reassessing the timelines annually and to tightening them if adversarial capability advances. Three days is a starting position.
What this means if you don’t work for a federal agency#
The directive binds civilian executive branch agencies. It doesn’t bind you. It will still reach you, through two paths.
Contract language is the first. The directive requires agencies to review contracts so that vendors supporting agency systems can meet the timelines. Remediation windows written into procurement move downstream fast.
The second path is simple credibility. Once a federal standard says a KEV entry on an exposed, high-impact asset warrants a compromise assessment rather than a patch ticket, “we patched it within our SLA” stops reading as a complete answer to a board, an auditor, or a customer’s security questionnaire.
The harder question, and the one worth sitting with, is whether your team could actually execute triage on a three-day clock tonight. Most can’t, and the gap is rarely tooling. It’s that nobody knows which appliances are internet-reachable this week, and nobody has ever pulled logs off the load balancer.
Where to start#
Pick the systems that would hurt most and work backward from the triage requirement rather than the patch queue.
Inventory the appliances and build infrastructure that terminate external traffic or hold pipeline credentials. Load balancers, application delivery controllers, CI/CD servers, artifact registries. For each one, answer whether it’s reachable from outside, and whether the management or API interface is reachable separately from the data path.
Confirm you’re collecting logs from those systems today, not that you could collect them. Appliance logging is frequently configured during deployment and never validated again. A three-day triage window is not when you want to learn that your load balancer has been logging to local disk with a seven-day rotation.
Write down, in advance, what evidence you’d need to answer “was this compromised” for each system class. For a build server, that’s account creation, agent registration, credential access, and outbound connections from the server process. For an edge appliance, that’s configuration changes, administrative account additions, and new VPN or tunnel definitions. Deciding this during an incident is how three days becomes three weeks.
Shorten the window before the KEV listing. Both August cases had a vendor patch available before CISA confirmed exploitation, LoadMaster by roughly two months. Treating vendor advisories for internet-facing infrastructure as a separate, faster track than general patching removes most of the exposure that triage has to reconstruct later.
The 43-day median isn’t a discipline problem. It’s a capacity problem, and no amount of urgency closes an eleven-day gap between an advisory and an exploit. What’s actually achievable is narrowing the set of systems where the answer has to arrive in three days, and knowing in advance how you’d produce it.
