Waking up to 237 CVE alerts is not a security posture—it's noise. Your scanner flags everything from kernel bugs that need local access to PHP issues in libraries you don't even use. Meanwhile, the two vulnerabilities that actually matter get lost in the flood.
I've triaged thousands of vulnerability reports across shared hosting, VPS, and dedicated servers. The pattern is always the same: most alerts are irrelevant to your environment, a dozen need eventual patching, and two or three deserve immediate action. The trick is sorting them fast.
The four-step triage funnel
This process takes 200+ alerts and narrows them to a short list you can action today. Each step filters out another category of non-threats.
Step one: filter by exploitability
Start with CVSS score, but don't stop there. A 9.8 rating means nothing if there's no public exploit and the attack vector requires physical access to the server.
Check these three things:
- Does a working exploit exist? Search Exploit-DB, GitHub, and Metasploit modules. If attackers have code, the CVE moves to your short list.
- What's the attack vector? Network exploitable beats local every time. Remote unauthenticated is the worst case.
- Is it being exploited in the wild? CISA's Known Exploited Vulnerabilities catalog is your friend here. If it's on that list, patch it yesterday.
In practice, about 80% of alerts drop out at this stage. That kernel vulnerability with a CVSS of 7.2? Needs local shell access and hasn't been exploited anywhere. It stays on the eventual-patch list but doesn't wake you up at 2 AM.
Step two: map to actual assets
Your scanner found a critical OpenSSL bug. Great—are you running the affected version on anything exposed?
Inventory your stack:
# Check installed package versions
rpm -qa | grep openssl
dpkg -l | grep openssl
# Find what's listening on public interfaces
ss -tulpn | grep LISTEN
netstat -tulpn | grep LISTEN
# Check web server and PHP versions
httpd -v
nginx -v
php -v
I've seen teams scramble to patch a PostgreSQL CVE when they only run MySQL. Don't be that team. If the vulnerable component isn't in your environment, archive the alert and move on.
For cPanel servers, check EasyApache profiles and installed PHP versions:
/scripts/ea_current_to_profile --show
ea-php74 -v
ea-php81 -v
Vulnerabilities in PHP versions you've already disabled don't count.
Step three: assess exposure and blast radius
Now you have exploitable CVEs affecting software you actually run. Next question: how exposed is it?
Rank by surface area:
- Public-facing services (web servers, mail servers, DNS) get top priority
- Backend services with authentication (databases, Redis, internal APIs) are mid-tier unless authentication is broken
- Internal-only tools on private networks drop to the bottom unless you have compliance requirements
A remote code execution bug in Apache matters more than the same bug in a monitoring agent that only talks to localhost.
Blast radius matters too. On shared hosting, one compromised account can pivot to others if permissions are weak. On a single-tenant VPS, the blast radius is smaller but you still care about data exfiltration and using your server as a malware host.
Vendor response time: the wildcard
Some vendors patch fast. Others take weeks or never release a fix at all.
Check the CVE publication date and the vendor's security advisory. If a patch exists, your job is straightforward: test and deploy. If the vendor went silent three months ago, you have decisions to make.
Options when no patch exists:
- Mitigation via configuration—disable the vulnerable feature, restrict access with firewall rules, or add a reverse proxy filter
- Backported patches—RHEL and Ubuntu sometimes backport fixes to older package versions without bumping the version number your scanner sees
- Replace the component—switch libraries, pick a different web server, or containerize the application to isolate it
For WordPress sites, plugin vulnerabilities often fall into the no-vendor-response category. The plugin author abandoned it two years ago and 50,000 sites still run it. Deactivate and find an alternative.
Testing before you patch
Never apply updates directly to production without testing. I don't care how critical the CVE is.
Spin up a staging environment that mirrors production:
# Snapshot before patching
lvcreate -L 10G -s -n staging-snap /dev/vg0/root
# Or for cPanel servers
/scripts/pkgacct username
Apply the patch, run your smoke tests, and watch logs for an hour. Then schedule the production update during a maintenance window.
The exception: if you're already compromised or under active attack, patch production now and test later. You can't test your way out of a breach in progress.
Prioritization worksheet
Here's how I score vulnerabilities to build the final patch queue.
| Factor | High (3 pts) | Medium (2 pts) | Low (1 pt) |
|---|---|---|---|
| Exploitability | Public exploit + active exploitation | Public exploit, no active use | Theoretical only |
| Exposure | Public network service | Authenticated service | Internal/localhost only |
| Impact | RCE or full system compromise | Data disclosure or DoS | Information leak |
| Vendor response | Patch available now | Patch coming in < 7 days | No patch timeline |
Add up the score. Anything scoring 10+ goes on today's list. 7-9 is this week. Below 7 gets scheduled for the next maintenance cycle.
So what about false positives?
Scanners lie. A lot.
They see version strings and assume the worst. Your RHEL 7 server reports OpenSSL 1.0.2k and the scanner screams about vulnerabilities patched in 1.0.2l, but Red Hat backported those fixes without changing the version number.
Cross-reference scanner results with your distribution's security advisories:
- RHEL/CentOS: Red Hat CVE Database
- Ubuntu: Ubuntu Security Notices
- Debian: Debian Security Tracker
If your vendor says the CVE is resolved in the package you're running, close the alert and add it to your scanner's exception list with a note.
Automate the noise
You can't manually triage 200 CVEs every week. Automate the easy stuff.
Script the first two filter steps:
#!/bin/bash
# Example: filter CVEs by installed packages
VULN_LIST="$1" # CSV from scanner
while IFS=, read -r cve package version; do
if rpm -q "$package" &>/dev/null; then
installed=$(rpm -q --queryformat '%{VERSION}-%{RELEASE}' "$package")
echo "$cve,$package,$version,$installed,INSTALLED"
else
echo "$cve,$package,$version,N/A,NOT_INSTALLED"
fi
done < "$VULN_LIST"
Feed this into a ticket system or spreadsheet. You're left reviewing the "INSTALLED" rows only.
For public exploit checks, APIs from the National Vulnerability Database and CISA's KEV feed can be polled daily.
When to patch vs. when to mitigate
Patching isn't always the right move immediately.
If the patch is untested, breaks compatibility, or requires downtime you can't afford right now, buy time with mitigations:
- Firewall rules: block the vulnerable port from untrusted networks
- WAF rules: signature-based blocks for web application CVEs
- Access control: restrict who can reach the service while you test the patch
- Disable features: turn off the vulnerable module if it's not critical
Document every mitigation and set a reminder to circle back with the real patch. Mitigations are temporary bandages, not fixes.
The compliance angle
PCI DSS and other frameworks give you 30 days to patch critical vulnerabilities. That deadline starts when the vendor releases a fix, not when your scanner detects it.
If you're in scope, track vendor advisory dates and keep patch receipts:
# Log patch activity
date >> /var/log/patch-history.log
yum update -y openssl >> /var/log/patch-history.log 2>&1
rpm -qa | grep openssl >> /var/log/patch-history.log
Auditors want proof you patched within the window.
What to check first
When you open your vulnerability report, scan for these red flags first: any CVE with a public exploit, anything on CISA's KEV list, and remote code execution bugs in public-facing services. Those three categories will hand you your immediate action list. Everything else gets sorted through the four-step funnel.
The goal isn't zero vulnerabilities—it's zero exploited vulnerabilities. Triage keeps you focused on the gaps attackers actually use instead of chasing scanner phantoms.