The Real Change in BOD 26-04 Is Forensic Triage

Most coverage of BOD 26-04 focuses on the KEV's move from fixed deadlines to risk-based timelines. The more significant change is two words in the remediation table: "& forensic triage."

What changed

BOD 22-01 was a remediation directive: update procedures, patch per catalog timelines, report status. The word "forensic" does not appear in it.

BOD 26-04 replaces it with a four-variable risk model: public exposure, KEV status, automatability, and technical impact. The four variables map to 16 combinations and a remediation timeline for each, from fix-on-upgrade to three days. Three combinations also require forensic triage.

The inputs are not new metadata. Automatability and technical impact are SSVC decision points that CISA already publishes through its Vulnrichment program. Mallory ingests Vulnrichment, the KEV catalog, and the NVD into the same corpus as the PoCs, advisories, and detections, so a CVE arrives already scored against the directive's variables.

The implementation guidance sets the clock:

• Scoping within 2 hours of the KEV addition.
• Volatile evidence collection within 24 hours, before patching.
• Triage analysis and an escalation decision within 72 hours: no evidence of compromise, suspected, or confirmed.

Different inputs

Remediation needs a patch and a maintenance window. Triage needs to know what exploitation looks like: the artifacts it leaves, the log entries it generates, the behavior that follows. CISA will publish IOCs and triage steps in the KEV entry when it has them. It won't always have them in the first hours after an addition.

The burden shifts to three places:

• Vendors: advisories need exploitation artifacts, detection guidance, and log locations, not just a patch link and a CVSS score.
• Defenders: vulnerability management and incident response now run on the same clock. A KEV addition triggers both.
• Tooling: when the entry lands, someone has to answer what to look for, on which assets, immediately.

That last one is an intelligence problem, not a scanner problem. Scanners locate vulnerable instances. They don't collect the PoCs, IOCs, detections, and adversary activity scattered across advisories, blogs, and researcher chatter in the hours after a KEV addition.

Example: CVE-2026-10520

The first vulnerability on the new clock is live right now. CVE-2026-10520: pre-auth OS command injection in Ivanti Sentry, CVSS 10.0, root RCE on a publicly exposed gateway. Here is the timeline from our data:

• June 9, 14:10 UTC: Ivanti publishes the advisory.
• June 9, 21:55: watchTowr publishes a proof of concept on GitHub, about 8 hours later.
• June 10, evening: Shadowserver reports broad exploitation attempts against Sentry instances.
• June 11: CISA adds it to the KEV. Three more PoC repos appear. Suricata and Emerging Threats detection rules land that evening.
• June 12: agencies have until Sunday to remediate and complete forensic triage.

When the KEV entry landed, the PoC had been public for roughly 30 hours and exploitation had been observed for half a day. The information a triage team needs existed: what the exploit sends, what artifacts it leaves, which detection rules to deploy. It was spread across 133 sources we tracked for this one CVE: the vendor advisory, national CERT bulletins from three countries, four PoC repositories, detection rule pull requests, researcher analysis, and social reports.

The artifacts

Mallory's analysis of the watchTowr PoC turns that into a concrete hunt. Exploitation is a single unauthenticated POST to /mics/api/v2/sentry/mics-config/handleMessage with a message form field carrying a commandexec XML block that runs an arbitrary command as root. A server that executed it returns the markers Message handled successfully and <result><success>.

That points the hunt at specific logs. Search the appliance web server access log for POSTs to that endpoint with commandexec or reqandres in the body. Then correlate against the Linux audit log (/var/log/audit/, /var/log/messages) for the Java process spawning a shell: /bin/sh, id, whoami, curl, or wget. Unexplained admin accounts point at the paired CVE-2026-10523. Shadowserver honeypots were recording these attempts on June 10, a day before the KEV addition, and reported some instances already backdoored.

None of that came from the vendor. Ivanti's advisory shipped the patch and, asked how to tell if you had been compromised, stated there were no indicators of compromise to provide. The log paths, the request strings, the process-spawn correlation: all of it was assembled by researchers and responders in the days after disclosure.

The 72-hour triage clock does not include time to assemble that. Teams that can't do it fast start their compromise assessment with the CVE description.

This won't stay federal

BOD 26-04 binds federal civilian agencies. But KEV timelines became the de facto SLA for many private-sector programs, and auditors, insurers, and boards tend to adopt CISA's expectations. If your program treats the KEV as an input today, expect "can we determine whether we were already compromised" to follow.

- jcran