Unpatched servers are the easiest target attackers find. I've cleaned up after dozens of breaches that started with a vulnerability that had a patch available for weeks or months. The fix was sitting there, waiting.
Most admins know they should patch. But knowing and doing are different things, and the gap between them is where compromises happen. Here are the nine mistakes I see repeatedly, along with the right way to handle each one.
Mistake 1: Waiting for "the right time" to patch
You tell yourself you'll patch during the next maintenance window. That window is three weeks away. The vulnerability is being actively exploited now.
Delay is the single biggest patching mistake. Security updates exist because someone found a hole that attackers can use. Every day you wait is a day your server sits exposed.
The fix: Treat security patches differently from feature updates. Critical security fixes go out within 24-48 hours of release, sometimes faster if exploits are public. Schedule a brief maintenance window or apply patches during low-traffic periods.
For production systems, test the patch on staging first, but compress that timeline. A two-hour staging test is better than a two-week delay. If you don't have staging, snapshot your VPS before patching so you can roll back if something breaks.
# Before patching, take a snapshot
lvcreate -L 20G -s -n root-snapshot /dev/vg0/root
# Or on cloud platforms
aws ec2 create-snapshot --volume-id vol-xxxxx --description "Pre-patch snapshot"
Mistake 2: Only patching what breaks
Some admins only update packages when they're troubleshooting an unrelated issue. Apache won't start? Update Apache. Everything else? Leave it alone if it's working.
This approach guarantees you're running vulnerable software. Attackers don't care if your ancient OpenSSL version "works fine" for your application.
The fix: Run full system updates on a regular cadence. Weekly for internet-facing servers, monthly minimum for internal systems. Use your distribution's update mechanism to catch everything.
# RHEL/CentOS/AlmaLinux
sudo yum update -y
# Debian/Ubuntu
sudo apt update && sudo apt upgrade -y
# Check what needs a reboot after kernel updates
needs-restarting -r # RHEL-based
test -f /var/run/reboot-required && echo "Reboot needed" # Debian-based
Yes, this sometimes means rebooting. Plan for it.
Mistake 3: Ignoring kernel updates because they require a reboot
Kernel updates pile up in your update queue because applying them means downtime. So you patch everything else and skip the kernel for months.
Kernel vulnerabilities are particularly dangerous since they can lead to privilege escalation or container escapes. An attacker who gains limited access can exploit an unpatched kernel to take over the entire system.
The fix: Schedule monthly kernel updates at minimum, more often if critical vulnerabilities appear. Use a brief maintenance window during off-peak hours.
If you absolutely cannot reboot, look into live kernel patching:
# RHEL/CentOS with kpatch
sudo yum install kpatch kpatch-runtime
sudo systemctl enable kpatch
# Ubuntu with Canonical Livepatch (requires Ubuntu Advantage)
sudo snap install canonical-livepatch
sudo canonical-livepatch enable [token]
Livepatch isn't a permanent solution. You still need actual reboots eventually, but it buys time for critical systems.
Mistake 4: Running automated updates without monitoring
You enable automatic updates and forget about them. Months later, you discover they've been failing silently because the disk filled up or a repository changed.
Automatic updates are better than nothing, but only if they actually run. In support tickets I handled, the usual culprit was a full disk, broken repository mirrors, or dependency conflicts that stopped the update process.
The fix: Automate the updates, but also automate the monitoring. Set up alerts that fire if updates fail or if the last successful update was more than a week ago.
# Enable unattended upgrades on Debian/Ubuntu
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# Configure email notifications
# Edit /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Mail "[email protected]";
Unattended-Upgrade::MailReport "on-change";
Check your logs weekly to verify updates ran:
tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
Mistake 5: Patching the OS but forgetting application dependencies
Your system packages are current, but you're running PHP, Node.js, Python, or Ruby applications with dependencies that never get updated. Those language-specific packages have vulnerabilities too.
Composer, npm, pip, and gem packages don't update themselves when you run yum update. You have to handle them separately.
The fix: Track application dependencies as part of your patch routine. Each language has its own update commands:
# PHP (Composer)
composer update --with-dependencies
# Node.js (npm)
npm audit fix
npm update
# Python (pip)
pip list --outdated
pip install --upgrade [package-name]
# Ruby (bundler)
bundle update
For production applications, test dependency updates in staging first since they're more likely to introduce breaking changes than OS packages.
Mistake 6: No rollback plan when patches break things
You apply updates, something breaks, and now you're scrambling to figure out what changed and how to undo it. No snapshots, no backups taken right before the update, no clear path back.
Patches do occasionally break things. A new kernel might have driver issues, or an updated library might change behavior your application depends on.
The fix: Always have a rollback path before you patch. The simplest approach is filesystem snapshots if you're using LVM or a cloud platform that supports them.
# Create LVM snapshot before major updates
lvcreate -L 10G -s -n pre-update-snapshot /dev/vg0/root
# If things break, roll back
lvconvert --merge /dev/vg0/pre-update-snapshot
reboot
For cloud VPS, use your provider's snapshot feature. Take one before updates, keep it for a week, then delete it if everything's stable.
Document your rollback procedure so you're not looking it up during an outage.
Mistake 7: Patching without testing on production-like systems
You apply patches directly to production because you don't have a staging environment, or your staging environment is so different from production that testing there is meaningless.
Then the patch causes an issue that only appears under production load or with production data, and you're fixing it live while users are impacted.
The fix: Build a staging environment that actually mirrors production. It doesn't need to be the same size, but it should run the same OS version, same application stack, and similar configuration.
For budget-constrained setups, spin up a temporary staging VPS only when you need to test updates:
# Clone your production server to test updates
rsync -avz --exclude=/proc --exclude=/sys --exclude=/dev \
production-server:/ /mnt/staging-test/
Test the update there, verify your application still works, then apply to production with more confidence.
Mistake 8: Patching without reading the changelog
You see updates available, you install them, done. You didn't look at what changed or whether the update includes configuration changes you need to make.
Sometimes updates require manual steps. A web server might change its default configuration format, or a database might need you to run a migration script. If you don't read the notes, you miss those steps.
The fix: Check release notes for significant updates, especially for major services like Apache, Nginx, MySQL, PostgreSQL, or PHP. You don't need to read every line, but scan for breaking changes and required actions.
# See what's about to update before you apply it
yum update --changelog # RHEL-based
apt list --upgradable # Debian-based
For critical services, check the upstream project's release notes or security advisories before applying major version updates.
Mistake 9: No inventory of what needs patching
You patch the servers you remember. You forget about that staging box you spun up six months ago, the old server you meant to decommission, or the jump host that only gets used occasionally.
Attackers find those forgotten systems. They're often less monitored and become the entry point for a breach.
The fix: Maintain an inventory of every server you run. Use a spreadsheet if nothing else, but better yet, use configuration management or an asset tracking system.
# Quick inventory check: last successful update on each system
for host in $(cat servers.txt); do
echo -n "$host: "
ssh $host "stat -c %y /var/log/yum.log | cut -d' ' -f1" 2>/dev/null || echo "unreachable"
done
Schedule quarterly reviews where you list every system, verify it's still needed, and either patch it or decommission it.
If you're managing more than a handful of servers, invest in configuration management tools like Ansible, Puppet, or Salt that can inventory and patch systems centrally.
What counts as a critical patch?
You can't treat every update as urgent or you'll burn out. So which patches require immediate action?
Prioritize anything marked as a security update by your distribution. These have been vetted as important. Within security updates, focus first on:
- Remotely exploitable vulnerabilities
- Services exposed to the internet (web servers, SSH, mail servers)
- Privilege escalation issues in the kernel or core utilities
- Actively exploited vulnerabilities (check security mailing lists)
For everything else, your regular update schedule is fine.
FAQ
How often should I patch production servers? Security updates within 24-48 hours. Full system updates weekly for internet-facing servers, monthly for internal systems. Adjust based on your risk tolerance and uptime requirements.
Can I skip patches if my firewall blocks direct access? No. Attackers reach systems through application vulnerabilities, compromised user accounts, or lateral movement from other compromised systems. Firewalls help but aren't a substitute for patching.
What if a patch breaks my application? Roll back using your snapshot or backup, identify what broke, and either fix your application to work with the update or find a workaround. Don't leave the system unpatched indefinitely.
Should I patch databases and web servers during business hours? Not if you can avoid it. Schedule updates during maintenance windows or low-traffic periods. For high-availability setups, use rolling updates to patch without downtime.
Do containers need patching too? Yes. Both the container host OS and the base images you build containers from need regular updates. Rebuild and redeploy containers when base images are patched.
Where most patch strategies fail
The pattern I see across breached systems is the same: patches were available, the admin intended to apply them, but something always came up. An urgent ticket, a project deadline, a fear that updates might break something.
That gap between intention and execution is what attackers count on. Close it by making patching a scheduled, tested, monitored routine rather than something you do when you have time. You won't have time until after the breach, and by then it's too late.
Start with automated updates plus monitoring for non-critical systems. For production systems, schedule weekly patch windows and actually use them. Test first when you can, but don't let perfect be the enemy of patched.