How to Triage a Critical CVE

The CVE-of-the-week fire drill

A critical vulnerability lands in a widely used product, the headlines call it catastrophic, and within an hour someone forwards it to your team with a single-word message: "urgent?". The instinct is to drop everything and patch. Sometimes that instinct is right. Often it is a waste of a weekend on something that never touched your environment, while a genuinely reachable issue sits unnoticed.

Panic does not scale. What scales is a short, repeatable set of questions you ask every time, in the same order, so that the decision to declare an emergency is based on your exposure rather than on the severity of the headline. Here is the sequence we run.

Step 1 — Does it even apply to you?

Before anything else, confirm the vulnerability can exist in your estate at all. Two conditions must both be true: you are actually running the affected product, and you are running an affected version or configuration. A critical flaw in a product you decommissioned last year is not your problem, and a bug that only affects a feature you never enabled is a footnote. Most "urgent" forwards die at this step, which is exactly why it comes first.

Step 2 — Is it reachable?

An affected version that nothing can reach is a very different risk from one exposed to the internet. Work through the path an attacker would need:

• Is the vulnerable service internet-exposed, or only reachable from inside a segment?
• Does exploitation require authentication, and if so, at what privilege level?
• Are there preconditions — a specific setting, a non-default feature, a particular network position?

An unauthenticated, internet-facing instance with no preconditions is a five-alarm fire. The same bug behind authentication on an internal-only host, requiring a non-default configuration, may be a routine patch cycle.

Step 3 — Is it really exploitable?

"Critical" describes potential impact, not likelihood. Ask what the real-world exploitation picture looks like: is there a public proof-of-concept, or is exploitation still theoretical? What does the EPSS score suggest about the probability of exploitation in the near term? Is there credible evidence it is being exploited in the wild? A flaw with a working public exploit and active exploitation deserves a very different response from one that is severe on paper but has no known path to weaponization yet.

Step 4 — The CVSS base score is not your priority

It is tempting to sort your queue by CVSS base score and work top-down. Resist it. The base score is a context-free measure of a vulnerability in the abstract; it knows nothing about whether you run the product, whether it is reachable, or whether anyone can actually exploit it. A 9.8 on an internal service nobody can reach outranks, by the raw number, a 7.5 on your public login page — and that ordering is exactly backwards. Context beats the number every time. Use the score as one input, never as the sort key.

Step 5 — Mitigate now, patch smart

When triage says the issue is genuinely your emergency, the vendor patch is not always available immediately — and even when it is, deploying it safely takes time. Buy that time with temporary controls:

• Virtual patching / WAF rules to block the exploit pattern at the edge while you schedule the real fix.
• Segmentation to take the vulnerable service off the paths that expose it.
• Disable the feature if the flaw lives in a component you can turn off without breaking the business.

These are stopgaps, not solutions. They reduce the window of exposure so you can patch on a schedule you control rather than in a 3 a.m. scramble.

Step 6 — Verify the exposure is actually closed

Applying a patch is not the same as being safe. Test the update in a staging environment first so you are not trading a security incident for an availability one. Then confirm, from the attacker's perspective, that the exposure is genuinely gone — re-check the version, re-run the reachability test, and where possible attempt the exploit path against the patched system. A patch that was rolled back by an automated deployment, or that missed one host in the fleet, leaves you exactly as exposed as before while everyone believes the issue is handled.

Make it repeatable

The single most valuable output of your first CVE fire drill is a written runbook of these steps. Capture the version-check command for each critical product, the reachability questions, where you look up exploit and EPSS data, and who has authority to approve emergency mitigations. A quick command to confirm what you are actually running is the kind of thing you want on hand before the pressure is on:

# confirm the installed package version
dpkg -l | grep -i <package>
rpm -q <package>

# grab a version banner from a running service
curl -sI https://host.example/ | grep -i server

Wire those into a runbook and the next "urgent?" message becomes a fifteen-minute triage instead of a lost weekend. A calm, documented process beats panic — and it means the emergencies you do declare are the ones that genuinely deserve it.