Every month brings a fresh wave of CVEs labeled "critical." Your inbox fills with vendor alerts, your monitoring dashboard lights up red, and suddenly you're staring at forty patches that all claim to need immediate attention. They don't.
I've triaged hundreds of CVE reports across shared hosting clusters, VPS fleets, and cPanel servers. The math is simple: you can't patch everything at once, and not every critical score means critical risk to your infrastructure. The question isn't whether a CVE is dangerous in the abstract. It's whether it's dangerous to you, right now, given what you're running and who can reach it.
How CVSS scoring actually works
The Common Vulnerability Scoring System gives every CVE a number between zero and ten. A score above nine typically earns the "critical" label, but that score comes from eight distinct factors, and not all of them matter equally in every environment.
CVSS breaks into three metric groups: base, temporal, and environmental. The base score is what you see in the CVE announcement. It measures the vulnerability in a vacuum, assuming worst-case conditions. Temporal metrics adjust for whether exploit code exists in the wild. Environmental metrics let you recalculate the score based on your actual deployment—but almost nobody does this step.
Here's what drives a high base score: network attack vector (remotely exploitable without authentication), low complexity (easy to exploit), no privileges required, and high impact on confidentiality, integrity, or availability. A vulnerability that checks all those boxes will score above nine even if it only affects a deprecated library you don't use.
The attack vector matters most. A critical remote code execution flaw in an internet-facing service is a different animal than a privilege escalation bug that requires local shell access. If your Apache or Nginx is exposed, a network-vector CVE in the HTTP parser deserves top priority. If the CVE needs physical access to the console, it slides down the list.
Complexity tells you how hard the exploit is to pull off. Low complexity means an attacker can succeed reliably with public tools. High complexity might require race conditions, specific timing, or preconditions that rarely align in production. In support tickets I handled, the low-complexity flaws were the ones we saw exploited within days of disclosure.
Exploit availability changes everything
A CVE without public exploit code is a theoretical problem. A CVE with working proof-of-concept code on GitHub is a live threat.
Check the temporal score modifiers. "Exploit Code Maturity" ranges from unproven to high. If researchers published a working exploit, the maturity is high. If the CVE was discovered through fuzzing and nobody's demonstrated exploitation, it's unproven. That gap matters more than the base score.
I track exploit repos and security mailing lists because they tell me when a CVE moves from theory to practice. The moment a one-liner PoC hits Twitter, that CVE jumps to the front of the queue regardless of its CVSS number. Attackers script these exploits into mass-scanning tools within hours.
Another signal: are attackers already using it? Check threat intelligence feeds and your own logs. If you see scans or probes targeting the vulnerable endpoint, you're in the window. Patch it before the next wave.
Some vulnerabilities get exploited heavily for a few weeks and then fade. Others become permanent fixtures in bot toolkits. A critical CVE in a widely deployed CMS like WordPress or Joomla tends to see sustained exploitation because the target population is huge and slow to patch. A critical CVE in an obscure VoIP daemon might see a brief flurry and then nothing.
Asset exposure is your real attack surface
You don't patch based on what's vulnerable; you patch based on what's vulnerable and reachable.
Start with an inventory. What services listen on public IPs? What versions are they running? If a critical CVE affects Exim 4.96 and you're running Exim 4.97, you're clear. If you're on 4.94, you need to act—but only if that Exim instance accepts mail from the internet.
Internal-only services get a different risk tier. A critical flaw in your phpMyAdmin install sounds scary until you remember it sits behind a firewall and only accepts connections from your office IP. The CVE is real, the risk is managed. You'll patch it during the next maintenance window, not tonight.
Asset criticality compounds exposure. A vulnerable load balancer that fronts your entire infrastructure is higher priority than a vulnerable staging server that hosts test sites. If the asset going down or getting owned would cause revenue loss, data breach, or regulatory trouble, it moves up.
I use a simple matrix: public exposure (yes/no), service criticality (high/medium/low), and exploit availability (active/PoC/none). A publicly exposed, high-criticality service with active exploitation gets patched immediately. A low-criticality internal service with no known exploit gets scheduled.
What compensating controls buy you
Sometimes you can't patch right away. The vendor hasn't released a fix, or the patch breaks a critical integration, or your change window is days out. Compensating controls give you breathing room.
If the CVE requires unauthenticated access and you can enforce authentication in front of it, you've reduced the attack vector. Throwing the service behind VPN or IP allowlists works too. A remote code execution flaw in a web app becomes far less urgent when only your internal team can reach it.
Web application firewalls can block specific exploit patterns. If the CVE involves a known SQL injection payload or a predictable HTTP header manipulation, a WAF rule buys you time. This isn't a permanent fix—attackers will find variations—but it's enough to push the patch from tonight to Thursday's maintenance.
Rate limiting helps with vulnerabilities that require repeated requests or brute force. If an attacker needs to send ten thousand requests to trigger the flaw, a rate limit of one hundred per minute makes the exploit impractical.
I've also seen teams disable the vulnerable feature entirely as a temporary measure. If a critical CVE affects a specific API endpoint or plugin module you can live without, turn it off until the patch is ready. Users complain less about a missing feature than a data breach.
How to prioritize when everything is red
You're looking at twelve critical CVEs and a four-hour maintenance window. Here's the decision tree I follow.
First filter: is exploit code public and actively used? Those go in round one. Second filter: does the vulnerability affect an internet-facing service? If yes and it's in round one, patch it first. Third filter: what's the service criticality? Mission-critical services jump ahead of ancillary ones.
For the rest, I calculate a rough risk score: (CVSS base * exploit availability weight * exposure weight). Exploit availability gets a multiplier of 2x for active exploitation, 1.5x for public PoC, 1x for none. Exposure gets 2x for public internet, 1x for internal. Criticality adds a flat +2 bonus for high, +1 for medium.
That formula isn't scientific, but it forces you to consider all three dimensions instead of blindly following CVSS. A 9.8 CVE with no exploit code and internal-only exposure might score lower than a 7.5 CVE with active exploitation on a public-facing service.
If two CVEs score similarly, I patch the one in the component with the messier history first. A package that's had three critical CVEs in six months is more likely to have a fourth one next week. Get ahead of it.
When vendor severity ratings lie to you
Vendors mark everything critical because it's safer for them. If they downplay a CVE and someone gets breached, they face liability. If they overstate it and you waste time patching, that's your problem.
Read the technical details, not just the summary. A "critical remote code execution" might require the attacker to already have admin credentials, which makes it a privilege escalation bug in practice. A "critical information disclosure" might leak a single environment variable that's already public in your setup.
Pay attention to preconditions. Some CVEs require specific configurations that aren't default. If the flaw only triggers when a non-standard compile flag is set or a rare feature is enabled, check whether you're actually running that configuration before you panic.
I've also seen vendors release emergency patches for issues that affect almost nobody in production. The vulnerability is real under lab conditions, but the code path isn't reachable in normal deployments. You still patch it eventually, but it doesn't need to be tonight.
Testing patches before you deploy them
A bad patch can be worse than the vulnerability. I've watched a kernel update break NFS mounts, a PHP update kill a critical API, and an OpenSSL patch introduce connection timeouts.
Run patches in staging first if you possibly can. Hit the service with realistic traffic, run your smoke tests, check logs for errors. If staging isn't an option—some shops don't have one—at least test on a single production host that you can pull out of rotation if things go wrong.
For web applications, test with your monitoring enabled. If response times spike or error rates jump, you know immediately. For system packages, check that services restart cleanly and don't throw warnings about changed config formats.
Some patches require reboots. Kernel updates, core library changes, and occasionally glibc bumps. Schedule those for low-traffic windows and make sure your services come back up in the right order. A database that starts before the network is fully up can bind to the wrong interface.
Rollback plans matter. Know how to downgrade the package, and keep the old version cached in your local repo. If the patch breaks production at 2 a.m., you need to undo it in under five minutes, not spend twenty minutes hunting for the old .deb or .rpm.
What your logs tell you about active threats
Your access logs and firewall logs show you what attackers are already probing for. Grep for the CVE identifier or common exploit signatures.
If you see requests that match the CVE's attack pattern—specific URLs, unusual headers, malformed parameters—someone's scanning you. That bumps the CVE up in priority even if there's no confirmed exploit in the wild yet. Attackers often probe before public disclosure.
Check authentication logs too. Brute force attempts, weird user agents, and repeated 401s from unfamiliar IPs can signal reconnaissance. If a critical CVE affects your authentication mechanism and you're seeing login scans, patch it tonight.
Failed exploit attempts still show up in logs as malformed requests or errors. A spike in 500-series responses or segfaults in your service logs right after a CVE drops usually means someone's testing the exploit. They'll refine it and come back.
Patch cycles for different risk tiers
Not everything can be patched immediately, and not everything should be. You need tiers.
Tier one: internet-facing, mission-critical services with active exploits. Patch within hours. Emergency change control, out-of-band maintenance, whatever it takes. These are "drop everything" CVEs.
Tier two: internet-facing services with public PoC code, or critical internal services with active exploits. Patch within 48 hours during your next maintenance window.
Tier three: everything else with a critical CVSS score but no exploit activity. Patch within two weeks during regular maintenance.
Tier four: moderate or low scores. Patch during the next OS update cycle or monthly maintenance.
These are guidelines, not rules. A tier-three CVE can jump to tier one if exploit code appears. A tier-one CVE can drop to tier two if you deploy a compensating control that blocks the attack vector.
Document your tier assignments and review them weekly. The threat landscape shifts fast, and a CVE that was low-risk on Monday can be high-risk by Friday.
What to check first
Before you start patching, build your prioritization list. Pull down the latest CVE data, cross-reference it with your inventory, and score each one. Filter by exposure and exploit availability. Rank by risk, not just severity.
Check your logs for signs of active probing. If you see exploit attempts, move that CVE to the top. Verify that your compensating controls are in place and effective for anything you're not patching immediately.
Test patches in non-production first, then roll them out in waves. Start with your least critical public-facing service and work up to the crown jewels. Keep rollback plans ready. Monitor everything.
And remember: a CVE labeled "critical" is only critical if it's reachable, exploitable, and aimed at something that matters. Patch smart, not just fast.
FAQ
Do I always need to patch critical CVEs immediately?
No. If the vulnerability isn't exploitable in your environment or the affected service isn't exposed, you can schedule it for your regular maintenance window. Prioritize based on exploit availability and asset exposure, not just the CVSS score.
What if the patch breaks my application?
Test in staging first. If a patch causes issues, roll back and look for compensating controls—firewall rules, authentication requirements, or disabling the vulnerable feature—until a stable fix is available.
How do I know if a CVE is being actively exploited?
Check threat intelligence feeds, security mailing lists, and your own logs. Look for requests that match the exploit pattern or sudden spikes in errors. If you see probing activity, treat the CVE as high priority.
Should I trust vendor severity ratings?
Use them as a starting point, but read the technical details. Vendors often mark CVEs as critical for liability reasons. Check the preconditions and attack vector to see if it actually applies to your deployment.
How often should I reassess CVE priorities?
Weekly at minimum. Exploit availability changes fast. A CVE with no public code on Monday might have a working exploit by Wednesday. Keep your prioritization list current.
Start with your actual attack surface
You can't patch everything, and you don't need to. Focus on what's reachable, what's being exploited, and what matters to your operations. Use CVSS as one input, not the only one. Let exploit availability and asset exposure guide your decisions.
Build a repeatable triage process so you're not making gut calls at 3 a.m. when the next critical CVE drops. Your infrastructure will be more secure, and you'll sleep better.