A CVSS 9.8 critical vulnerability lands in your inbox at 3 PM on a Friday. Do you patch it immediately and risk breaking production, or wait until Monday and hope nobody finds the exploit first?
I've watched teams scramble to patch every CVE marked "critical" only to realize half of them didn't even affect their infrastructure. The vendor marked it critical. The scanner flagged it red. But the vulnerable service wasn't exposed, or the attack required local access your threat model doesn't include.
Real triage means weighing three factors: the technical severity (CVSS), whether attackers can actually use it (exploit availability), and whether your infrastructure gives them a way in (asset exposure). Patch everything eventually, but fix the right things first.
What CVSS scores actually measure
CVSS—the Common Vulnerability Scoring System—breaks down to a number between 0 and 10. Anything 9.0 or higher gets labeled critical. Sounds simple until you realize the score combines eight different metrics, and most people only look at the final number.
The base score has three groups: exploitability, impact, and scope. Exploitability covers attack vector (network, adjacent, local, physical), attack complexity (low or high), privileges required (none, low, high), and user interaction (none or required). Impact measures confidentiality, integrity, and availability loss. Scope asks whether the vulnerability breaks out of its original security boundary.
A remote code execution bug that needs no authentication and no user interaction will score higher than one requiring an authenticated session and a specific configuration. Both might be critical, but one is trivially exploitable and the other demands more attacker effort.
The temporal score modifies the base score based on exploit maturity, remediation level, and report confidence. Vendors often skip publishing temporal scores, so you calculate them yourself. An unproven theoretical vulnerability scores lower than one with public exploit code.
Environmental scores let you adjust for your specific deployment—how critical the affected system is, what compensating controls you have in place, how exposed it is to attackers. Almost nobody calculates environmental scores because it requires effort. That's exactly why you should.
The attack vector matters more than the number
A CVSS 9.8 with network attack vector and no privileges required? That's a wormable RCE. Patch it now.
A CVSS 9.3 requiring local access and high privileges? Still critical on paper, but an attacker already needs root or physical access. If your threat model stops at the network perimeter and you trust your local users, this drops in priority behind the network bugs.
I've seen admins delay patching a 7.5 CVSS authentication bypass that was getting hammered in the wild while rushing to fix a 9.1 local privilege escalation nobody could reach. The number alone doesn't tell you urgency.
Exploit availability changes everything
A vulnerability with proof-of-concept code in the wild is not the same as one with only a technical description. When researchers publish a CVE, they usually hold back working exploit code for a responsible disclosure period. Once that period expires, exploits hit GitHub, Metasploit modules appear, and automated scanners start probing.
You want to know three things: is there public exploit code, is it being used in the wild, and how reliable is it?
Check Exploit-DB, GitHub, and Metasploit's module database. Search for the CVE number plus "exploit" or "PoC". Look at the disclosure timeline—vulnerabilities older than 30 days with public exploits are fair game for every attacker.
The Exploit Prediction Scoring System (EPSS) estimates the probability a CVE will be exploited in the next 30 days. An EPSS score above 10% means real danger. Above 50% means it's probably already happening.
Some CVEs get exploited before the patch even drops—zero-days. If threat intel feeds show active exploitation, it jumps to the front of the queue no matter what the CVSS score says. I'd rather patch a 6.5 being actively exploited than a 9.0 nobody's figured out yet.
When proof-of-concept means production ready
Not all PoC code is equal. Some researchers publish sanitized examples that demonstrate the flaw but require significant attacker skill to weaponize. Others accidentally publish production-ready exploits that any script kiddie can fire off.
If the PoC includes a working shell, requires minimal modification, or has already been incorporated into exploitation frameworks, treat it as actively exploited even if your threat feeds don't show it yet. The gap between PoC publication and mass scanning is measured in hours now.
Asset exposure is your real attack surface
You can have a critical RCE with public exploit code, but if the vulnerable service isn't reachable, your actual risk is zero. This is where most automated scanners fail—they flag every installed package without asking whether it's exposed.
Start by identifying where the vulnerable component runs. Is it a kernel bug? Every server is affected. A web application dependency? Only your web-facing hosts matter. A library used by internal tooling that never touches the network? Still patch it, but not tonight.
Then ask what network exposure it has. Internet-facing services are obviously high priority. Internal services behind a firewall are lower. Localhost-only services that never bind to a network interface are lowest.
Check whether compensating controls reduce the risk. A vulnerable Apache version behind a WAF with virtual patching rules might buy you time. A database with a CVE in its authentication module doesn't matter if that database only accepts connections from localhost and your application uses Unix sockets.
The exposure audit you should run first
Before you triage any CVE, know what you have exposed.
# List all listening services
sudo ss -tlnp
# Check for internet-facing ports
sudo iptables -L -n -v
# Enumerate running web services
sudo netstat -tlnp | grep -E ':(80|443|8080|8443)'
Cross-reference this with your vulnerability scan results. If a CVE affects nginx but nginx isn't running on that host, deprioritize it. If it affects a library your custom application imports but that code path is never executed, you have time to plan the patch.
I've seen entire teams waste weekends patching every server for a Java deserialization bug when only two hosts ran Java applications and both were internal tools.
The decision matrix that actually works
Here's how I prioritize when multiple critical CVEs land at once.
Patch immediately (tonight, emergency change): - CVSS 9.0+ with network attack vector - Public exploit code available - Service is internet-facing - EPSS score above 20% or active exploitation confirmed
Patch this week (next maintenance window): - CVSS 9.0+ but requires authentication or user interaction - Public exploit code exists but service is internal-only - CVSS 7.0-8.9 with network vector and internet exposure - No confirmed exploitation yet but PoC is reliable
Patch this month (planned maintenance): - CVSS 9.0+ but local attack vector only - CVSS 7.0-8.9 without public exploits - Vulnerable component is installed but not exposed - Compensating controls are verified working
Patch eventually (next major update cycle): - Any CVSS score if the component isn't actually used - Local exploits on hardened systems where attackers can't get local access - Vulnerabilities in EOL software you're already planning to replace
This isn't a formula. It's a framework. A 6.5 authentication bypass being mass-scanned beats a 9.1 kernel bug that requires physical access to the BIOS.
Document your triage decision
When you defer a critical CVE, write down why. "Vulnerable service not exposed to internet, internal firewall rules block access, planning patch during next maintenance window on [date]." If an incident happens later, you'll need to show you made a risk-informed decision, not that you ignored it.
Keep a triage log. Date, CVE number, CVSS score, EPSS score, exposure status, decision, and who approved it. It takes five minutes and saves you when compliance auditors ask why you didn't patch everything immediately.
What about dependency chains and transitive risks
Modern applications pull in hundreds of dependencies. A vulnerability in a library you don't directly use but that's required by something you do use is a transitive vulnerability. Your scanner will flag it. Your SBOM will list it. But is it actually exploitable in your context?
Check whether the vulnerable code path is reachable. A flaw in an XML parsing library doesn't matter if your application never parses XML. A deserialization bug is irrelevant if you never deserialize untrusted data.
Some dependency scanning tools now show reachability analysis—they trace code paths to determine whether vulnerable functions are actually called. If they are, patch it. If they're not, you can defer.
Be careful with this logic. An unreachable code path today becomes reachable tomorrow when someone adds a feature. If the patch is trivial (bump a version number in requirements.txt), just do it. If it requires refactoring because the new version breaks your API usage, then the cost-benefit calculation changes.
The upstream patching problem
You're running CentOS or Ubuntu LTS. A critical CVE drops. The vendor backports a fix to your release channel, but they don't bump the version number—they patch the existing version. Your scanner still flags it as vulnerable because it only checks version strings.
Verify whether your distribution already applied the fix. Check the distro security advisories. Look at the package changelog:
# Debian/Ubuntu
apt-cache policy <package-name>
apt-cache show <package-name> | grep -A 20 "^Version"
# RHEL/CentOS/Rocky
yum info <package-name>
rpm -q --changelog <package-name> | head -n 50
If the changelog references the CVE number, the fix is already in. Update your scanner's exception list and move on.
Patch smarter by measuring real risk
Not every critical CVE is a five-alarm fire. CVSS gives you severity, exploit databases tell you feasibility, and your network topology defines exposure. Combine all three and you get actual risk.
Patch the internet-facing RCE with a public exploit tonight. Schedule the authenticated internal bug for next week. Defer the local privilege escalation until the next maintenance cycle unless your threat model includes malicious insiders.
Document every decision so you can show your work when someone asks why a critical CVE sat unpatched for three days. Automate what you can—vulnerability scanning, EPSS score lookups, reachability analysis—but keep the final triage decision human. You know your infrastructure and threat model better than any scanner.
When you triage based on real risk instead of raw CVSS scores, you'll spend less time patching and more time securing the things that actually matter.