You wake up Monday to a vendor advisory listing seventeen critical CVEs across your stack. Your maintenance window is four hours on Saturday night. Patching everything means outages you can't afford, and the security team is asking which five vulnerabilities absolutely must ship this weekend.
This is the weekly reality for ops and security teams managing production infrastructure. The CVSS score alone won't tell you what to fix first, and treating every critical CVE as equally urgent is how you end up breaking production at 2 AM over a theoretical exploit that requires physical console access.
Here are the five factors experienced teams use to rank critical CVEs when the clock is ticking.
1. Active Exploitation in the Wild
A CVE with public exploit code or confirmed attacks jumps to the top of the queue. Full stop.
Check whether security vendors, CERTs, or the CVE description itself mention active exploitation. CISA maintains a Known Exploited Vulnerabilities catalog that flags CVEs being used in real attacks. If your CVE appears there, you patch it this cycle or implement a workaround immediately.
In support tickets I've handled, the difference between a theoretical remote code execution flaw and one with a Metasploit module is the difference between next-month patching and same-day emergency maintenance. Attackers script exploitation within hours of disclosure for high-value targets.
Look for phrases like "exploitation detected," "public PoC available," or "weaponized exploit." A GitHub repository with working exploit code means automated scanners will start hitting your infrastructure within days.
Where to Check Exploit Status
Start with the vendor advisory itself. Then cross-reference:
- CISA KEV catalog
- Exploit-DB and GitHub for public proof-of-concept code
- Security vendor blogs (Cloudflare, Akamai, Rapid7)
- Your WAF or IDS logs for exploit attempt signatures
If you see nothing, the CVE might still be critical, but you have breathing room to test the patch properly.
2. Asset Exposure and Attack Surface
A critical vulnerability in a service exposed to the internet outranks the same flaw in an internal-only system.
Map each CVE to your actual infrastructure. Does it affect your public-facing web servers, your internal ERP database, or a dev environment behind three layers of VPN? The public nginx instance serving customer traffic gets patched before the staging MySQL box that only DevOps can reach.
I rank exposure in three tiers:
Tier 1: Internet-facing — web servers, mail relays, DNS resolvers, API gateways, anything with a public IP and open ports.
Tier 2: Internal with elevated privilege — domain controllers, database primaries, backup systems, credential stores.
Tier 3: Isolated or low-privilege — dev boxes, CI runners, read replicas, monitoring agents.
A remote code execution CVE in an internet-facing Apache instance is a Saturday night emergency. The same CVE in a firewalled Jenkins controller accessed only by your team through SSH? Still important, but it can wait for the normal change window if you verify the firewall rules are tight.
Quick Exposure Audit
Run this to see what's actually listening:
sudo ss -tuln | grep LISTEN
Then cross-check your firewall:
sudo iptables -L -n -v
# or for firewalld
sudo firewall-cmd --list-all
If port 443 is open to 0.0.0.0/0 and the CVE affects your TLS library, that's tier one.
3. Vendor Severity Rating (With Context)
CVSS scores are a starting point, not gospel.
A 9.8 CVSS rating means the vulnerability has maximum theoretical impact under ideal attacker conditions. In practice, you need to read the CVE description and understand the attack prerequisites. Does it require authenticated access? Local shell access? A specific non-default configuration?
Vendors sometimes inflate scores to get attention or deflate them to avoid panic. Red Hat and Debian often publish their own severity assessments that account for how the package is typically deployed in their distributions. Trust vendors who explain their reasoning.
So what if the score is lower but your environment is uniquely exposed?
A "high" severity PHP deserialization bug might be critical for you if your app passes untrusted user input to unserialize(). Read the technical details, not just the headline score.
Adjusting Vendor Ratings
Ask three questions:
- Does the vulnerable code path execute in our deployment?
- Can an attacker reach it from their position (internet, internal network, localhost only)?
- What breaks if we patch it right now?
A critical kernel CVE that requires local access and your systems have no local user accounts? Still patch it, but maybe not this weekend if you're also dealing with an internet-facing RCE.
4. Availability of Workarounds and Compensating Controls
Sometimes you can mitigate a CVE without patching, buying time to test properly.
Vendor advisories often include workarounds: disabling a feature, changing a config, adding a firewall rule. If the workaround is low-risk and effective, apply it immediately and schedule the patch for your normal cycle with full regression testing.
Common compensating controls:
- Firewall rules to block attacker access to the vulnerable service
- WAF rules to filter exploit payloads
- Disabling optional features that contain the flaw (e.g., turning off an unused Apache module)
- Segmentation to isolate vulnerable systems
I've seen teams block external access to a vulnerable management interface with iptables while waiting for an upstream patch that needs kernel recompilation and validation. The firewall rule took two minutes. The patch cycle took two weeks. Both were correct responses.
Example: Apache mod_proxy CVE Mitigation
Imagine a CVE in mod_proxy_http. If you're not using reverse proxying:
# /etc/httpd/conf.modules.d/00-proxy.conf
# LoadModule proxy_module modules/mod_proxy.so
# LoadModule proxy_http_module modules/mod_proxy_http.so
Comment out those lines, restart Apache, verify your sites work, and you've mitigated the risk without touching the package.
5. Business Impact and Service Criticality
The last filter is business context. Which systems make you money, and which ones can tolerate downtime?
Your payment processing gateway and primary database cannot go down during business hours. Your internal wiki can. Even if both have critical CVEs, you patch the wiki first if it lets you practice the procedure with lower risk, or you schedule payment gateway patching for a true maintenance window with all hands on deck.
Rank your services by revenue impact and SLA commitments. A critical CVE in a service with 99.95% uptime guarantees gets more careful handling than one in a best-effort internal tool, even if both need patching.
This isn't about ignoring vulnerabilities. It's about sequencing fixes so you don't cause a bigger outage than any attacker would.
Building a Service Criticality Matrix
Document this before the next CVE drops:
| Service | Revenue Impact | Max Downtime | Patch Window |
|---|---|---|---|
| Payment API | Direct | 0 (HA failover only) | Sunday 2-6 AM |
| Web frontend | Direct | 30 min | Saturday 10 PM - 2 AM |
| Admin panel | Indirect | 2 hours | Weekday evenings |
| Monitoring | Indirect | 4 hours | Anytime with notice |
When a CVE lands, you instantly know which assets can absorb risk for testing and which require change approval from three VPs.
Real-World Triage Example
You receive advisories for five critical CVEs on Monday:
CVE-A: OpenSSL RCE, CVSS 9.8, public exploit available, affects your internet-facing nginx.
CVE-B: MySQL privilege escalation, CVSS 8.8, requires authenticated database user, affects your internal reporting DB.
CVE-C: Kernel local privilege escalation, CVSS 7.8, no public exploit, affects all servers.
CVE-D: WordPress plugin XSS, CVSS 9.0, no exploit yet, affects your customer portal.
CVE-E: Postfix DoS, CVSS 7.5, vendor workaround available (rate limiting), affects your mail relay.
Using the five criteria:
- CVE-A has active exploitation and internet exposure. Patch immediately or put the server behind Cloudflare and enable rate limiting as a temporary measure while you test the OpenSSL update.
- CVE-D is internet-facing but no exploit yet. Disable the vulnerable plugin right now if possible, schedule WordPress update for this weekend.
- CVE-E has a workaround. Implement Postfix rate limits today, schedule full patch next cycle.
- CVE-B is internal-only and requires auth. Audit database users, ensure principle of least privilege, patch within two weeks.
- CVE-C is kernel-level but needs local access and no public exploit. Schedule it with your quarterly kernel updates unless you have untrusted local users.
You've now turned five critical CVEs into a concrete action plan without needing to emergency-patch everything at once.
Automating the Triage Process
Large environments can't manually evaluate every CVE. Here's a simple scoring script concept:
# Pseudocode for CVE priority scoring
def score_cve(cve):
score = 0
if cve.has_public_exploit():
score += 50
if cve.is_in_cisa_kev():
score += 40
if cve.asset_exposure == 'internet':
score += 30
elif cve.asset_exposure == 'internal_critical':
score += 20
score += (cve.cvss_base / 10) * 10
if cve.has_workaround():
score -= 15
return score
You'd feed this your vulnerability scanner output and asset inventory, then sort by score. Anything above 80 gets emergency patching, 50-79 goes into the next maintenance window, below 50 gets scheduled normally.
The numbers are arbitrary. Tune them to your risk tolerance and resource constraints.
What to Check First
When the next batch of critical CVEs lands in your inbox, check exploit availability first and asset exposure second. Those two factors alone will tell you if you're looking at a drop-everything emergency or something you can handle in your normal change cycle.
Document your infrastructure's exposure and criticality before you need it. When you're scrambling at midnight, you don't want to be running nmap scans to remember which servers are public and which aren't.
Patching is risk management, not perfection. Fix what matters most first, buy yourself time for the rest, and test everything before it touches production.