You pull the morning vulnerability feed and see six CVEs, all rated critical, all scored above 9.0. Your patching window is six hours. Which one do you tackle first?
CVSS scores tell you how bad a flaw could be in a vacuum, but they don't account for whether attackers already have working exploit code, whether your infrastructure actually exposes the vulnerable service, or whether the vendor's patch has been tested by anyone outside the lab. I've watched sysadmins burn entire weekends patching a 9.8 that had zero public exploits while a 7.5 with a Metasploit module sat untouched on a public-facing web server.
This guide walks through five factors that matter more than the CVSS number when you need to decide what gets patched tonight and what can wait until Tuesday.
Check for active exploit code first
A vulnerability with public exploit code moves to the front of the queue. Period.
Search GitHub, Exploit-DB, and Metasploit for proof-of-concept code or modules targeting the CVE. If you find a working exploit that requires no authentication and runs remotely, that CVE jumps ahead of higher-scored flaws with no known exploits. Attackers script these exploits into automated scans within hours of publication.
I've seen mass exploitation begin within 48 hours of a Metasploit module drop. The CVE itself might have been public for weeks with minimal attacker interest, but the moment someone packages it into a point-and-click module, scanning traffic spikes across the internet.
Check the CVE publication date against the exploit publication date. A two-week-old CVE with exploit code released yesterday is more dangerous than a two-day-old CVE with no public tooling yet. The window between exploit publication and mass scanning is your narrowest margin.
Look at exploit complexity
Not all public exploits are created equal. An exploit that requires physical access or pre-authentication on the target system is lower priority than one that works unauthenticated over the network.
Read the proof-of-concept code or module description. Does it need a valid user session? Does it require the attacker to chain multiple vulnerabilities? Does it only work on specific OS versions or configurations? Complexity buys you time.
Authenticated exploits still matter if you run a shared hosting environment or WordPress multisite where untrusted users have login access. But for single-tenant VPS or dedicated servers, they drop below unauthenticated remote code execution every time.
Map which assets are actually exposed
A critical flaw in software you don't run is not critical to you.
Pull an inventory of what services are listening on public IPs, what software versions are installed, and which applications are reachable from the internet. Compare that against the CVE's affected product and version list. If the vulnerability lives in a service that's firewalled off or not installed at all, it falls off your immediate list.
For web hosting environments, this means auditing:
ss -tulnp | grep LISTEN
systemctl list-units --type=service --state=running
apache2 -v
php -v
mysql --version
On cPanel servers, check:
/scripts/check_cpanel_rpms --list-upgrades
rpm -qa | grep -E 'httpd|php|mysql|postfix|dovecot|exim'
Cross-reference the output against the CVE details. A critical OpenSSL vulnerability doesn't affect you if your stack uses LibreSSL. A PHP flaw in version 8.1 doesn't touch your PHP 8.2 instances.
Consider indirect exposure through dependencies
Shared libraries and system packages can expose you even when the primary application isn't directly vulnerable. A flaw in glibc or zlib affects dozens of services that link against those libraries.
On CentOS, RHEL, AlmaLinux, or Rocky Linux:
yum list installed | grep -E 'glibc|openssl|zlib'
ldd /usr/sbin/httpd | grep -E 'ssl|crypto|z'
On Debian or Ubuntu:
dpkg -l | grep -E 'libc6|libssl|zlib'
ldd /usr/sbin/apache2 | grep -E 'ssl|crypto|z'
If a critical CVE hits a library that's loaded by your web server, mail server, and database, you're dealing with blast radius across multiple services. That moves it up the priority list even if the primary attack vector is obscure.
Evaluate vendor patch availability and quality
A CVE with a vendor-issued patch in your distribution's official repository is faster to deploy than one requiring manual source compilation or third-party packages.
Check your package manager first:
yum check-update
apt update && apt list --upgradable
If the patch is already in the repos, you can test and deploy quickly. If the vendor hasn't released an update yet, you're looking at workarounds, manual patching, or waiting—all of which slow response time and increase risk.
Some vendors move faster than others. Red Hat and Debian typically release security updates within 24 to 72 hours of CVE publication for critical flaws. Smaller upstream projects or niche software packages can take weeks. If you're running a self-compiled application or an obscure CMS, expect delays.
What about vendor workarounds?
Vendor advisories sometimes include mitigation steps that don't require a full patch. Disabling a vulnerable feature, adding a firewall rule, or changing a configuration file can buy time until the proper update arrives.
Read the vendor's security bulletin carefully. Workarounds are often buried at the bottom of the advisory. If disabling a feature stops the exploit path and doesn't break production, implement the workaround immediately and schedule the patch for a maintenance window.
For Apache or Nginx, this might mean disabling a module:
a2dismod vulnerable_module
systemctl reload apache2
For PHP, it could mean adjusting disable_functions in php.ini:
disable_functions = exec,passthru,shell_exec,system,proc_open,popen
Workarounds aren't permanent fixes, but they compress the window attackers have to exploit a flaw before you can patch.
Weigh the operational cost of patching
Some patches restart critical services. Others require application downtime or database schema changes. The size of the disruption affects when you can deploy the patch, which in turn affects how long the vulnerability stays open.
A kernel update requires a reboot. If you're hosting production sites, that means scheduling a maintenance window, notifying customers, and coordinating with on-call staff. A userland service like Exim or Dovecot can restart in seconds with minimal disruption.
I prioritize patches that can be applied without downtime ahead of patches that require reboots, unless the reboot-required CVE has active exploits. In that case, the maintenance window happens tonight.
Test the patch in staging first
Patches occasionally break things. A security update to PHP might interact badly with a custom extension. An Apache patch might change how modules load or handle configuration directives.
If you manage multiple servers, patch a staging or development server first. Run automated tests or click through critical application paths. Check error logs:
tail -f /var/log/apache2/error.log
tail -f /var/log/php-fpm/www-error.log
tail -f /var/log/mysql/error.log
If the patch introduces new errors or breaks functionality, you need to decide whether the vulnerability risk is worse than the patch risk. For a critical CVE with active exploits, you patch anyway and fix the breakage. For a medium-severity flaw with no known exploits, you might wait for a revised patch or work with the vendor on a fix.
Factor in compensating controls already in place
Firewall rules, WAF policies, intrusion detection, and access controls reduce the effective risk of some vulnerabilities. A remote code execution flaw in a service that's only accessible from a trusted management network is less urgent than the same flaw in a public-facing web application.
Check what's already protecting the vulnerable service:
iptables -L -n -v
firewall-cmd --list-all
For Cloudflare users, check WAF rules and rate limiting. If you've already blocked requests to the vulnerable endpoint or the attack requires a specific user-agent or header pattern that Cloudflare's managed rules catch, you've bought time to test the patch properly.
Compensating controls don't eliminate the need to patch, but they let you schedule the patch during normal maintenance instead of emergency weekend work.
When compensating controls don't help
If the vulnerability is in something like sudo, polkit, or the kernel itself, network-level controls don't matter. An attacker who already has limited shell access can exploit local privilege escalation flaws regardless of your firewall.
Similarly, vulnerabilities in mail servers, DNS resolvers, or other services that must accept traffic from the internet by design can't be fully mitigated by perimeter defenses. These move to the front of the queue.
Build a scoring matrix that fits your environment
Take the five factors and assign each a weight based on your infrastructure. Here's a framework that works for most hosting environments:
- Exploit availability (weight: 40%): public exploit code, especially in Metasploit or widely used attack frameworks
- Asset exposure (weight: 25%): vulnerable service is internet-facing and not firewalled
- Vendor patch availability (weight: 15%): patch is already in official repos and tested
- Operational cost (weight: 10%): patch can be deployed without downtime or major disruption
- Compensating controls (weight: 10%): no existing mitigations are in place
Score each CVE on a 1-5 scale for each factor, multiply by the weight, and sum the results. Higher scores go to the top of the patching queue.
This isn't a perfect system, but it's better than patching in CVSS order or, worse, in the order you happened to read the CVEs.
Adjust the weights for your use case
Shared hosting environments should increase the weight on asset exposure because every public-facing service represents potential compromise of multiple customer accounts. VPS providers might weight operational cost higher because customer-initiated reboots are harder to coordinate than reboots on infrastructure you fully control.
If you manage WordPress hosting specifically, weight exploit availability heavily. The WordPress ecosystem has mature exploit tooling, and attackers scan aggressively for known plugin and theme vulnerabilities.
Common questions about patch prioritization
How long can I wait to patch a critical CVE with no public exploits?
Two weeks maximum. Exploits often surface after the initial CVE disclosure once researchers have time to reverse-engineer patches or build proof-of-concept code. Treat the CVE publication date as the start of a countdown, not a static risk level.
What if two CVEs have the same priority score?
Patch the one affecting more services first. A flaw in OpenSSL impacts your web server, mail server, and probably half a dozen other network services. A flaw in a single PHP extension affects only applications using that extension.
Should I disable a service entirely if I can't patch it immediately?
If the service isn't critical and the CVE has active exploits, yes. Stopping Apache for three hours is better than running a remotely exploitable web server. For essential services like DNS or email, lean on compensating controls and expedite the patching schedule.
Do I need to patch every CVE, even low-severity ones?
Eventually, yes, but they can wait until regular maintenance windows. Low-severity CVEs rarely see active exploitation, and the operational risk of patching on short notice often outweighs the security risk of waiting a week. Focus your emergency response energy on critical and high-severity flaws.
What to patch tonight
When ten CVEs land in your inbox, don't reach for the CVSS score first. Check for exploit code. Map which of your servers actually run the vulnerable software. Confirm whether your vendor has shipped a tested patch. Estimate how much downtime the patch will cause.
CVSS tells you how bad a vulnerability could be. These five factors tell you how bad it is in your specific environment, which is the only number that matters when you're deciding what to patch before sunrise.