How to Triage a CISA KEV Addition in 72 Hours

When CISA added the Zimbra command injectionCommand Injection🛡️A security vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. that allows attackers to execute arbitrary operating system commands on the host system through a vulnerable application. CVE-2026-73570 to the Known Exploited Vulnerabilities catalog on August 21, 2026, it gave federal agencies until August 24 to remediate. Three days. The usual BOD 22-01BOD 22-01🛡️CISA Binding Operational Directive 22-01, which requires U.S. Federal Civilian Executive Branch agencies to remediate vulnerabilities listed in the Known Exploited Vulnerabilities catalog by a set deadline. CISA shortens the deadline when exploitation is widespread. window is three weeks, and CISA compresses it when exploitation is already widespread. Whether or not you are a federal agency, that shortened deadline is the most useful risk signal you will get for free, and it deserves a process rather than a scramble.

This is that process. It assumes you have a vulnerability management function of some kind, even if it is one person with a spreadsheet.

Hour 0 to 4: Confirm Scope

The first question is not "how do we patchPatch🛡️A software update that fixes security vulnerabilities, bugs, or adds improvements to an existing program." but "are we affected." KEV entries are deliberately terse; the scoping details live in the vendor advisory and in the reporting that prompted the addition.

Pull three things: the vendor advisory, the CISA entry, and at least one independent write-up from a source that read the advisory carefully. Extract the affected versions, the affected components, and any preconditions. For the Zimbra case, the preconditions were specific: the optional zimbra-snmp package had to be installed with notifications enabled. An organization running Zimbra 10.1.19 without that package was not exposed to this CVE.

Then inventory. If your asset management can answer "which hosts run product X at version Y with component Z" in minutes, use it. If it cannot, that is a finding for later; for now, check manually and record what you find. Hosted instances count. Ask the provider directly and get a written answer.

Output of this phase: a list of in-scope hosts, or a documented determination that there are none.

Hour 4 to 12: Prioritize Within Scope

Not every affected host carries the same risk. Rank by exposure and by blast radius.

Exposure: is the vulnerable service reachable from the internet? For a mail server, SMTP is always exposed, so the answer is yes by definition. For an internal monitoring agent, the answer might be no, which lowers urgency without eliminating it.

Blast radius: what does the vulnerable process have access to? Command execution as the zimbra user reaches every mailbox, the LDAP configuration, and every credential the mail server uses. That is a high-blast-radius host even though the account is not root.

Internet-facing plus high blast radius goes first. Everything else follows in order. Write the order down so that when someone asks why host B was patched before host A, the answer exists.

Hour 12 to 36: Patch or Mitigate

Apply the vendor fix to the top of the list first. For the Zimbra case, that meant upgrading to 10.1.20 or later.

Where the fix cannot be applied inside the window, because of change control, a dependency, or a maintenance contract that has lapsed, apply the interim mitigation the vendor or the reporting body recommends. Disabling the vulnerable component, restricting the reachable port, or removing an optional package are all legitimate temporary controls. What makes them legitimate is documentation: what was done, who owns it, and when it will be replaced by the real fix.

Do not skip mitigation because the patch is "scheduled for next week." The KEV timeline exists because the bug is being exploited now.

Hour 36 to 60: Hunt

This is the phase most organizations skip, and it is the one that determines whether you actually responded or just closed the door after the visitor left.

If the vulnerability was public and your host was exposed before you patched, you need evidence either way. The reporting body usually provides indicators. CERT Polska's guidance for the Zimbra case was specific: unexpected service restarts in the Zimbra log, and files created recently by the zimbra user in the Jetty webapp directories or in /tmp. Those are web shellWeb Shell🛡️A malicious script placed in a web server's content directory that lets an attacker execute commands through HTTP requests. Web shells are a common persistence mechanism after remote code execution and are detected by looking for unexpected files in webapp directories. signatures.

Check every in-scope host, including the ones you patched first. Patching removes the entry point; it does not remove anything the attacker already installed. If you find indicators, stop treating this as vulnerability management and start treating it as incident response: preserve evidence, isolate, rotate credentials, and rebuild.

If you find nothing, record that you looked, what you looked for, and when. Absence of evidence is only meaningful if the search was real.

Hour 60 to 72: Document and Close

Produce a short record: the CVE, the scope determination, the hosts affected, what was done to each, the hunt results, and any residual risk. Two pages is plenty. This record is what you will hand to an auditor, an insurer, or your own future self when the same product appears in the KEV again. Zimbra has 18 entries in the catalog; a repeat is not hypothetical.

Then look at what the exercise revealed about your environment. If scoping took twelve hours because inventory was manual, that is the improvement to fund. If the vulnerable component was an optional package nobody remembered installing, that points at reducing mail server attack surface as a standing practice rather than a one-time cleanup.

Why the Structure Matters

The order is deliberate. Scope before prioritize, so you are ranking real hosts. Prioritize before patch, so the most exposed system is fixed first. Patch before hunt, so the hunt is not racing an open door. Hunt before close, so closure means something.

Understanding how command injection works in network-facing services helps with the scoping phase in particular, because it lets you reason about preconditions and reachability without waiting for someone else to explain them. The Zero-DayZero-Day🛡️A security vulnerability that is exploited or publicly disclosed before the software vendor can release a patch, giving developers 'zero days' to fix it. Vulnerability Response guide covers the broader case where no patch exists yet; this process is for the more common situation where the patch exists and the question is whether you get to it before the attacker does.