You get the alert: fifteen critical CVEs dropped overnight. Your maintenance window is four hours next Tuesday. Something has to give.
The vendor calls everything critical. CVSS scores hover between 9.1 and 9.8. But your production web servers, your mail stack, and your DNS infrastructure all run different versions of the affected software. You can't patch everything at once without risking extended downtime, and not every vulnerability presents the same real-world risk to your environment.
I've seen admins waste weekend emergency maintenance windows patching theoretical risks while leaving genuinely dangerous exposures untouched for weeks. The triage framework that follows is what I use when the patch queue exceeds available maintenance slots.
The three-axis decision model
Every CVE gets evaluated on three independent axes. Think of them as coordinates that place each vulnerability somewhere in three-dimensional risk space.
First axis: exploitability. Does working exploit code exist in the wild? A CVSS 9.8 vulnerability with no public proof-of-concept is less urgent than a CVSS 7.5 with exploit kits actively scanning for it. Check whether the CVE has a KEV listing, search GitHub and exploit databases, and watch your WAF or IDS logs for reconnaissance patterns.
Second axis: exposure. Is the vulnerable service reachable from the internet, or is it bound to localhost and only accessed by internal processes? A critical PHP vulnerability matters more on your public WordPress host than on a cron script that processes local files. Asset inventory is not optional here.
Third: business impact if exploited. What can an attacker do with successful exploitation, and what data or systems would be compromised? Remote code execution on your billing database server outranks information disclosure on a staging environment, even if both have identical CVSS scores.
CVSS scores are a starting point, not a verdict
CVSS gives you a common vocabulary and a rough severity band. That's useful. But the score comes from a formula that weighs attack complexity, privileges required, and impact scope in a generic way. It doesn't know your network architecture.
A vulnerability rated critical because it allows unauthenticated remote code execution sounds terrifying. If that service is firewalled to a management VLAN and requires VPN access, your exposure is minimal. Conversely, a moderate-severity authentication bypass in your public-facing control panel is a five-alarm fire if customer accounts are at stake.
I treat anything above CVSS 7.0 as a candidate for the priority list, but the final ranking depends on the other two axes. Scores below 7.0 go into the regular patch cycle unless I see active exploitation or unusual environmental factors.
Exploit availability changes everything
When exploit code goes public, the clock starts ticking in hours, not days. Automated scanners pick it up fast. I've watched access logs fill with probes within six hours of a Metasploit module release.
Check these sources during triage: the CVE's reference links, CISA's Known Exploited Vulnerabilities catalog, security mailing lists for your software stack, and GitHub search for the CVE identifier. If you find proof-of-concept code or worse, weaponized exploits, that CVE jumps the queue.
Active exploitation in the wild is the loudest signal. If your IDS is logging attempts or you see chatter in incident response communities about mass scanning, patch that vulnerability first. Everything else can wait.
Map your exposure surface
You need an asset inventory. Not a vague notion of what runs where—an actual list.
For each server and service, document which software versions are installed, which ports are open to the internet, and what internal network segments have access. When a CVE lands, you should be able to answer "do we run this?" in under five minutes.
Public exposure multiplies risk. A vulnerable Apache version on a server behind Cloudflare with strict WAF rules is a different threat profile than the same version on a VPS with port 80 open to the world. If the service isn't reachable externally and doesn't process untrusted input, you've bought yourself time.
Internal services still matter, especially if your network has been breached or if the service handles escalated privileges. But they rank below internet-facing vulnerabilities in most triage decisions.
Business context completes the picture
Two servers, same vulnerability, same exposure. Which do you patch first?
The one that processes payment data, stores customer records, or runs your primary revenue application wins. Impact isn't just about technical severity. It's about what breaks, what leaks, and what stops making money if an attacker gets in.
I assign every asset an implicit criticality tier. Tier one is production infrastructure that directly serves customers or handles sensitive data. Tier two is internal tooling and staging environments. Tier three is dev boxes and isolated test systems. When patches compete for the same maintenance window, tier-one assets go first.
Compliance requirements also factor in. If your environment is subject to PCI-DSS, HIPAA, or GDPR, certain vulnerabilities trigger mandatory remediation timelines. A critical CVE in scope for your audit is non-negotiable, even if the technical risk seems manageable.
The triage workflow I actually use
When CVEs arrive, I run through this checklist in order:
- Applicability check: Do we run the affected software and version? If no, archive and move on.
- Exposure audit: Is the vulnerable component reachable from untrusted networks? Check firewall rules, listening ports, and reverse proxy configs.
- Exploit status: Search for public exploits, KEV listings, and scanning activity. If exploits exist, flag for immediate review.
- Impact assessment: What can an attacker do? RCE and authentication bypasses rank highest, followed by privilege escalation and data exposure.
- Compensating controls: Do we have WAF rules, network segmentation, or other layers that mitigate the vulnerability? These reduce urgency but don't eliminate it.
- Asset criticality: Which systems are affected, and what's the business impact if they're compromised?
After running this checklist, I slot each CVE into one of four buckets: patch within 24 hours, patch in the next maintenance window, patch within 30 days, or defer to the next major upgrade cycle. The first bucket is reserved for internet-facing systems with public exploits. The last is for low-exposure internals with no active threat.
What if you can't patch immediately?
Sometimes the patch isn't ready, the vendor hasn't released a fix, or your environment is too fragile to touch without extensive testing. You still have options.
Network-level mitigation comes first. Block access to the vulnerable service at the firewall if external exposure is the risk. Restrict it to known-good IP ranges or internal VLANs. This buys you time to test the patch properly.
Web application firewalls can block specific attack patterns. If the CVE involves a particular HTTP header, parameter, or exploit string, write a custom rule. It's not a substitute for patching, but it closes the immediate window.
Disable the vulnerable feature if you don't need it. Many CVEs target optional modules, plugins, or APIs that aren't essential to your workload. Turn them off until you can patch safely.
Monitor aggressively. Increase logging verbosity, set up alerts for unusual access patterns, and review logs daily. You want early warning if someone is probing or exploiting the vulnerability while you prepare to patch.
Testing patches before you deploy them
Critical doesn't mean untested. I've seen patches that fixed one CVE and broke production in new and exciting ways. Your staging environment exists for this.
Deploy the patch to a non-production system that mirrors your production config. Run through your standard smoke tests: Does the service start? Do critical workflows complete? Are there new errors in the logs?
For web applications, test user-facing functionality and administrative interfaces. For system packages, verify that dependent services still work. A patched OpenSSL library that breaks your mail server's TLS is not an improvement.
If testing reveals issues, decide whether the risk of the vulnerability outweighs the risk of the broken patch. Sometimes you hold off and push the vendor for a hotfix. Sometimes you implement compensating controls and wait for the next release. There's no universal answer, but an informed decision beats a blind one.
Start with your inventory
You can't triage what you can't see. If you walked away from this article with one action item, it should be building or updating your asset inventory. List every server, every service, every open port, and every software version.
When the next batch of CVEs drops, you'll have the map you need to make fast, defensible decisions about what to patch first. The triage framework is only as good as the data you feed it.