Safeguard
Vulnerability Analysis

CISA Gave You Three Days: What the KEV Deadlines Say About Your Patch Process

Of the 103 vulnerabilities CISA added to the exploited catalogue since June, 75 carry a three-day remediation deadline. That is shorter than most release cycles, and it is an architecture requirement rather than a scheduling problem.

Safeguard Research Team
6 min read

CISA's Known Exploited Vulnerabilities catalogue reached 1,710 entries in its 14 September 2026 release. Since 1 June it has added 103.

The number worth looking at is not 103. It is the deadline attached to each one.

Of those 103 entries, 75 carry a remediation window of three days from the date they were added. The other 28 get fourteen. Nothing in between.

If your patch process measures itself in sprints, that is the finding: the most dangerous vulnerabilities you will face this quarter come with a deadline shorter than your release cycle.

What the split means

The three-day and fourteen-day windows are not arbitrary severity bands. They reflect a risk-based prioritisation: exposure, exploitation characteristics, and what an attacker gets. The catalogue is not a list of severe vulnerabilities — it is a list of vulnerabilities someone is already using, which is a much smaller and more urgent set than "everything above CVSS 9".

The distinction matters because most vulnerability programmes are built around severity thresholds. Anything 9.0 and above gets escalated; everything else queues. That produces a queue thousands of items long, prioritised by a number that says how bad exploitation would be, not whether it is happening.

KEV inverts it. A 5.3 in the catalogue deserves attention a 9.8 outside it does not, because one is being used and the other is a hypothesis. CVE-2026-66384 — an authenticated write outside a Docker cache path in JFrog Artifactory, CVSS 5.3 — is in the catalogue. Most 5.3s never will be.

Three days is an architecture requirement

A seventy-two hour window is not a scheduling problem you solve with urgency. It is a constraint on how the system is built. Meeting it repeatedly, on a system you did not choose the timing for, requires four things to already be true:

You know where the software is. Not a spreadsheet updated quarterly. If discovering every instance of a product takes two days, you have one day left. This is the step that most often consumes the window, and the one least likely to be the subject of a project.

You can patch without a change advisory board meeting. Emergency paths exist in most organisations and are used reluctantly because using them is politically expensive. A process invoked three times a quarter is a process; one invoked once a year is a fire drill.

You can restart the thing. Plenty of KEV entries sit in infrastructure with no maintenance window — the build server mid-release, the registry every pipeline depends on. If patching requires downtime you are not permitted to take, the deadline is missed at the architecture level, not the process level.

You can tell whether you were hit before you patched. Patching closes the door; it says nothing about what came through. For credential-disclosure bugs this determines whether remediation means "apply update" or "apply update and rotate everything that host could reach".

Where the entries are landing

Of the 103 added since June, the vendors appearing most are Microsoft (11), Cisco (8), then JFrog, Fortinet, SonicWall and Oracle at four each.

Two shapes are visible in that list. The first is familiar: network edge devices — firewalls, VPN concentrators, remote access gateways. They have been the reliable initial-access route for years, for the same structural reason each time. They are internet-facing by definition, they hold credentials, they are rarely instrumented like servers, and they cannot be patched without an outage someone has to authorise.

The second is newer and closer to home. JFrog Artifactory entered the catalogue for the first time on 27 August 2026 and had four entries by 11 September. GitLab CE/EE entered on 11 September with CVE-2026-85706, a CVSS 10.0 unauthenticated file read. JetBrains TeamCity entered on 5 August with an unauthenticated RCE. Registry, source host, build server — the systems that assemble and distribute everything you ship, all exploited in the wild inside six weeks.

Eight of the 103 are flagged as used in ransomware campaigns. That number is low because the flag records confirmed association, not because ransomware is rare; the majority are marked Unknown, which means unproven rather than untrue.

Using the catalogue properly

Subscribe to it as a feed, not a report. The catalogue is published as JSON and updated continuously. Matching it against your own inventory nightly is a small piece of automation that changes what your team sees first each morning.

Match on product, not just CVE. A CVE match requires you to already know the version you run everywhere. A vendor-and-product match catches the instance nobody inventoried, which is the one that will still be running next month.

Diff the deadline, not the score. Sort your open findings by KEV due date. It is a better queue than CVSS, because it encodes exploitation and urgency together.

Treat non-federal deadlines as the same deadline. The binding directive applies to federal civilian agencies. The attackers do not check whether you are in scope.

The uncomfortable part

Most organisations cannot meet a three-day window today, and saying so plainly is more useful than pretending otherwise. The realistic goal is not universal seventy-two hour patching. It is:

  1. A short, honest list of systems where you can move in three days, because they are exposed and hold credentials to everything else — edge devices, source hosts, registries, CI.
  2. Enough inventory accuracy that finding them is minutes, not days.
  3. A rehearsed rotation procedure for the case where patching was not fast enough.

That is a smaller project than "modernise vulnerability management", and it is the part that changes outcomes.

How Safeguard helps

Safeguard keeps a continuous inventory of the components your software is built from, so "where do we run this" is a query rather than an investigation — the step that most often consumes a three-day window before anyone has touched a patch.

Reachability analysis then separates the findings that are exploitable in your code from the ones that merely appear in a dependency list, which is what keeps capacity free for the small number of vulnerabilities that arrive with a deadline attached. The catalogue tells you what attackers are using. Your inventory has to tell you, quickly, whether that includes you.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.