When a critical CVE drops, the real question is not whether to patch. It's which server gets patched first. You patch everything eventually, but your Tuesday afternoon has finite hours and a production environment cannot reboot itself seventeen times. A triage framework separates the fires from the smolder.
I have seen teams scramble to patch every CVSS 9+ finding in alphabetical order while an internet-facing WordPress install with a known exploit sits untouched for three days. The score alone does not tell you enough. You need exploit availability, asset exposure, and a handful of secondary signals that shift a CVE from "schedule it" to "patch it now."
CVSS score: the starting line, not the finish
CVSS gives you a number between 0.0 and 10.0. Critical starts at 9.0. The score comes from eight base metrics: attack vector, attack complexity, privileges required, user interaction, scope, confidentiality impact, integrity impact, and availability impact.
A remote, unauthenticated RCE with no user interaction will score high. A local privilege escalation requiring an authenticated session scores lower. The system is transparent, and you can decode any CVE's score by reading the vector string.
But two CVEs with identical 9.8 scores can have wildly different real-world risk. One might affect a library your application never calls. Another might sit in the authentication layer of your public API. CVSS measures theoretical severity, not actual danger to your specific infrastructure.
Treat the score as a filter. Anything below 7.0 goes into the regular patch cycle unless you have a specific reason to escalate. Between 7.0 and 8.9, check exploit status and exposure. At 9.0 and above, you move fast, but you still triage.
Exploit availability: theory versus weaponized code
A vulnerability without a public exploit is a different animal than one with working proof-of-concept code on GitHub. When CISA's Known Exploited Vulnerabilities catalog lists a CVE, that means active exploitation in the wild. Patch those first.
Check three places: the CVE record itself for references to exploits, public exploit databases, and security vendor advisories. If researchers published working code, assume attackers are already scanning for it. If exploit code is not public but the CVE description is detailed enough to write one, expect exploits within days for high-value targets.
Some CVEs get proof-of-concept code within hours of disclosure. Others stay theoretical for months. The gap between publication and weaponization is your window, and it varies wildly. A remote code execution bug in a popular web server gets exploited immediately. A niche protocol parser in a desktop application might never see real attacks.
Prioritize any CVE with confirmed active exploitation, even if the CVSS score is mid-range. An 8.1 with working exploits beats a 9.5 that requires obscure preconditions nobody has automated yet.
Asset exposure: internet-facing versus internal
An RCE in your internal monitoring stack is serious. An RCE in your public-facing web application is a five-alarm fire. Exposure to untrusted networks multiplies risk because the attack surface is unlimited.
Inventory your assets by exposure tier:
- Tier 1: Internet-facing services (web servers, APIs, mail relays, DNS resolvers with recursion enabled)
- Tier 2: Internal services accessible from the DMZ or partner networks
- Tier 3: Fully internal systems behind multiple network boundaries
Patch Tier 1 first, always. If a critical CVE affects both your public WordPress site and your internal Ansible control node, the WordPress site gets patched in the next maintenance window. The control node can wait a week if necessary.
Don't forget about services you deployed once and forgot. That test Jenkins instance on port 8080, still running and internet-accessible, probably has six critical CVEs by now. Asset discovery tools help, but a manual nmap scan of your public IP ranges once a quarter catches the orphans.
Privileges required: unauthenticated beats everything
CVSS tracks whether an attacker needs credentials. Unauthenticated vulnerabilities are automatically higher priority because the barrier to exploitation is zero. An attacker does not need to steal credentials, phish a user, or compromise an adjacent system first. They just send a packet.
Authenticated vulnerabilities still matter, especially in environments where credentials leak regularly (think WordPress admin panels with weak passwords, or SSH keys committed to public repos). But if you are triaging two critical CVEs and one requires admin access while the other works without any login, patch the unauthenticated one first.
The exception: if the authenticated vulnerability affects a service where you know credentials have leaked or where a recent breach occurred, escalate it. A post-auth RCE on a system where an attacker already has a foothold is effectively unauthenticated.
Attack complexity: low complexity means automated scans
CVSS distinguishes between low and high attack complexity. Low complexity means exploitation is straightforward and reliable. High complexity means success depends on timing, rare configurations, or conditions outside the attacker's control.
Low-complexity vulnerabilities get scripted into mass-scanning tools within hours of public disclosure. Shodan and Censys light up with scanners probing for the vulnerable version. If your server is visible, it will be probed. High-complexity bugs might never see automated exploitation.
When two CVEs have similar scores and exposure, the low-complexity one moves up the queue. It's more likely to be exploited at scale, and automated attacks hit faster than targeted ones.
User interaction: does someone need to click?
User interaction required (UIR) drops a CVE's priority slightly because exploitation depends on human behavior. A stored XSS bug needs an admin to visit a specific page. A malicious file upload needs a user to trigger processing.
That said, UIR is not a reason to delay patching internet-facing systems. Social engineering is cheap, and attackers are patient. If the vulnerable application is a content management system where multiple users log in daily, user interaction is nearly guaranteed.
UIR matters more for internal tools with limited user bases. A bug in an admin-only interface accessed twice a month is less urgent than the same bug in a customer-facing portal hit thousands of times per hour.
Scope: does the vulnerability break containment?
CVSS v3 introduced scope to measure whether a vulnerability can affect resources beyond its original security boundary. A scope change means an attacker can escape a sandbox, pivot to other systems, or access data outside the vulnerable component's intended reach.
Container escapes, VM breakouts, and privilege escalations that cross trust boundaries all have changed scope. These are high-priority even if the initial impact seems limited, because they turn one compromised component into a foothold for lateral movement.
A vulnerability that only affects the component it sits in (unchanged scope) is easier to contain. You patch it, but you are not worried about an attacker using it to compromise your entire environment. Scope changes mean cascading risk, and you prioritize accordingly.
Impact triad: confidentiality, integrity, availability
CVSS measures impact in three dimensions. High confidentiality impact means an attacker can read sensitive data. High integrity impact means they can modify data or code. High availability impact means they can crash services or cause denial of service.
For hosting environments, integrity and availability often matter more than confidentiality. A vulnerability that lets an attacker deface your customer's website or take down your mail server causes immediate visible damage. A data leak is serious, but it might go unnoticed for weeks.
That said, confidentiality impacts hit hard when the data is credentials, payment information, or personal records subject to regulatory requirements. A database exposure bug affecting customer PII jumps the queue even if the CVSS score is mid-range, because the compliance and legal fallout is worse than a temporary outage.
Vendor patch availability: is there a fix you can deploy?
Some CVEs get disclosed before a patch exists. Others have patches, but only for certain versions or platforms. Before you prioritize a CVE, confirm that a patch or workaround is actually available for your environment.
If no patch exists, your options narrow to mitigation: disable the vulnerable feature, restrict network access, deploy a WAF rule, or isolate the affected system. Mitigation buys time but is not a substitute for patching. Track zero-day and unpatched CVEs separately and revisit them weekly.
When a vendor releases a patch, check the release notes for side effects. I have seen security patches introduce regressions that broke production applications. Test critical patches in a staging environment first unless the CVE is actively exploited, in which case you patch production immediately and deal with breakage if it happens.
Dependency depth: how many layers down is the vulnerable code?
A CVE in a library your application imports directly is easier to assess than one buried four levels deep in a transitive dependency. You need to know whether your code actually calls the vulnerable function. Dependency scanning tools help, but they often flag vulnerabilities in unused code paths.
If your application uses a library that depends on a vulnerable component, but your code never triggers the code path that hits the vulnerability, the risk is lower. That does not mean ignore it—software evolves, and a future feature might suddenly call that path—but it does mean you can defer the patch if higher-priority CVEs need attention.
For web applications, check whether the vulnerable library is client-side or server-side. Client-side JavaScript vulnerabilities require user interaction and are harder to exploit at scale. Server-side vulnerabilities in your application stack are immediate priorities.
Putting it together: a triage checklist
When a new critical CVE lands, run through this sequence:
- CVSS score 9.0 or higher? If not, it waits unless other factors escalate it.
- Public exploit available? Check CVE databases, exploit-db, and GitHub. If yes, escalate.
- CISA KEV listing? If the CVE is on the Known Exploited Vulnerabilities list, patch within the deadline (usually 14-21 days, but often sooner).
- Internet-facing asset affected? If yes, move to the top of the queue.
- Unauthenticated or low-complexity? Both factors increase likelihood of automated exploitation.
- Patch available and tested? If no patch exists, implement mitigations and track daily.
- Impact aligns with your risk priorities? Data exfiltration, service disruption, or credential theft—whatever your organization fears most gets priority.
This is not a scoring formula. It's a mental checklist. Two people triaging the same CVE list might order things slightly differently based on their environment, but both will catch the genuinely urgent ones.
What about compensating controls?
A WAF, an IPS, or a properly configured firewall can reduce risk while you prepare to patch. Compensating controls buy time, but they are not a permanent fix. WAF rules get bypassed. Firewall rules get misconfigured. The only real solution is patching the vulnerability.
That said, if you have a zero-day CVE with no patch and active exploitation, compensating controls might be all you have. Deploy them, monitor closely, and recheck vendor advisories daily for updates.
For internal systems, network segmentation is your best compensating control. If an attacker cannot reach the vulnerable service, the CVE is effectively neutralized. That gives you time to schedule the patch during a planned maintenance window instead of an emergency reboot at 2 AM.
What to check first
When a critical CVE announcement hits your inbox, pull up the CVE record and scan for three things: CVSS vector string, exploit availability, and affected versions. Cross-reference your asset inventory. If the CVE affects an internet-facing service and exploits exist, you are patching today. If it is internal-only with no known exploit, you have a few days to test.
Triage is about making smart decisions with incomplete information under time pressure. The goal is not perfect prioritization. The goal is ensuring the vulnerabilities most likely to cause real damage get fixed before an attacker finds them. Everything else is scheduling.