Attackers don’t wait. A critical CVE published today might be exploited in the wild within hours. I’ve seen it happen — a client lost their entire WordPress site to a vulnerability that was disclosed and patched three days earlier. They hadn’t updated because “it was just a web app.”
This isn’t a theoretical risk. It’s the reality of running internet-facing servers in 2026. The window between disclosure and exploitation keeps shrinking. Your patching process needs to shrink too.
Here’s what you actually need to do — a concrete, repeatable plan for patching critical CVEs before attackers strike.
Why Critical CVEs Demand Immediate Action
Not all vulnerabilities are created equal. A critical CVE means the CVSS score sits at 9.0–10.0. That translates to remote code execution, authentication bypass, or total compromise — with minimal attacker effort.
In support tickets I handled, the usual culprit was a full disk or outdated Apache version. But the most panicked calls always started the same way: “We got hacked through a CVE we didn’t patch.”
The Exploitation Timeline
Two years ago (2024), the median time to exploit a critical CVE after public disclosure was under 14 days. By early 2026, that number has dropped to under 72 hours for some high-profile bugs. Automated exploit kits scrape every new CVE and weaponize it within hours.
You cannot rely on “we’ll patch it next maintenance window.” If you run production services, your patching cadence for critical CVEs must be measured in hours — not days or weeks.
Step 1: Know What You’re Running
You can’t patch what you don’t know you have. The first step is inventory.
Every server, every service, every package version — you need a live, searchable list.
Tools to Build Your Inventory
- For Linux servers:
dpkg -l(Debian/Ubuntu) orrpm -qa(RHEL/CentOS) produce installed package lists. Run them regularly. - For Docker containers:
docker imagesplusdocker pswith specific image tags. Usedocker scanor Trivy for vulnerability scanning. - For web services: Service detection via Nmap or your configuration management tool. Know which PHP version, which nginx build, which OpenSSL release.
Automate this. A cron job that dumps the package list to a central log can save you hours during an incident.
# Example cron job for Debian/Ubuntu (daily at 2am)
0 2 * * * dpkg -l > /var/log/package-inventory/$(date +\%F).txt 2>&1
Service Discovery
Don’t forget services running on non-standard ports. I’ve found forgotten Redis instances on port 6379, MongoDB on 27017, and even an old Elasticsearch cluster with no authentication. Each one is a potential CVE vector.
Use ss -tlnp or netstat -tulpn to list listening services. Cross-reference with your expected service list daily.
Step 2: Monitor CVE Feeds and Vendor Advisories
Waiting for your software vendor to email you about a critical patch is too slow. You need real-time feeds.
Where to Watch
- National Vulnerability Database (NVD): https://nvd.nist.gov/ — filter by CVSS 9.0+ and recent month.
- CVE.org: Direct CVE records with references to vendor patches.
- Your vendor’s security advisories: cPanel, Plesk, Apache, Nginx, OpenSSL, PHP — all have mailing lists or RSS feeds.
- Exploit-DB: Proof-of-concept code often appears here soon after disclosure.
RSS to the Rescue
Set up an RSS reader (Newsboat, Miniflux, or even a Slack bot) that consumes feeds from the NVD and your vendors. When a critical CVE drops for software you run, you get a ping in minutes — not days.
I prefer a simple script that polls the NVD API hourly and matches against my software inventory. It’s about 20 lines of Python. You can build one in an afternoon.
# Pseudocode
import requests
from my_inventory import get_packages
feed = requests.get('https://services.nvd.nist.gov/rest/json/cves/2.0?cvssScore=9.0-10.0')
for cve in feed.json()['vulnerabilities']:
if any(pkg in cve['descriptions'] for pkg in get_packages()):
alert_me(cve)
Step 3: Prioritize Patches by Risk, Not Just Score
CVSS score is a starting point. But a 9.8 CVE on an internal-only tool that’s unrelated to your stack is less urgent than an 8.5 CVE on your public-facing nginx.
What to Consider
- Exploitability: Does the CVE have a public exploit? Check Exploit-DB, Metasploit, or GitHub.
- Attack vector: Network vs. local. Network-exploitable, no authentication? That’s your top priority.
- Impact: Data loss? Remote code execution? Denial of service? Prioritize RCE and auth bypass.
- Internet exposure: If the service listens on a public IP, patch it now. If it’s isolated on a private VLAN with no internet access, you can schedule the patch next maintenance window.
The Eisenhower Matrix for CVEs
Urgent + Important -> Patch immediately (within hours). Not urgent + Important -> Schedule within 48 hours. Urgent + Not important -> Automate or vendor-supplied workaround. Not urgent + Not important -> Ignore until next cycle.
Most critical CVEs fall into the top-left box. Act fast.
Step 4: Patch with Care — But Patch Fast
You need speed, but you also need stability. The classic tension: “Should I apply this kernel security update immediately or risk breaking production?”
Practical Patching Workflow
-
Workaround first: Some CVEs can be mitigated without a full patch. For example, disabling a vulnerable feature, limiting access via firewall rules, or adding authentication. Apply a workaround while you test the actual patch.
-
Test in staging: If you have a staging environment, deploy the patch there first. Run your test suite for 15–30 minutes. If nothing breaks, push to production.
-
Deploy via automation: Ansible, Salt, Puppet, or even a well-written script. Manual patching of 50 servers is error-prone and slow.
# Ansible playbook snippet
- name: Update all packages to latest
apt:
upgrade: dist
update_cache: yes
register: apt_res
- name: Reboot if kernel updated
reboot:
reboot_timeout: 300
when: apt_res is changed and 'linux-image' in apt_res.stdout
- Validate: After patching, verify the service is running. Check the version (
nginx -v,openssl version). Run a quick vulnerability scan withnmap --script vulnor a commercial scanner.
What About Reboots?
Kernel updates typically require a reboot. That’s fine — schedule a rolling reboot across your cluster. If you’re running a single server, you’ll have downtime. Accept it. A few minutes of downtime is far better than a weeks-long compromise.
Step 5: Automate Wherever Possible
Manual patching doesn’t scale. Automation is your safety net.
Automated Patching Tools
- Unattended-upgrades (Debian/Ubuntu): Configure it to automatically install security updates. Yes, even if it breaks something — you can roll back.
- yum-cron / dnf-automatic (RHEL/CentOS): Same concept.
- OS-level auto-patch services: Tools like Canonical Livepatch or Red Hat’s Kpatch can apply kernel patches without reboot.
I run unattended-upgrades on all my personal servers. In production, you might want a review gate — but for critical CVEs, auto-apply is safer than waiting.
Continuous Vulnerability Scanning
Use a tool like OpenVAS, Nessus, or Wazuh to scan your infrastructure daily. Set alerts for critical CVEs. When a scan detects a vulnerable package, you should know immediately.
Integrate scanning into your CI/CD pipeline. If a Docker image contains a critical CVE, block it from deploying.
# GitLab CI job
vulnerability-check:
script:
- trivy image --severity CRITICAL $CI_REGISTRY_IMAGE
only:
- tags
So What if the Port is Open but SSH Still Refuses?
That question is a bit sideways, but it illustrates a common problem: you think you’ve patched, but the old vulnerable version is still running. Every engineer has been there.
After applying a patch, verify the running service, not just the package database. Use:
# Check the actual binary in memory
dpkg -S /usr/sbin/sshd | grep -E '^libssl'
# Or for a running process
sshd -V
Sometimes you need to restart the daemon or reboot the machine. Don’t skip that step.
What to check first
Start today. Not tomorrow.
- Inventory your servers and services — know what you’re running.
- Subscribe to CVE feeds — NVD RSS, vendor advisories.
- Set up automated patching for security updates on non-production servers first, then production.
- Run a vulnerability scan against your public-facing IPs. Fix anything critical immediately.
- Document your patching policy — write down who decides what gets patched and how fast. Communicate it to the team.
The days of “patch Tuesday” are over. Attackers don’t wait for a schedule. Neither should you.
Patched servers are happy servers. Patch those CVEs now.