You run the updates, reboot the server, and mark the ticket resolved. A month later the scanner still flags the same CVE. Or worse — you patch the package but leave the old vulnerable binary running in memory because you forgot to restart the service.
I've watched teams waste hours on CVE remediation that never actually closes the hole. The package manager says it's fixed, the compliance dashboard turns green, but the attack surface stays exactly the same. Here are the nine mistakes that cause it and the fixes that actually work.
Mistake 1: Patching the package but not restarting the service
This is the single most common gap. You install the updated OpenSSH package, but sshd keeps running the old code from memory. The CVE scanner checks the installed package version and reports success, while the vulnerable daemon keeps accepting connections on port 22.
Linux does not automatically reload running binaries when you update a package. Services keep the old executable mapped in memory until you explicitly restart them.
The fix: after every security update that touches a daemon or library, identify which services need a restart. For most package-based vulnerabilities, check what's using the old library:
sudo lsof | grep 'DEL.*lib'
That command shows processes still using deleted library files — they're running old code. Restart each one. For system libraries like glibc or OpenSSL that dozens of processes link against, a reboot is often cleaner than hunting down every affected daemon.
Better still, script the restart into your patch routine. When you update openssh-server, always bounce sshd. When you patch Apache modules, always systemctl restart apache2.
Mistake 2: Ignoring kernel CVEs because "we can't reboot production"
Kernel patches sit in /boot doing nothing until you reboot. I've seen three-year-old kernel CVEs on production boxes because the team treated every reboot as an event requiring a change window and executive approval.
The kernel is your security foundation. An unpatched privilege escalation or container escape in the kernel makes every other control irrelevant.
The fix: if your infrastructure can't tolerate a reboot, use live kernel patching. Red Hat offers kpatch, Ubuntu has Livepatch, and SUSE provides kGraft. These technologies apply kernel security fixes to the running kernel without downtime.
Set up Livepatch on Ubuntu:
sudo ua attach YOUR_TOKEN
sudo ua enable livepatch
For RHEL:
sudo yum install kpatch kpatch-runtime
sudo systemctl enable kpatch
Not every CVE has a live patch available, and eventually you still need a full reboot to apply non-security updates and clear out accumulated state. Schedule quarterly maintenance windows at minimum. Live patching is a bridge, not a replacement for reboots.
Mistake 3: Trusting the package manager's version string without verifying
Distribution vendors backport security fixes to older package versions and keep the original version number. You see openssl-1.0.2k installed, the CVE database says 1.0.2k is vulnerable, so you assume you're exposed. Meanwhile the distro already patched that CVE and simply kept the 1.0.2k label.
This causes two problems: false positives that waste investigation time, and false confidence when you do install the "fixed" package but don't verify the actual patch landed.
The fix: check the distro's security advisories, not the upstream CVE alone. Red Hat, Debian, and Ubuntu all publish detailed security trackers showing which CVEs are patched in which package builds.
For RHEL/CentOS:
yum updateinfo list security
yum updateinfo info CVE-XXXX-XXXXX
For Debian/Ubuntu:
apt-cache policy <package-name>
Then cross-reference the installed build against the distro's CVE tracker. Ubuntu's tracker is at https://ubuntu.com/security/cves, Debian's at https://security-tracker.debian.org/tracker/.
Better vulnerability scanners like Nessus and Qualys understand distro backports and won't flag false positives. If you're using a generic CVE scanner that only checks version strings, expect noise.
Mistake 4: Skipping dependencies and leaving the supply chain vulnerable
You patch the main application but ignore the libraries it links against. The web app gets updated, but the ancient libcurl or libxml2 it depends on stays at a vulnerable version because "nothing else complained."
Shared libraries are transitive dependencies in the OS layer. A single vulnerable .so file can affect dozens of binaries.
The fix: after patching an application, audit its library dependencies:
ldd /usr/sbin/some-daemon
That shows every shared library the binary loads. Cross-check each one against your patch list. If any library has open CVEs, update it even if the package manager didn't flag it as a dependency of the package you just patched.
For Python/Node.js/Ruby apps, use the language-specific tools:
pip list --outdated
npm audit
bundle audit
These tools check application-layer dependencies. Run them separately from your OS package updates because they live in different namespaces.
Mistake 5: Applying patches without reading the changelog or advisory
You see "critical" and immediately push the update to production. Turns out the patch changes a config file format, breaks an API, or requires a database migration. The service crashes, you roll back, and now you're running the vulnerable version again with no clear path forward.
I've responded to outages caused by security patches more times than I can count. The CVE was real, the patch was necessary, but the deployment was reckless.
The fix: read the vendor advisory and the package changelog before applying any critical update. Look for breaking changes, deprecated options, and required follow-up steps.
yum info <package-name>
apt-get changelog <package-name>
Test the patch in a staging environment that mirrors production config. Run your health checks and integration tests. If the patch requires config changes, script them so you can apply the update and config adjustment atomically.
Speed matters with critical CVEs, but breaking production helps no one. A two-hour delay to test the patch properly is better than a four-hour outage.
So what if the patch isn't available yet?
Vendors don't always ship patches immediately. Sometimes the CVE drops on Friday and the vendor's security team won't have a build ready until Monday. You can't ignore a critical remote code execution flaw for 72 hours.
Mistake 6: Waiting passively for the vendor patch instead of mitigating
The vendor will release a patch when they release a patch. Meanwhile, your attack surface is wide open. Most CVEs include enough detail for an attacker to write an exploit before the patch arrives.
The fix: apply defense-in-depth controls while you wait. If the CVE affects a network service, restrict access with firewall rules or IP allow-lists. If it's a web application vulnerability, deploy a WAF rule or ModSecurity signature. If it's a privilege escalation, tighten permissions and disable the affected feature if possible.
For Apache vulnerabilities, you can often block exploit attempts with mod_security rules targeting the specific attack pattern described in the CVE. For kernel issues, enable SELinux or AppArmor policies that limit what the vulnerable code path can do even if exploited.
Document every mitigation so you remember to remove it after the real patch is applied. Temporary fixes have a way of becoming permanent technical debt.
Mistake 7: Patching only internet-facing systems and ignoring internal servers
The reasoning goes: "The database server sits behind the firewall, no one can reach it, so we'll patch it during the next maintenance window." Then an attacker compromises a web server, pivots to the internal network, and exploits the unpatched database.
Lateral movement is standard in modern attacks. The perimeter is not the security boundary anymore.
The fix: treat internal systems with the same urgency as public-facing ones for critical CVEs. Patch internal databases, application servers, and admin tools on the same schedule as your web frontends.
If you must stagger patches due to maintenance windows, prioritize based on data sensitivity and privilege level, not network exposure. A vulnerable internal Active Directory server is higher risk than a vulnerable public blog.
Mistake 8: Forgetting to patch container images and VM templates
You patch every running server but leave the master image untouched. Next time someone spins up a new container or provisions a VM from the template, the vulnerability reappears.
I've watched teams patch the same CVE six times because their CI/CD pipeline kept deploying old images.
The fix: update your base images and templates immediately after patching production. For Docker:
docker pull ubuntu:22.04
docker build --no-cache -t myapp:latest .
docker push myapp:latest
Rebuild from the updated base image even if your app code didn't change. Tag the new build clearly so your deployment pipeline picks it up.
For VM templates, boot the template, apply all patches, clear logs and temp files, then re-export it. Update your provisioning scripts to reference the new template version.
Automate this. Every time your patch management tool closes a CVE ticket, trigger a rebuild of the relevant images.
Mistake 9: Skipping verification after patching
You applied the update, restarted the service, and moved on. Three weeks later a compliance scan flags the same CVE. Either the patch didn't actually install, or it installed but didn't fix the issue due to a config conflict or partial update.
The fix: verify every patch with the same scanner or tool that originally detected the vulnerability. If you used Nessus to find it, run Nessus again after patching. If you used yum updateinfo, check that the CVE no longer appears in the output.
For application-layer CVEs, test the specific exploit or attack vector if you can safely reproduce it. If the CVE describes a particular HTTP request that triggers code execution, send that request to your patched server and confirm it's blocked or handled safely.
Keep a log of what you patched, when you patched it, and what verification you ran. When auditors or compliance teams ask for proof, you'll have a paper trail.
What to check first
Most CVE remediation failures come down to process, not technical skill. You need a checklist that forces you to think past "install update, mark complete."
Before you close the ticket, confirm: - The package version matches the fixed version in the vendor advisory - All affected services and daemons have been restarted or the system rebooted - Dependency libraries are also patched if the CVE affects shared code - Base images, templates, and CI/CD pipelines pull the updated version - A vulnerability scan no longer flags the issue - Any temporary mitigations applied before the patch are removed
Patch once, verify twice. That's the difference between remediation theater and actual security.
Questions
Do I need to reboot after every security update?
Not always. User-space packages like Apache or MySQL only need a service restart. Kernel updates, core libraries like glibc, and some low-level system components require a full reboot. Check the package changelog and use lsof | grep DEL to see what's still using old code.
How do I know if my distro backported a CVE fix?
Check the distro's security tracker. RHEL, Ubuntu, and Debian all maintain CVE databases showing which fixes are included in which package builds. Generic version-based scanners won't catch backports; use a scanner that understands your distro's patching model.
What if the patch breaks my application?
Test in staging first. If the patch is genuinely incompatible, apply mitigating controls (firewall rules, WAF policies, permission restrictions) while you work with the vendor or rewrite the conflicting code. Never run a known critical vulnerability in production without defense-in-depth controls.
Should I patch Windows servers the same way?
The principles are identical: read the advisory, test the patch, restart affected services, update base images, and verify. Windows Update handles most restarts automatically, but you still need to check that legacy services or third-party software picked up the updated libraries.