Articles

Manage Vulnerabilities in Linux Systems from Detection to Patch (2026)

April 16, 2026 6 min read

Linux systems are a minefield of potential security holes, and keeping them patched is a constant battle.

Here’s how to get a grip on it, from spotting the weaknesses to slamming them shut.

Detecting Vulnerabilities

You can’t fix what you don’t know is broken. For Linux, this means regularly scanning your systems for known vulnerabilities.

1. Package Manager Auditing (The Low-Hanging Fruit)

Your first line of defense is the package manager itself. Most Linux distributions track vulnerabilities in the software they distribute.

  • Diagnosis: On Debian/Ubuntu systems, use apt list --upgradable. On RHEL/CentOS/Fedora, use dnf check-update or yum check-update. This will show you packages with available updates, which often include security fixes. For a more direct vulnerability scan against your installed packages, use apt list --installed | grep <package_name> and cross-reference with CVE databases. On RHEL-based systems, rpm -qa --last | head can show recently installed packages, which might be worth investigating.
  • Fix: sudo apt upgrade (Debian/Ubuntu) or sudo dnf upgrade / sudo yum update (RHEL/CentOS/Fedora). This pulls in the latest versions of your installed packages, which should contain the security patches.
  • Why it works: Package managers are designed to resolve dependencies. When a security patch is released for a library, the package maintainer updates the package. Upgrading the package replaces the vulnerable version with the patched one, often resolving the underlying security issue.

2. Vulnerability Scanners (Deeper Dives)

Package managers only know about vulnerabilities in their own repositories. For a more comprehensive view, you need dedicated vulnerability scanners.

  • Diagnosis:
    • OpenSCAP: This is a powerful, open-source framework. Install it with sudo apt install libopenscap8 (Debian/Ubuntu) or sudo dnf install openscap-scanner (RHEL/CentOS/Fedora). Then, run a scan: oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig-rhel7-server --results results.xml /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml. The output results.xml will detail compliance failures, many of which are security vulnerabilities.
    • Trivy: A simple, all-in-one scanner. Install it by downloading the binary from its GitHub releases page. Then run: trivy fs / to scan your filesystem for vulnerabilities in installed packages and container images.
    • Nessus/Qualys (Commercial): These offer more advanced features, reporting, and integrations but come with a cost. They typically involve installing an agent on your Linux hosts or running a central scanner that probes your network.
  • Fix: For vulnerabilities identified by scanners, the fix is usually to update the specific package. If OpenSCAP reports a CIS benchmark violation related to an old kernel, you’d follow the package manager upgrade steps above. If Trivy finds a vulnerability in openssl 1.1.1f, you’d ensure openssl is updated via your package manager. For vulnerabilities in custom applications or binaries not managed by the package manager, you might need to recompile from source or deploy a newer version.
  • Why it works: Scanners compare the versions of installed software against databases of known vulnerabilities (like CVEs). They identify specific packages and versions that are affected and often suggest the version that fixes the issue.

3. Kernel Vulnerabilities (The Core Issue)

The Linux kernel is the heart of the system. A vulnerable kernel can compromise everything.

  • Diagnosis: Tools like uname -r show your current kernel version. You can then check this against known kernel CVEs. More advanced systems use security auditing tools like auditd to monitor for suspicious kernel module loading or system calls. For a quick check of installed kernels and their relation to available updates, use dnf history list kernel or apt list --installed | grep linux-image.
  • Fix: sudo apt update && sudo apt dist-upgrade (Debian/Ubuntu) or sudo dnf upgrade kernel (RHEL/CentOS/Fedora). This will install the latest kernel provided by your distribution. You must reboot for the new kernel to take effect: sudo reboot.
  • Why it works: Kernel updates contain patches that address critical security flaws in the kernel’s code. A reboot is necessary because the kernel is loaded into memory at boot time, and a new kernel image needs to replace the old one.

4. Misconfigurations (The Human Element)

Many "vulnerabilities" aren’t flaws in the software itself, but insecure ways it’s configured.

  • Diagnosis:
    • SSH: Check /etc/ssh/sshd_config. Look for PermitRootLogin yes (should be no), PasswordAuthentication yes (should ideally be no, favoring key-based auth), and weak Protocol versions (should be Protocol 2).
    • Firewall: Use sudo ufw status (Ubuntu) or sudo firewall-cmd --list-all (CentOS/RHEL) to see open ports. Unnecessary open ports are attack vectors.
    • File Permissions: Use find / -perm -o+w -type f to find world-writable files, which can be dangerous if they’re configuration files or executables.
    • Services: Use sudo systemctl list-units --type=service --state=running to see what’s active. Is everything you expect running?
  • Fix:
    • SSH: Edit /etc/ssh/sshd_config and set PermitRootLogin no and PasswordAuthentication no. Then restart the SSH service: sudo systemctl restart sshd.
    • Firewall: sudo ufw deny <port_number> or sudo firewall-cmd --remove-port=<port_number>/tcp --permanent && sudo firewall-cmd --reload.
    • File Permissions: chmod o-w /path/to/file.
    • Services: sudo systemctl disable <service_name> and sudo systemctl stop <service_name>.
  • Why it works: Secure configurations reduce the attack surface. Disabling root login, enforcing key-based authentication, and closing unneeded ports make it significantly harder for attackers to gain unauthorized access or exploit existing vulnerabilities.

5. Container & Application Vulnerabilities (Beyond the OS)

If you’re running containers or custom applications, these have their own vulnerability landscapes.

  • Diagnosis:
    • Container Images: Use tools like Trivy (trivy image <image_name>), Clair, or Anchore to scan your Docker images for vulnerabilities in their base OS packages and application dependencies.
    • Application Dependencies: For applications built with Node.js, use npm audit. For Python, safety check -r requirements.txt. For Java, tools like OWASP Dependency-Check.
  • Fix: Rebuild your container images with updated base layers or application dependencies. For applications, update the specific vulnerable libraries (e.g., npm update <package_name>, pip install --upgrade <package_name>).
  • Why it works: Just like the OS, applications and their dependencies have bugs that get discovered. Updating them to patched versions is crucial. Container scanning ensures your immutable infrastructure isn’t shipping with known issues.

6. Outdated Software (The Unmanaged Debt)

Software that hasn’t been updated in years, especially if it’s not from your distribution’s repositories, is a major risk.

  • Diagnosis: This is often discovered during manual audits or by vulnerability scanners that can detect specific application versions running on ports (e.g., an old Apache 2.2.x). Tools like netstat -tulnp or ss -tulnp can show listening services.
  • Fix: The best fix is to migrate to a supported, patched version. If that’s not immediately possible, consider isolating the vulnerable service behind a firewall or using a Web Application Firewall (WAF) to add a layer of protection.
  • Why it works: Older software versions are less likely to have received security updates and are well-known targets for attackers. Replacing them removes the known exploit vectors.

Once you’ve patched everything, don’t be surprised if you immediately hit a "systemd service failed to start" error because a dependency was updated in a way that broke backward compatibility.

Want structured learning?

Take the full Cdk course →