Unpatched servers remain one of the easiest targets for attackers. The moment a vulnerability is disclosed, automated scanners begin probing the internet for exposed systems. Your window to patch before exploitation shrinks every day. This guide covers what to prioritize, how to patch safely, and how to build a sustainable update routine that keeps attackers out.
Why Patching Matters More Than Ever
Every piece of software on your server represents a potential attack surface. Operating systems, web servers, PHP runtimes, control panels, SSL libraries, database engines—each can harbor vulnerabilities that allow remote code execution, privilege escalation, or data theft.
Attackers don't need sophisticated zero-days. They scan for known, publicly documented vulnerabilities in outdated software. If your server runs last year's kernel or an old version of OpenSSL, you're already on their list.
The challenge is not whether to patch, but what to patch first and how to do it without breaking production services.
What to Patch Right Now
Operating System Kernel and Core Utilities
Your kernel is the foundation. Kernel vulnerabilities can grant attackers root access, escape container isolation, or bypass security modules. Always apply security updates to the kernel, systemd, glibc, and core utilities like sudo and openssh.
For Debian and Ubuntu:
sudo apt update
sudo apt list --upgradable
sudo apt upgrade
For RHEL, AlmaLinux, and Rocky Linux:
sudo dnf check-update
sudo dnf upgrade --security
Kernel updates require a reboot. Plan maintenance windows accordingly, but don't postpone security patches indefinitely.
Web Server Software
Apache, Nginx, LiteSpeed, and OpenLiteSpeed all publish security advisories. Subscribe to their mailing lists or RSS feeds. Vulnerabilities in HTTP parsing, request handling, or module code can allow attackers to execute arbitrary code or bypass authentication.
Check your current version:
apache2 -v
nginx -v
Update via your package manager. Restart the service after updating:
sudo systemctl restart apache2
sudo systemctl restart nginx
PHP and Application Runtimes
PHP is everywhere in hosting environments. Each version reaches end-of-life on a predictable schedule, after which security patches stop. Running unsupported PHP versions leaves you exposed to publicly known exploits.
Check your PHP version:
php -v
If you're still on PHP 7.x, you're running an unsupported version. Migrate to PHP 8.1 or newer. Use your package manager or a repository like Remi or Ondrej's PPA for current versions.
The same principle applies to Python, Node.js, Ruby, and other runtimes. Pin to actively supported versions and update regularly.
OpenSSL and Cryptographic Libraries
SSL/TLS vulnerabilities can expose session keys, decrypt traffic, or allow man-in-the-middle attacks. OpenSSL and its alternatives (LibreSSL, BoringSSL) release patches for critical flaws regularly.
Check your OpenSSL version:
openssl version
Update via your distribution's package manager. After updating, restart services that link against OpenSSL—typically your web server and mail server.
Database Servers
MySQL, MariaDB, and PostgreSQL all publish security advisories. Vulnerabilities in SQL parsing, replication, or authentication can allow attackers to dump databases, escalate privileges, or crash the service.
Check your database version:
mysql --version
psql --version
Update via your package manager. Test the update on a staging environment first if possible, especially for major version jumps.
Control Panels: cPanel, Plesk, DirectAdmin
Control panels run with elevated privileges and expose large attack surfaces. They handle authentication, file management, DNS, email, and database administration. A vulnerability in the panel itself can compromise every account on the server.
cPanel, Plesk, and DirectAdmin all release security updates through their built-in update systems. Enable automatic updates or check for updates manually:
For cPanel:
/scripts/upcp
For Plesk:
plesk installer update
For DirectAdmin:
cd /usr/local/directadmin
./directadmin u
Subscribe to the vendor's security mailing list to receive advance notice of critical patches.
DNS Software
BIND, PowerDNS, and Unbound all handle recursive queries or authoritative responses. DNS vulnerabilities can allow cache poisoning, denial of service, or remote code execution.
Check your DNS server version:
named -v
pdns_server --version
Update via your package manager and restart the service.
Mail Server Components
Postfix, Exim, Dovecot, and SpamAssassin all have security histories. Mail servers are high-value targets because they handle authentication, sensitive data, and often run with elevated privileges.
Check your mail server versions:
postconf mail_version
exim -bV
dovecot --version
Update via your package manager. Test mail flow after updates to catch configuration regressions.
How to Patch Safely
Take Backups Before Major Updates
Patching can introduce regressions or compatibility issues. Before applying major updates—especially kernel, database, or control panel updates—take a snapshot or backup.
For VPS environments, use your provider's snapshot feature. For bare metal, use tools like rsnapshot, Borg, or Restic.
Test Updates in Staging First
If you manage multiple servers or have a staging environment, apply updates there first. Run your monitoring checks, test application functionality, and verify service availability before rolling updates to production.
Understand Your Update Policy
Different distributions have different update philosophies. Debian and Ubuntu LTS apply security backports without changing software versions. RHEL and derivatives follow a similar approach. Rolling distributions like Arch apply upstream updates directly.
Know whether your distribution includes feature changes in security updates or only patches vulnerabilities. This affects testing requirements.
Restart Services After Patching
Updating a package does not restart the running process. After patching OpenSSL, Apache, Nginx, PHP-FPM, or database servers, restart the affected services:
sudo systemctl restart apache2
sudo systemctl restart php8.2-fpm
sudo systemctl restart mysql
Use lsof or checkrestart (from debian-goodies) to identify processes still using old library versions:
sudo checkrestart
Reboot After Kernel Updates
Kernel updates do not take effect until reboot. Some environments support live patching (KernelCare, Ubuntu Livepatch), but most require a reboot.
Schedule reboots during maintenance windows. Use tools like needrestart to check if a reboot is required:
sudo needrestart -r l
Automating Security Updates
Unattended Upgrades on Debian and Ubuntu
Debian and Ubuntu include unattended-upgrades, which applies security updates automatically. Install and configure it:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
Edit /etc/apt/apt.conf.d/50unattended-upgrades to control which updates are applied. By default, it applies only security updates.
Enable automatic reboots if needed:
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
DNF Automatic on RHEL and Derivatives
RHEL, AlmaLinux, and Rocky Linux use dnf-automatic:
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
Edit /etc/dnf/automatic.conf to control behavior. Set apply_updates = yes to apply updates automatically, or apply_updates = no to only download and notify.
Control Panel Update Automation
cPanel supports automatic daily updates. Enable it in WHM under Server Configuration → Update Preferences. Choose between Stable, Release, and Edge tiers based on your tolerance for change.
Plesk supports automatic updates through Tools & Settings → Updates. Enable automatic installation of security updates.
DirectAdmin requires manual updates or cron-based automation. Add a cron job to run the update script:
0 3 * * * /usr/local/directadmin/directadmin u >/dev/null 2>&1
Monitor Update Logs
Automatic updates can fail or introduce issues. Monitor logs regularly:
- Debian/Ubuntu:
/var/log/unattended-upgrades/ - RHEL/AlmaLinux:
/var/log/dnf.log - cPanel:
/var/cpanel/updatelogs/
Set up alerts for failed updates or service restarts.
Beyond Patching: Reducing Attack Surface
Patching is necessary but not sufficient. Combine it with other hardening measures:
Disable Unused Services
Every running service is a potential entry point. Disable services you don't need:
sudo systemctl disable --now <service-name>
Configure Firewalls
Use firewalld, ufw, or iptables to restrict inbound connections. Allow only necessary ports: SSH (22), HTTP (80), HTTPS (443), and mail ports if needed.
For ufw:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
Harden SSH Access
Disable password authentication and use key-based authentication. Disable root login. Change the default SSH port if you face constant brute-force attempts.
Edit /etc/ssh/sshd_config:
PermitRootLogin no
PasswordAuthentication no
Port 2222
Restart SSH:
sudo systemctl restart sshd
Use Fail2Ban or CSF
Fail2Ban monitors logs and blocks IP addresses after repeated failed login attempts. ConfigServer Security & Firewall (CSF) provides similar functionality with a cPanel-friendly interface.
Install Fail2Ban:
sudo apt install fail2ban
sudo systemctl enable --now fail2ban
Configure jails in /etc/fail2ban/jail.local.
Common Patching Mistakes to Avoid
Postponing Kernel Reboots Indefinitely
Kernel updates remain inactive until reboot. Postponing reboots for months leaves you vulnerable to known kernel exploits. Schedule regular maintenance windows.
Ignoring End-of-Life Software
Running unsupported PHP, Python, or database versions means no security patches exist. Attackers know this and target outdated versions. Migrate to supported versions before EOL.
Applying Updates Without Testing
Automatic updates can break applications, especially when language runtimes or libraries change behavior. Test updates on non-production systems first, or use phased rollouts.
Forgetting to Restart Services
Updating packages without restarting services leaves old, vulnerable code running in memory. Always restart affected services after patching.
Overlooking Third-Party Software
Package managers don't update manually installed software, WordPress plugins, or custom scripts. Audit third-party software regularly and update it separately.
Building a Sustainable Patching Routine
Weekly Security Checks
Run a weekly check for available updates:
sudo apt update && sudo apt list --upgradable
Review the list and apply security updates immediately.
Monthly Maintenance Windows
Schedule monthly maintenance windows for kernel updates, major version upgrades, and other changes that require reboots or service restarts.
Subscribe to Security Mailing Lists
Subscribe to security advisories for your distribution, control panel, and key software components. This gives you advance notice of critical vulnerabilities.
- Debian: debian-security-announce
- Ubuntu: ubuntu-security-announce
- RHEL: rhsa-announce
- cPanel: cPanel Security Advisories
Use Vulnerability Scanners
Tools like Lynis, OpenVAS, or Nessus can identify outdated software, weak configurations, and missing patches. Run scans regularly and prioritize findings.
Document Your Patching Process
Document which updates require testing, which can be applied automatically, and who is responsible for approving changes. Clear processes reduce delays and missed patches.
Conclusion
Patching is not a one-time task—it's an ongoing discipline. Attackers exploit known vulnerabilities faster than most teams can patch them. The key is prioritization: update the kernel, web server, runtime, and control panel first, then work down the stack. Automate what you can, test what you must, and build a routine that makes patching predictable rather than reactive. The servers you patch today are the ones that won't appear in tomorrow's breach reports.