CISA gives you 3 days to patch and triage. Live Exploit Tracker gives you a head start
On June 10, 2026, CISA fundamentally rewrote how federal agencies must prioritize patching. The new directive assumes you can answer one question continuously, for every CVE in your environment: “Is this being exploited, right now, and by whom?” That is precisely the question Live Exploit Tracker was built to answer.
CISA’s BOD 26-04 Just Made Exploitation Evidence Mandatory. We’ve Been Collecting It Live, at Scale, for Years.
What BOD 26-04 actually changes
Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk”, supersedes both BOD 22-01 (KEV remediation) and BOD 19-02 (internet-accessible systems). The flat “it’s in the KEV, patch it in 14 days” era is over. In its place: a graduated model built on four binary risk variables, evaluated per vulnerability, per asset:
- Publicly exposed — is the vulnerable asset reachable from the internet?
- Known exploitation — is the CVE in CISA’s KEV catalog?
- Automatable — can an adversary automate the full exploitation chain?
- Technical impact — does exploitation yield total or partial control?
The combination of answers maps to remediation timelines ranging from three calendar days with mandatory forensic triage at the top, down to “fix on next system upgrade” at the bottom. Notably, CISA no longer requires CVSS for prioritization. Severity scores are out; evidence of real-world exploitation is in.
CISA is explicit about why now: AI is compressing the window between disclosure and weaponization, while remediation performance is moving the wrong way — per the 2026 Verizon DBIR figures CISA cites, only 26% of KEV vulnerabilities were fully remediated in 2025, down from 38% the year before.
The directive’s logic is sound. Its operational demand is brutal: agencies now need continuous, current, per-CVE exploitation intelligence — not a quarterly threat report, not a static severity score. And for the highest tier, they need to determine within 72 hours whether they’ve already been compromised.
This is exactly the gap Live Exploit Tracker closes.
Live Exploit Tracker: ground truth on exploitation, from hundreds of thousands of real sensors
Live Exploit Tracker (L.E.T.) is powered by the CrowdSec Network — the largest crowdsourced threat intelligence network in the world, with servers deployed across real production infrastructure in 180+ countries. When an attacker probes or exploits a CVE anywhere in the network, we see it. Not a honeypot guess. Not a vendor advisory. Actual exploitation attempts against actual workloads.
For every tracked CVE, L.E.T. tells you:
- The exploitation phase — recon, targeted exploitation, mass exploitation, or decline. Watching a CVE move from “insufficient data” to “targeted exploitation” is watching your remediation deadline accelerate in real time.
- Momentum — is this threat growing, stable, or fading? A KEV entry from 2023 that nobody exploits anymore and a CVE that gained 80 attacking IPs this week are not the same priority. BOD 26-04 finally lets agencies act on that distinction.
- Who is attacking — every observed attacker IP, with full CTI profiling: origin, hosting provider, known/unknown actor, behavioral history across the network.
- What they’re after — takeover, ransom, or exfiltration, derived from observed attacker behavior.
- Indicators of compromise — the actual HTTP patterns and payloads observed exploiting the CVE in the wild.
Mapping L.E.T. to the directive, variable by variable
| BOD 26-04 requirement | What it demands operationally | What Live Exploit Tracker provides |
| Known exploitation (variable 2) | Track KEV continuously; react the moment a CVE is added | Live exploitation telemetry that frequently precedes KEV listing — we observe in-the-wild exploitation directly, giving you a head start before the clock officially starts |
| Automatable (variable 3) | Assess whether exploitation can be fully automated | Direct field evidence: our targeted-vs-mass-exploitation classification distinguishes hand-driven campaigns from spray-and-pray automation, based on observed attacker behavior, not theoretical analysis |
| 3-day forensic triage | Determine within 72h whether you were already compromised | Downloadable attacker IP lists and HTTP-level IoCs per CVE — grep your logs against the exact IPs and request patterns observed exploiting that vulnerability, going back months |
| Dynamic timelines | Re-prioritize the moment exploitation status changes | Phase-transition events and momentum scoring, updated continuously from live network signals, available via API for automated ingestion |
| “KEV is not the only list” (CISA’s own implementation guidance) | Track exploitation beyond the KEV catalog | Coverage of actively exploited CVEs regardless of KEV status, including pre-KEV recon campaigns against specific vendors and products |
Variable 1 — knowing which of your assets are publicly exposed — is your asset inventory’s job (EASM). L.E.T. doesn’t scan your network; it tells you what the adversary is doing, so your exposure data plus our exploitation data equals a complete BOD 26-04 picture.
Case in point: when CVSS says 5.3 and reality says 9/10
CISA dropped CVSS as a mandatory prioritization input for good reason. Here’s a live example of why.
CVE-2025-13956 is a missing-authorization flaw in LearnPress, a WordPress LMS plugin. CVSS score: 5.3. Medium. Under severity-based triage, it sits in the backlog forever.
Here’s what the CrowdSec Network actually observed: the CVE was published in March 2025 and stayed quiet for over a year. Then, in April 2026, we detected the first in-the-wild exploitation. By June 12, 2026, exploitation patterns shifted enough that our system reclassified it to targeted exploitation — 168 unique attacker IPs, momentum 4/5, targeting score 5/5, with 79% of attacking IPs profiled as pursuing system takeover. CrowdSec Score: 9/10 — critical active campaign.
A CVSS-driven program ignores this CVE. An exploitation-evidence-driven program — the kind BOD 26-04 now mandates — catches the phase transition the day it happens and re-prioritizes immediately. That’s the difference between a severity score assigned once at publication and a risk signal recomputed continuously from live attack data.
The vendor view: see the campaign, not just the CVE
Agencies don’t run CVEs; they run products. Federal networks are full of the exact appliances attackers systematically target—and if the last few years of emergency directives have taught us anything, it’s that edge devices from a handful of vendors pose disproportionate risk.
L.E.T.’s vendor pages aggregate all observations across a vendor’s entire product line. Take our Ivanti page: 20 tracked CVEs, 3 active recon campaigns, and 12,800+ attacker IPs currently engaged — including 13,500 IPs probing Connect Secure panels before any specific CVE is even in play. That recon activity is your earliest warning signal: adversaries are mapping targets for the next vulnerability before it becomes publicly known.
For a federal security team, this turns the directive’s per-CVE obligation into something manageable: one view of your actual vendor exposure, ranked by live adversary attention.
Beyond prioritization: shrink the exposure window while you patch
BOD 26-04 gives you three days for the worst cases. Patching an enterprise fleet in three days is hard. Patching it while the vulnerability is under active exploitation is harder.
This is where L.E.T. goes further than any prioritization feed: every CVE and vendor page exposes dynamic, subscribable IP datasets. Point your firewall, WAF, CDN, or cloud security layer at the blocklist for a specific CVE — or an entire vendor — and the IPs actively hunting that vulnerability are preemptively blocked from ever reaching your workloads. The dataset updates as the campaign evolves; no manual list management.
It’s not a substitute for patching — the directive is unambiguous about that, and so are we. It’s a compensating control that buys you the 72 hours you need and materially derisks the gap between “deadline starts” and “patch deployed.” Plug the holes in the hull while you’re still in the dry dock queue.
And when the forensic triage requirement kicks in, the same data answers the other question the directive forces: pull the full attacker IP intelligence and IoC patterns for the CVE via API, run them against your logs, and you have an evidence-based answer to “were we already hit?” — within the window, not after a six-week IR engagement.
Built for automation, because three days leave no room for manual work
Everything in L.E.T. is API-first: CVE details, exploitation phase, scores, attacker IPs, IoCs. Feed it into your vulnerability management platform, your SOAR, your reporting pipeline. The directive expects agencies to automate KEV tracking and remediation reporting; our data is structured to drop straight into that machinery. A curl away:
curl -s -H "x-api-key: YOUR_API_KEY" \
"https://admin.api.crowdsec.net/v1/cves/CVE-2025-13956"
The bottom line
BOD 26-04 codifies what defenders have known for years: patch what’s being exploited, defer what isn’t, and find out fast if you’ve already been breached. The directive supplies the framework. It assumes you have the evidence.
We have the evidence — live, global, behavioral, per-CVE and per-vendor — and the protection layer to act on it before your patch lands.
Explore Live Exploit Tracker now at tracker.crowdsec.net — browse CVEs, vendors, and live exploitation data freely. Federal agency or supporting a federal mission? Talk to our team about API access, blocklist integration, and operationalizing BOD 26-04.
