How we triage critical CVEs for clients

A scanner finding with a CVSS score of 9.8 gets attention, but it does not automatically answer the operational question: what should we patch first?

The National Vulnerability Database explains that CVSS describes technical severity, not risk. A critical flaw in a disabled component on an isolated test system may be less urgent than a lower-scored flaw being exploited against an internet-facing gateway. Treating the score as a patch clock creates noise, burns maintenance windows, and can leave the most exposed system waiting in the same queue as everything else.

A useful MSP triage process combines four questions: is the asset actually affected, can an attacker reach the vulnerable path, is exploitation happening or likely, and what would compromise mean to the business?

Start with a decision record, not a headline

Before assigning urgency, capture enough evidence for another technician to reproduce the decision:

• The CVE, vendor advisory, affected product, installed version, and enabled feature
• The asset, business owner, service purpose, and whether it is in production
• Internet and internal exposure, including any authentication or network boundary
• Fixed version, vendor mitigation, and known upgrade prerequisites
• CISA Known Exploited Vulnerabilities status and the date checked
• EPSS probability and percentile, also with the date checked
• Expected technical impact, business impact, maintenance window, and rollback owner

The vendor advisory is the starting point for affected versions and fixes. A generic scanner can identify candidates, but it may not understand a vendor backport, disabled module, or build-specific mitigation. Verify the running build on the asset instead of relying only on an inventory label.

This is also why a current external inventory matters. If no one can say which firewalls, remote-management portals, or web applications are public, urgency becomes guesswork. Our guide to inventorying public websites and services provides a simple starting record.

Evaluate five dimensions

1. Applicability

First prove that the vulnerable code exists and is reachable in the installed configuration. Check the exact version, platform, licensed features, and vendor conditions. Record “not affected” only with evidence; do not close a finding because a product name merely looks different.

2. Exposure and reachability

Direct internet exposure usually increases urgency, but reachability is more precise than an internet yes-or-no field. Ask whether exploitation requires a VPN account, local network access, user interaction, or a previously compromised endpoint. Consider whether segmentation actually blocks the path and whether the control has been tested.

CISA’s internet exposure reduction guidance recommends maintaining an exposure inventory, deciding whether each service must remain public, mitigating unnecessary exposure, and checking again over time. Disabling an unused public feature can sometimes reduce immediate risk faster than an emergency upgrade.

3. Exploitation evidence and likelihood

The CISA Known Exploited Vulnerabilities catalog is an authoritative list of vulnerabilities observed being exploited in the wild. A relevant KEV entry is strong evidence for urgent action. Absence from KEV is not proof that exploitation is impossible or has not started.

FIRST’s Exploit Prediction Scoring System estimates the probability that a CVE will be exploited in the next 30 days and updates daily. It can help separate thousands of theoretical findings, but EPSS is not a complete risk score: it does not know the value of your system, the damage an exploit could cause, or your compensating controls. Save both the probability and percentile with the check date rather than copying a changing number into a permanent label.

A public proof of concept raises concern, especially when it is reliable and easy to use, but it is not the same as confirmed exploitation. Validate claims against CISA and the vendor instead of assigning emergency status from a social-media post.

4. Technical consequence

Different outcomes deserve different treatment. Pre-authentication remote code execution or authentication bypass on an edge device generally has a more dangerous path than a denial of service requiring a logged-in local user. Note the required privileges, user interaction, scope change, persistence options, and whether successful exploitation exposes credentials or a management plane.

5. Business criticality and blast radius

Finally, map the technical result to the organization. An identity provider, firewall, backup console, or remote-management system can become a path to many other assets. Include the number of affected systems, sensitive data involved, redundancy, recovery readiness, and the operational risk of a rushed change.

Business criticality should not excuse an exposed system from patching. It tells you how much coordination, testing, and rollback preparation the fix requires.

Put the result into a clear action lane

We use the evidence to choose an action, not to invent a mathematically precise score:

• Emergency action: The asset is affected and reachable, credible active exploitation exists, and compromise could have serious consequences. Reduce exposure immediately, prepare the fix, and involve the incident lead if logs suggest attempted or successful access.
• Accelerated change: Exploitability is high or exploit material is available, the path is plausible, and the impact matters, but the evidence does not require an all-hands response. Assign an owner and a near-term maintenance window.
• Scheduled remediation: The flaw applies but has limited reachability, lower likely consequence, or effective verified controls. Patch within the organization’s vulnerability-remediation standard and keep monitoring vendor and KEV updates.
• Track or not affected: The product is not vulnerable, the component is absent, or a vendor-supported fix is not yet available. Document the proof, review new intelligence, and time-box any temporary mitigation.

CISA’s Stakeholder-Specific Vulnerability Categorization guide uses a similar decision-tree idea: exploitation status, technical impact, and mission impact lead to an action outcome. An SMB can use that reasoning without copying federal deadlines that do not fit its environment.

Compensating controls need an expiration date

Removing a service from the internet, disabling the affected feature, restricting management access, or applying a vendor-provided filter can buy time. A WAF signature or firewall rule is useful only if it covers the vulnerable path and its logs are watched. None of these should quietly become the permanent substitute for a supported fix.

Record who implemented the control, how it was tested, what telemetry should fire, and when it will be reviewed. The Ubiquiti security bulletin patch guide shows how version checks and temporary exposure reduction fit around a vendor update.

Close the loop after the change

After patching, verify the running version, not just the installer’s success message. Test the service from a user’s perspective, confirm that external exposure still matches the intended design, and review security logs covering the period before remediation. If the asset was publicly reachable and exploitation was plausible, use an incident first-hour checklist rather than assuming the patch erased earlier activity.

Browser fleets and office endpoints still need reliable routine deployment, so emergency triage should feed back into normal operations. The same discipline behind Chrome zero-day patch habits and Windows update rings keeps the next urgent advisory from becoming a manual scramble.

The goal is not to make every vulnerability quiet. It is to make urgency explainable: affected asset, reachable path, credible exploit evidence, meaningful consequence, named owner, verified remediation.