Linux Security: How Updates, CVEs and Advisories Work

Last reviewed on 2026-05-13 Reference

In short

Each Linux distribution publishes its own stream of security advisories — start with the official source for the distribution you run.
A CVE is just an identifier; the severity is described separately, usually with a CVSS score.
For most desktops, enabling automatic security updates and rebooting when prompted is the right default.
For servers, decide explicitly which updates can apply automatically and which require a human in the loop.

The shape of a Linux security advisory

When a vulnerability is found in a piece of software shipped by a distribution — the kernel, a system library, a daemon, a desktop application — the affected upstream project usually coordinates a fix with distribution maintainers. The fix is then packaged for each supported release, an advisory is published, and the patched package lands in the distribution's security repository.

The advisory itself typically includes four things:

A distribution-specific identifier — for example, USN-#### for Ubuntu, DSA-#### for Debian, RHSA-#### for Red Hat. This is the canonical record on the distribution side.
One or more CVE identifiers — globally unique names that allow advisories from different distributions to be correlated.
The affected packages and versions, plus the version that contains the fix.
A short description of the issue and, where appropriate, mitigation guidance.

If you maintain Linux systems professionally, the official advisory channel for the distributions you run is the authoritative source. Aggregators and security newsletters are useful for situational awareness, but the distribution's own pages will always be the first to list a fix and the canonical place to confirm package versions.

What CVE and CVSS actually mean

CVE — Common Vulnerabilities and Exposures — is a naming scheme run by the MITRE Corporation. A CVE identifier (such as CVE-YYYY-NNNN) is just a name; it doesn't tell you how serious the issue is on its own. The same CVE can describe a problem that is trivially exploitable in one configuration and entirely irrelevant in another.

CVSS — the Common Vulnerability Scoring System — is the most widely used numeric scale for describing severity. A CVSS base score is a number between 0 and 10 derived from properties of the vulnerability itself: how exploitable it is, how much privilege is required, what the impact on confidentiality, integrity and availability would be. Distributions and the National Vulnerability Database (NVD) typically publish CVSS v3 scores alongside CVEs.

In practice, the score is a starting point rather than a verdict. A CVSS 9.8 in a service you don't run is less urgent than a CVSS 5.4 in something you expose to the internet. Always pair the score with what's actually installed and what's actually exposed on the system you maintain.

Official advisory sources for the major distributions

Ubuntu

Ubuntu Security Notices (USN) are published by Canonical's security team. See ubuntu.com/security/notices.

Debian

Debian Security Advisories (DSA) are published by the Debian Security Team. See debian.org/security.

Red Hat / RHEL / Fedora

Red Hat Security Advisories (RHSA) and Fedora Security Advisories are aggregated at access.redhat.com.

Arch Linux

Arch Linux Security Advisories (ASA) are tracked by the Arch Security Team. See security.archlinux.org.

A practical update workflow

Desktops and personal laptops

For most people running Linux on a personal machine, the right default is to let security updates apply themselves and reboot when prompted.

On Ubuntu and Debian, the unattended-upgrades package handles this and is enabled by default on recent Ubuntu installs. The default configuration installs security updates only, which is generally what you want.
On Fedora, the dnf-automatic systemd unit can be enabled to either download or apply updates on a schedule.
On Arch and other rolling-release distributions, automatic updates are unusual; the conventional pattern is a manual sudo pacman -Syu on a regular cadence (weekly, say) and reading the Arch news page before major upgrades.

For the kernel specifically, an updated package only takes effect after a reboot. Distributions that offer livepatch services (such as Canonical Livepatch for Ubuntu) can apply some kernel security fixes without one, but a full reboot is still the only way to get fully onto the new kernel.

Servers and shared infrastructure

The trade-off changes when other people depend on the system. Automatic updates are still desirable for the routine, low-risk patches, but you usually want a deliberate review for kernel updates, kernel-module changes and anything that restarts a service users are connected to.

A common pattern:

Subscribe to the security advisory channel for your distribution.
Apply security-only updates automatically on a regular schedule.
For kernel updates, schedule a maintenance window and apply them by hand.
Keep an eye on whether services restarted cleanly after an update — needrestart on Debian/Ubuntu and dnf needs-restarting on Fedora can both tell you which processes are still running an older binary.

Common system-hardening building blocks

Beyond keeping packages patched, the major Linux distributions ship a number of system-level hardening features that are worth knowing about. None of them are a silver bullet on their own; together they reduce the impact of a compromise.

Firewall. A host firewall such as ufw on Ubuntu, firewalld on Fedora and Red Hat, or iptables/nftables directly. The point is to make sure only the services you intend to expose are reachable.
Mandatory access control. SELinux is enabled by default on the Red Hat family; AppArmor is used by Debian, Ubuntu and openSUSE. Both confine processes to a narrower set of actions than file permissions alone would allow.
Sandboxing. Flatpak applications run inside per-app sandboxes; some distributions also ship bubblewrap or Firejail for ad-hoc sandboxing of arbitrary commands.
Secure boot and disk encryption. Most distributions support both. Disk encryption is worth turning on for laptops; secure boot becomes relevant when you also have a custom kernel or out-of-tree modules.
Logging. journalctl is the entry point on any systemd-based system; the systemd basics page covers the everyday commands. Reviewing what services log at boot occasionally is a cheap way to notice misbehaving software early.
File permissions. The foundation underneath all of the above is still the classic Linux permission model. The file permissions reference covers what each bit means and where ACLs fit in.
Certificate monitoring. If you operate services with TLS certificates, a small daily check catches expiries before they cause outages. The SSL certificate expiry script is a starting point.

What this site does not publish

This page intentionally does not list specific currently-open CVEs, version numbers or release dates. Those details age very quickly, and a stale list is worse than no list at all because it gives a false impression of completeness. The official advisory channels above are always the right source for "what is happening today".