How to Install Only Security Updates on RHEL 9/10 and AlmaLinux 9/10 (DNF)

By /

Updated for 2026: the original version of this post covered the yum-plugin-security era — RHEL 5, 6 and 7, all long end-of-life. On RHEL 8/9/10 and AlmaLinux 8/9/10 there is no plugin to install: errata metadata is a native part of dnf, and everything the plugin did is built in. Here’s the modern version.

Environment

  • Red Hat Enterprise Linux 8, 9 or 10, AlmaLinux 8, 9 or 10 (Rocky Linux works the same)
  • Repositories that carry errata metadata — the stock RHEL and AlmaLinux repos do (advisories are RHSA on RHEL, ALSA on AlmaLinux)

Issue

  • Can patching be limited to security updates only — no bug fixes, no enhancements?
  • How do you apply one specific fix, by CVE or by advisory, without taking everything else?
  • Can security patching be automated safely?

See what’s pending

List the security advisories waiting for your system, without installing anything:

[root@server ~]# dnf updateinfo list --security
ALSA-2026:1024 Important/Sec.  openssl-3.0.7-1.el9.x86_64
ALSA-2026:1031 Critical/Sec.   kernel-5.14.0-1.el9.x86_64
ALSA-2026:1040 Moderate/Sec.   sudo-1.9.5p2-1.el9.x86_64

Filter by severity when you only care about the serious ones, and read the full description of anything before applying it:

[root@server ~]# dnf updateinfo list --security --sec-severity=Critical
[root@server ~]# dnf updateinfo info ALSA-2026:1031

To see which security advisories are already applied on the box (handy in audits):

[root@server ~]# dnf updateinfo list --installed --security

What changes on RHEL 10 / AlmaLinux 10: DNF5 (EL10 coverage added Oct 26, 2026)

On EL10, dnf is DNF5. The important news first: everything that applies updates is unchanged — dnf upgrade --security, --advisory=, --cve= and dnf upgrade-minimal --security all work exactly as above, and dnf-automatic with upgrade_type = security is unchanged. What changed are the listing commands:

[root@server ~]# dnf5 advisory list --security
[root@server ~]# dnf5 advisory list --security --advisory-severities=Critical
[root@server ~]# dnf5 advisory info ALSA-2026:1031

In other words: dnf updateinfo becomes dnf5 advisory, and --sec-severity becomes --advisory-severities. Advisory commands take advisory IDs only — to filter by package, use --contains-pkgs=PACKAGE_NAME. If you only need to apply (not list), you can ignore all of this: the apply commands are identical on EL9 and EL10.

Two smaller EL10 notes: needs-restarting comes from the yum-utils package on RHEL 10 if the command is missing, and the minor-release pin in the Notes below takes a 10.x release (subscription-manager release --set=10.0) instead of 9.x.

Apply security updates only

[root@server ~]# dnf upgrade --security

One caveat, carried over from the original post because it’s still true: this installs the latest available version of any package that has at least one security fix — and that newest build may also contain non-security changes. If you want to land on exactly the version that fixes the advisory, and nothing newer, use the minimal form:

[root@server ~]# dnf upgrade-minimal --security

Target one fix: by CVE or by advisory

This is the workflow for “drop everything and patch CVE-XXXX today”:

[root@server ~]# dnf upgrade --cve CVE-2026-XXXX
[root@server ~]# dnf upgrade --advisory=ALSA-2026:1031

Read the advisory first with dnf updateinfo info <id> — it lists the CVE references, severity, and affected packages, which is exactly what you paste into the change ticket.

Automate it: dnf-automatic

For fleets, security-only patching is the classic job for dnf-automatic:

[root@server ~]# dnf install -y dnf-automatic

In /etc/dnf/automatic.conf, under [commands]:

upgrade_type = security
download_updates = yes
apply_updates = yes

Then enable the install timer:

[root@server ~]# systemctl enable --now dnf-automatic-install.timer

Set emit_via = email in the same file if you want a report after each run. The usual production pattern: automate security updates, keep feature updates for maintenance windows.

After patching: does it need a reboot?

Kernel, glibc and systemd fixes only fully take effect after a restart. Don’t guess — ask (this tool is in dnf-plugins-core):

[root@server ~]# dnf needs-restarting -r
Core libraries or services have been updated since boot-up.
Reboot is required to fully utilize these updates.

Notes

  • Staying on a minor release (RHEL): security-only updates don’t roll your minor version forward the way a full upgrade can, but for a hard guarantee pin it: subscription-manager release --set=9.4.
  • Mirroring locally? If your fleet patches from an internal mirror, the errata metadata comes from that mirror — make sure your reposync runs with --download-metadata, as in our local YUM/DNF repository guide, or updateinfo will have nothing to work with.
  • No metadata, no security filtering: third-party repos that don’t publish errata metadata are invisible to all of the above — dnf can’t classify what it can’t see.

Running your own server? These guides assume you have a Linux box somewhere — see our guide to choosing a VPS in 2026 for the 7 specs that actually matter before you spin one up.

Scroll to Top