Every week brings another CVE announcement. Most hosting environments run fifty or more services across web servers, mail systems, databases, and control panels. Patching everything immediately is impossible.
The real question is which vulnerabilities deserve your attention right now and which can wait until next week's maintenance window. I've watched support teams waste hours patching low-risk CVEs while critical remote code execution bugs sat unpatched on public-facing assets. A simple triage framework fixes that.
The four-factor model
Four factors predict whether a CVE will cause you actual problems: the CVSS score tells you theoretical severity, exploit availability tells you if attackers can act on it, asset exposure tells you what's at risk, and vendor patch timelines tell you when a fix is realistic. Evaluate all four before you decide.
Most teams look at CVSS and stop. That's a mistake.
Factor 1: CVSS score (but read the vector)
CVSS scores range from zero to ten. Anything above nine is critical, seven to nine is high, four to seven is medium. Those bands matter, but the score alone doesn't tell you enough.
The attack vector matters more. A CVSS 9.8 that requires local access on a server with two known SSH keys is less urgent than a CVSS 7.5 remote unauthenticated bug on your Apache installation serving 200 client sites. Check the vector string.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
That string unpacks to: network attack vector (AV:N), low complexity (AC:L), no privileges required (PR:N), no user interaction (UI:N). That combination is the worst case. An attacker can hit it from anywhere, exploitation is straightforward, and no authentication is needed.
Compare that to:
CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:N
Local attack vector, high complexity, high privileges required, user interaction needed. Even if the base score is seven, this CVE needs local root access and a user to click something. That's not your emergency.
In support tickets I've handled, the panic usually comes from headlines, not from reading the vector. A "critical WordPress vulnerability" that requires an authenticated editor account is not critical if you vet your users and enforce strong passwords.
Factor 2: exploit availability
A CVE with public exploit code is a different animal. Check ExploitDB, GitHub, Metasploit modules, and security mailing lists. If working exploit code exists, your window is measured in hours, not days.
Three stages matter:
- Proof of concept exists: someone published code demonstrating the vulnerability. Attackers can weaponize this quickly.
- Metasploit or nuclei template exists: exploitation is now one command. Script kiddies can run it.
- Active scanning detected: security vendors or honeypots report widespread exploitation attempts. You're already being probed.
When exploit code drops for a network-accessible service, assume attackers will scan the entire IPv4 space within 24 hours. I've seen mass exploitation start within six hours of a Metasploit module release.
If no exploit exists and the CVE requires complex conditions, you have time to plan. Patch it, but you can schedule it with your normal maintenance cycle.
Factor 3: asset exposure and blast radius
A critical CVE in a service that's firewalled off or only accessible from your internal network is not your first priority. Focus on internet-facing assets first.
Rank your assets by exposure:
- Public-facing with direct Internet access: web servers, mail servers, DNS, cPanel/WHM, anything on a public IP without a firewall rule restricting it.
- Public-facing behind a reverse proxy or CDN: still exposed, but filtered traffic reduces some attack surface.
- Internal services with VPN/jump-host access: SSH on non-standard ports with key auth, databases bound to localhost, Redis with requirepass and bind to 127.0.0.1.
- Completely internal: services on private VLANs with no Internet route.
Then consider blast radius. A vulnerability in a shared hosting web server affects hundreds of customer sites. That's higher priority than a bug in a monitoring tool used by three people.
Check what's actually listening:
ss -tulnp
Then verify what's reachable from outside:
nmap -sV -p- your-public-ip
If port 3306 shows up in that nmap output, your MySQL is exposed to the Internet. Any MySQL CVE just became top priority regardless of CVSS score.
Factor 4: vendor patch timeline
A CVE is only actionable if a patch or workaround exists. Check the vendor's security advisory before you plan anything.
Four scenarios:
- Patch available: update now or schedule it based on the other three factors.
- Patch in beta/testing: assess risk tolerance. Applying an untested patch to production can cause outages.
- Workaround available: configuration changes, firewall rules, or disabling a feature can mitigate the risk until a real patch ships.
- No fix yet (zero-day or abandoned software): you need compensating controls, and you may need to replace the software entirely.
For cPanel, check their security advisories page. For Linux distribution packages, subscribe to the security mailing list for your distro (RHSA for RHEL/CentOS/AlmaLinux, USN for Ubuntu, DSA for Debian). Most enterprise distributions backport security fixes to older versions, so the patched version number often doesn't match upstream.
Don't assume the latest version on GitHub is what you need. Your package manager's patched version may have a lower version number but include the fix.
yum updateinfo list security
apt list --upgradable
Those commands show which updates are security-related.
Putting it together: a priority matrix
Combine the four factors into a decision matrix. I use a simple high/medium/low rating for each factor, then prioritize based on the pattern.
| CVSS | Exploit | Exposure | Patch | Priority |
|---|---|---|---|---|
| High | Yes | Public | Available | Immediate |
| High | Yes | Internal | Available | High |
| High | No | Public | Available | High |
| Medium | Yes | Public | Available | High |
| High | Yes | Public | Workaround | High |
| High | No | Internal | Available | Medium |
| Medium | No | Public | Available | Medium |
| Low | * | * | Available | Low |
Immediate means patch within hours, ideally during business hours with monitoring. High means patch within 24-48 hours during your next maintenance window. Medium means include it in your weekly or monthly patching cycle. Low means patch it eventually, but it's not driving your schedule.
If a CVE hits immediate priority, notify your team, check backups, and prepare a rollback plan before you apply anything. I've seen patching break more production systems than the vulnerabilities themselves when it's rushed without testing.
What about EPSS?
The Exploit Prediction Scoring System gives you a probability that a CVE will be exploited in the wild within 30 days. It's useful as a tiebreaker when you have two similar CVEs and limited time.
An EPSS score above 10% means security researchers think this CVE is likely to see exploitation soon. Above 50% means it's very likely. Below 1% means it's probably not on attackers' radar yet.
EPSS doesn't replace the four-factor model. Use it as supplemental data, especially for medium-severity CVEs where you're deciding what to batch together in a maintenance window.
Handling the backlog
You'll always have a backlog of medium and low-priority CVEs. That's normal. Address them in monthly patching cycles, and track them so you know what's outstanding.
Keep a spreadsheet or ticket system with:
- CVE identifier
- Affected service and version
- CVSS score and vector
- Exposure (public/internal)
- Date added to backlog
- Planned remediation date
Review the backlog every month. If a low-priority CVE has been sitting there for six months and nothing has happened, you're fine. If new information emerges (exploit code published, active exploitation detected), re-triage it.
Some CVEs never get exploited. Some get exploited years later. You can't predict everything, but you can make sure the realistic threats are covered.
Automate the busy work
Manual CVE triage doesn't scale past a handful of servers. Automate vulnerability scanning and patch management where possible.
For RedHat-based systems, yum-cron or dnf-automatic can install security updates automatically:
yum install yum-cron
systemctl enable --now yum-cron
Edit /etc/yum/yum-cron.conf and set apply_updates = yes to auto-apply security patches. For production, I prefer apply_updates = no with email notifications so you review before patching.
Ubuntu's unattended-upgrades does the same:
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades
Configure it to install security updates only, and reboot automatically if needed (or notify you to reboot manually).
For vulnerability scanning, OpenVAS and Nessus are popular. They'll scan your systems, report CVEs, and often give you a prioritized list. The scan results still need human judgment—scanners report everything and don't understand your specific environment—but they save hours of manual checking.
When patching isn't an option
Sometimes you can't patch. Legacy software with no updates, custom applications with no vendor, or critical systems where downtime is unacceptable. You need compensating controls.
Options:
- Firewall rules: block access to vulnerable services from untrusted networks. If the CVE requires network access and you can restrict it to known IPs, that's effective mitigation.
- Web application firewall: ModSecurity rules or Cloudflare WAF can block exploit attempts for web application CVEs.
- Disable the feature: if the vulnerability is in a module or feature you don't use, disable it. Many Apache and PHP CVEs affect optional modules.
- Reverse proxy filtering: place nginx or HAProxy in front of a vulnerable service and filter malicious requests.
- Intrusion detection: won't stop an attack, but it'll alert you when exploitation is attempted so you can respond.
Document every compensating control so you remember it's in place when you do eventually patch or replace the software.
What to check first
When a new CVE drops, don't rush. Read the vendor advisory, check the CVSS vector, and search for exploit code. Then verify whether your systems are exposed and whether a patch exists.
Most CVEs don't require emergency action. The ones that do have a clear pattern: high CVSS with network vector, public exploit code, and your service is directly reachable from the Internet. Patch those immediately. Everything else gets triaged into your normal maintenance schedule.
Track what you patch and what you postpone. That record becomes your evidence that you made rational risk decisions, not that you ignored security.