The KEV Due Date Is Now a Risk Verdict: Read It Before You Read the CVE

Since June 10, CISA has added 104 vulnerabilities to the Known Exploited Vulnerabilities catalogue. Every one of them carries a remediation deadline of either three days or fourteen. Nothing in between, nothing longer. Before June 10 the same field held seventeen different values, and more than a thousand entries sat at the old twenty-one-day default.

Four of those 104 landed yesterday, and all four sit on the perimeter: CVE-2026-93952 in Arista's on-premises VeloCloud Orchestrator, CVE-2026-94127 in F5 BIG-IP APM, and two in Check Point products, CVE-2026-93616 and CVE-2026-85102. All four are due September 25. That is two days from today.

The deadline column stopped being a scheduling hint in June. It is now the output of a published risk calculation, and it tells you three things about a vulnerability before you open a single advisory: whether CISA believes the affected asset is reachable from the internet, whether an attacker can automate the whole exploit, and whether success hands over total control of the box. A three-day entry means yes to all three. It also carries an obligation most teams have not noticed.

Who this is for

If you run none of those four products, the deadline column still matters, because the rule that produces it now governs every entry you triage. If you do run them, the exposure is narrower than the headlines suggest, and the exact conditions are below. Federal civilian agencies are bound by the directive. Everyone else inherits it the way we always inherit CISA deadlines: through the insurance questionnaire, the customer security addendum, and the auditor who asks why the appliance was patched on day eleven when the catalogue said three.

One honest exclusion up front. The F5 bug only reaches you if a virtual server carries both an APM access policy and an OAuth profile, with APM acting as the OAuth authorization server. A BIG-IP running APM purely as an OAuth client or resource server is out of scope for this one. Check that first and you may be finished with it in five minutes.

What the due-date column now encodes

Binding Operational Directive 26-04, issued June 10, 2026, replaced both BOD 19-02 and the BOD 22-01 regime that produced the familiar two-week and three-week KEV deadlines. It scores every vulnerability on four variables:

• Asset exposure - is the vulnerable asset publicly exposed?
• KEV status - is the vulnerability in the catalogue?
• Exploit automation - can an adversary automate every step of exploitation?
• Technical impact - does the adversary gain partial control or total control?

Those four inputs map to four outcomes: three days, fourteen days, sixty days, or fix at the next system upgrade. The worst combination, a publicly exposed asset with a fully automatable exploit yielding total control, draws the three-day window. And the directive attaches a second requirement to that tier that the catalogue JSON does not show you. Agencies must "complete remediation or mitigation action within the timeline (three days) and carry out a forensic triage of the asset to assess whether the system is compromised."

Read that clause again, because it changes the work. On a three-day entry, patching is half the task. The directive assumes that anything internet-facing, automatable, and total-impact has probably already been reached, and it asks you to prove otherwise on the specific box.

One more mechanic is worth knowing. The variables are dynamic. Pulling the management interface off the internet flips asset exposure from yes to no, and the required timeline moves out accordingly. Taking the box off the public internet is a legitimate way to buy time, and it is frequently faster than an appliance upgrade.

Read the number backwards

Because the window now derives from properties rather than from a batch default, you can invert it. Pull the catalogue and look at what the two tiers actually contain.

curl -sO https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

python3 - <<'PY'
import json, datetime, collections
kev = json.load(open("known_exploited_vulnerabilities.json"))["vulnerabilities"]
d = datetime.date.fromisoformat
BOD = d("2026-06-10")
today = datetime.date.today()

# Replace with the vendors you actually run on the perimeter.
ESTATE = {"F5", "Check Point", "Arista", "Cisco", "Fortinet", "SonicWall", "Citrix"}

since = [v for v in kev if d(v["dateAdded"]) >= BOD]
windows = collections.Counter((d(v["dueDate"]) - d(v["dateAdded"])).days for v in since)
print("entries since BOD 26-04:", len(since), "| windows:", dict(windows))

for v in sorted(since, key=lambda v: v["dueDate"]):
    window = (d(v["dueDate"]) - d(v["dateAdded"])).days
    if window == 3 and v["vendorProject"] in ESTATE:
        left = (d(v["dueDate"]) - today).days
        flag = "OVERDUE" if left < 0 else f"{left}d left"
        print(f'{v["cveID"]:<18} {v["vendorProject"]:<12} due {v["dueDate"]}  {flag}')
PY

Run that today and the window counter returns exactly two keys: 81 entries at three days and 23 at fourteen. The split is not a batch setting either. On thirteen separate dates since June, CISA has published mixed batches. September 11 is the clearest example: ConnectWise ScreenConnect and GitLab each got three days, while two JFrog Artifactory authorization bugs added in the same batch got fourteen.

The fourteen-day tier fills up with browser and client bugs, local privilege escalation, and libraries: Chromium V8, Windows kernel elevation, Starlette, LiteLLM, Artifactory. The three-day tier fills up with things that answer unauthenticated requests from the internet. That is the practical translation. When you see a three, CISA is telling you the box takes hostile input before it authenticates anybody.

The four on the September 25 clock

Arista VeloCloud Orchestrator, CVE-2026-93952

CVSS v3.1 10.0. Arista Security Advisory 0183 describes improper input validation that lets a remote attacker reach privileged internal functionality and compromise the orchestrator host. Three preconditions must hold: certificate-based Edge-to-Orchestrator authentication is configured, the attacker holds the public portion of an Edge authentication certificate, and the attacker can reach the VCO web interface. On-premises versions 5.2.3.15, 6.1.3.7, 6.4.2.7 and 7.0.0.2 and earlier are affected. Fixes are in 5.2.3.16 and 6.4.2.8 and later. Hosted and Dedicated orchestrators were already patched by Arista.

F5 BIG-IP APM, CVE-2026-94127

CVSS v3.1 9.8, a heap-based buffer overflow in OAuth profile handling that yields unauthenticated remote code execution. F5's advisory K000162605 confirms exploitation and places the flaw on the data plane, meaning the traffic path rather than the management path. Appliance mode does not protect you. F5 has shipped engineering hotfixes and offers an interim iRule through support for anyone who cannot take the upgrade window immediately. Builds past end of technical support will not receive a fix.

Check Point, CVE-2026-85102 and CVE-2026-93616

Both rated 9.8. Check Point's advisory covers a pair. CVE-2026-85102 is improper validation of certificate data during VPN negotiation, giving pre-authentication code execution on Security Gateway and Spark, R81 through R82.00.x, with fixes available since September 9. Check Point observed exploitation against Spark customers starting September 12, using certificates with subjects such as CN=vpn,OU=users,O=global. CVE-2026-93616 is a pre-authentication path traversal in the Management web service that executes a script from an arbitrary path and loads an arbitrary Java class. It affects Security Management R82.20, R82.10 at Jumbo Hotfix Take 44 or lower, R82 at Take 126 or lower, R81.20 at Take 166 or lower and R81.10 at Take 190 or lower. Check Point characterises exploitation of the management bug as a small number of targeted attacks.

Three of the four failed while deciding whether to trust something a stranger presented: a VPN peer certificate, an Edge certificate, an OAuth token. That code runs before any authentication decision exists to protect it.

The half of the three-day tier nobody schedules

Forensic triage on an appliance is harder than on a server, and that is exactly why it gets skipped. There is no EDR agent. The shell is restricted. The upgrade you are about to run replaces the filesystem you would have examined. So collect first, then patch.

Arista published enough detail to make this concrete for VCO. Check for the dropped files and the request signature before the upgrade, not after:

# Files dropped by observed exploitation of CVE-2026-93952
ls -la /usr/local/sbin/.vcnode.js /usr/local/sbin/vc-sysmond 2>/dev/null
md5sum /usr/local/sbin/vc-sysmond 2>/dev/null   # known bad: dc78e206eaeadec59fc5801fe4556bd0
systemctl cat vc-sysmon.service 2>/dev/null
ls -la /etc/systemd/system/vc-sysmon.service 2>/dev/null

# Request signature and known infrastructure in the web tier
grep -i 'x-vc-opt' /var/log/nginx/*access*.log
grep -E '142\.93\.149\.77|104\.248\.126\.159' /var/log/nginx/*.log

# Preserve before the upgrade wipes it
tar czf /tmp/vco-preupgrade-$(date +%F).tgz /var/log/nginx /etc/systemd/system

For Check Point, the equivalent is a review of certificate-based Mobile Access logins and of any second-stage behaviour that follows one, which in the vendor's telemetry looked like internal port and service scanning from the gateway itself. Check Point points customers to support articles sk1000117 and sk1000171 for the full indicator set.

For F5, the patch closes the overflow and says nothing about what an unauthenticated code-execution window produced while it was open. Sessions minted by a compromised APM remain valid after the hotfix. Rotate the device credentials, invalidate active access policy sessions, and re-issue any secret the appliance could read.

The sequencing rule generalises. I made the same argument four days ago about the three Linux kernel bugs that joined the catalogue with a September 21 deadline: the reboot that installs the fix is also the event that destroys the evidence. Appliances are worse, because the upgrade is a filesystem swap rather than a reboot. Capture the logs, the config, and the file listing to somewhere off the box, then upgrade.

Decide today who owns the seventy-two-hour queue

Seventy-two hours is shorter than most monthly change windows and shorter than many vendor support response times. A team that patches perimeter gear on a scheduled Saturday cannot meet it by trying harder on Saturday. It needs a standing emergency path: a named owner who watches the catalogue daily, pre-approved change authority for the three-day tier, a maintenance window that can be opened the same day, and a collection step that runs before the upgrade rather than instead of it.

The federal deadline is the visible part. The part that will matter to everyone else is that CISA has now published, in the open, a defensible definition of "how fast is fast enough" for an exploited internet-facing bug. Insurers, customers, and regulators read the same document you do. The next security questionnaire that asks about your remediation service level is going to be graded against three days for the perimeter, whether or not the directive binds you.

So pick the owner this week, and decide now what you will do with the triage half. If you do not have the capability to answer "was this box already used" before you replace its filesystem, that is the gap to close first, because it is the one the three-day tier is actually testing. We build and rehearse that collection step with clients as part of incident response planning, and it is a short engagement compared with the alternative of guessing after the fact.