RHEL Patch Management: Security Updates, CVEs and DNF Patching

RHEL security fixes are normally delivered as signed package updates associated with Red Hat Security Advisories (RHSA). You can use DNF to identify which advisories and CVEs apply to a host, inspect their severity, install only security-related updates, and verify which fixes are installed.

Findings may come from Red Hat advisories, vulnerability-management platforms such as Nessus or Qualys, or internal security tooling. The remediation workflow on RHEL still converges on advisory metadata and DNF:

Normal package patching
→ DNF installs updated RPM packages
→ services or processes may need restart
→ kernel updates normally require reboot

Kernel live patching
→ kpatch applies selected fixes to a running kernel
→ separate workflow with limited CVE coverage
→ normal DNF patching and reboot planning still apply

Generic DNF security-update commands may also apply to compatible RPM-based distributions when their repositories provide advisory metadata. RHSA identifiers and subscription content are specific to RHEL.

Quick Reference: RHEL Security Patching with DNF

The needs-restarting command is provided by the yum-utils package on RHEL 10.

1. Understand RHSA, CVE and RHEL Security Errata

Red Hat publishes errata notices that tie package updates to bugs, enhancements, or security issues. For patch management, three advisory types matter most:

A CVE identifies a publicly tracked vulnerability. On RHEL the usual remediation chain looks like this:

CVE
   ↓
affects package or product
   ↓
Red Hat evaluates impact
   ↓
RHSA identifies the security fix
   ↓
signed RPM updates are delivered through DNF repositories

One RHSA can address multiple CVEs. One CVE can affect multiple packages or products. Use RHSA and CVE metadata from DNF or the Red Hat CVE database, not upstream version numbers alone, to decide whether a host is affected.

2. Check Available Security Updates

Start with a summary of what DNF sees in enabled repositories:

dnf updateinfo summary

Updates Information Summary: available
    18 Security notice(s)
         9 Important Security notice(s)
         9 Moderate Security notice(s)
    10 Bugfix notice(s)

The summary counts security notices by severity. It answers whether security work is waiting without listing every package yet.

List the available security advisories and the package NEVRAs they would update:

dnf updateinfo list updates security

RHSA-2026:54576 Important/Sec. dracut-107-9.el10_2.x86_64
RHSA-2026:54576 Important/Sec. dracut-config-rescue-107-9.el10_2.x86_64
RHSA-2026:54576 Important/Sec. dracut-network-107-9.el10_2.x86_64
RHSA-2026:54576 Important/Sec. dracut-squash-107-9.el10_2.x86_64
RHSA-2026:50747 Important/Sec. freerdp-libs-2:3.10.3-12.el10_2.7.x86_64
RHSA-2026:54486 Important/Sec. freerdp-libs-2:3.10.3-12.el10_2.8.x86_64
RHSA-2026:54512 Moderate/Sec.  gnome-remote-desktop-49.3-4.el10_2.x86_64
RHSA-2026:53451 Moderate/Sec.  gstreamer1-plugins-good-1.26.7-2.el10_2.3.x86_64
RHSA-2026:53845 Important/Sec. iscsi-initiator-utils-6.2.1.11-1.git4b3e853.el10_2.2.x86_64
RHSA-2026:54343 Important/Sec. kernel-6.12.0-211.47.1.el10_2.x86_64

Each line shows the RHSA ID, severity, and affected package NEVRA. Kernel and multi-package advisories appear multiple times because several RPMs share the same RHSA.

To see what is already remediated on the host:

dnf updateinfo list security --installed

RHSA-2026:19141 Important/Sec. PackageKit-1.2.8-8.el10_2.x86_64
RHSA-2026:19141 Important/Sec. PackageKit-command-not-found-1.2.8-8.el10_2.x86_64
RHSA-2026:19141 Important/Sec. PackageKit-glib-1.2.8-8.el10_2.x86_64
RHSA-2026:36782 Moderate/Sec.  aardvark-dns-2:1.17.1-1.el10_2.x86_64
RHSA-2026:42739 Important/Sec. acl-2.4.0-1.el10_2.x86_64

That output answers a different question from the available list: which security advisories are already installed on this system.

3. Inspect an RHSA or CVE Before Patching

Before changing a production host, inspect the advisory that DNF or a scanner report references. On the lab host, RHSA-2026:54576 addresses a dracut issue:

dnf updateinfo info RHSA-2026:54576

===============================================================================
  Important: dracut security update
===============================================================================
  Update ID: RHSA-2026:54576
       Type: security
    Updated: 2026-08-13 18:31:51
       Bugs: 2500889 - CVE-2026-15816 dracut: dracut: root code execution via unescaped error message written to sourced emergency hook script in die()
       CVEs: CVE-2026-15816
Description: The dracut packages contain an event-driven initial RAM file system (initramfs) generator infrastructure based on the udev device manager.
           :
           : Security Fix(es):
           :
           : * dracut: dracut: root code execution via unescaped error message written to sourced emergency hook script in die() (CVE-2026-15816)
   Severity: Important

Review severity, CVEs, affected packages, and the description before you schedule downtime or service restarts. Confirm the package is actually installed with rpm -q; an advisory for software you do not run may not require action on that host.

When a scanner names a CVE instead of an RHSA, look it up the same way:

dnf updateinfo info --cve=CVE-2026-15816

The CVE lookup returns the same RHSA metadata DNF uses to build the update transaction.

Do not decide vulnerability status by comparing upstream version numbers alone. RHEL frequently backports security fixes while keeping a distribution-specific package version and release. A scanner finding such as this:

Finding:
CVE-2026-15816
Affected package: dracut
Severity: Important

RHEL workflow:
CVE → RHSA → DNF preview → package update → validation

should be validated against RHSA metadata and the installed NEVRA, not against an upstream fixed version string.

Check the installed package version:

rpm -q dracut

dracut-107-8.el10_2.x86_64

If DNF still lists dracut-107-9.el10_2 under RHSA-2026:54576, the fix is available but not yet installed.

4. Preview Security Updates

Preview the full security transaction before you install anything:

sudo dnf upgrade --security --assumeno

Upgrading:
 dracut               x86_64 107-9.el10_2  rhel-10-for-x86_64-baseos-rpms 487 k
 freerdp-libs         x86_64 2:3.10.3-12.el10_2.8  rhel-10-for-x86_64-appstream-rpms  1.3 M
 kernel-tools         x86_64 6.12.0-211.47.1.el10_2  rhel-10-for-x86_64-baseos-rpms  2.2 M
 libarchive           x86_64 3.7.7-10.el10_2  rhel-10-for-x86_64-baseos-rpms 420 k
Installing dependencies:
 kernel-core          x86_64 6.12.0-211.47.1.el10_2  rhel-10-for-x86_64-baseos-rpms  19 M
 kernel-modules       x86_64 6.12.0-211.47.1.el10_2  rhel-10-for-x86_64-baseos-rpms  42 M

Transaction Summary
=================================================================================================================
Install   8 Packages
Upgrade  27 Packages

Total download size: 269 M
Operation aborted.

--assumeno resolves dependencies and prints the transaction summary, then exits without making changes. Review package names, kernel updates, download size, and dependency installs before you approve the real run.

sudo dnf upgrade without --security applies the broader available update set, including bugfix and enhancement advisories. sudo dnf upgrade --security limits the transaction to packages tied to applicable security advisories.

5. Apply Security Updates with DNF

Apply all security updates

When the preview looks correct, apply the security-only transaction:

sudo dnf upgrade --security

DNF resolves the signed RPM set from enabled RHEL repositories. You do not need to download individual RPMs per CVE; advisory metadata drives package selection.

Apply the minimum security fix

Use upgrade-minimal when you want the lowest package versions that still resolve applicable security advisories, rather than moving every affected package to its newest available build:

sudo dnf upgrade-minimal --security

On the lab host both --security and --security with upgrade-minimal resolved the same transaction size because several advisories shared dependencies such as the kernel stack. The distinction still matters on hosts where a full security upgrade would jump packages farther than required.

Filter Critical or Important updates

Use severity-aware summary commands when you want to prioritize higher-rated work first:

dnf updateinfo summary --secseverity=Important

Updates Information Summary: available
    9 Security notice(s)
        9 Important Security notice(s)

A practical prioritization model is Critical, then Important, then Moderate, then Low. Severity alone does not replace environment-specific risk assessment. A Moderate issue in an internet-facing or heavily exposed service may deserve faster remediation than a higher-rated issue in an installed component that is unused or not exposed in that environment.

You can also list advisories at a given severity:

dnf updateinfo list updates security --secseverity=Important

Review the severity column in the output before you schedule maintenance. DNF also accepts --secseverity on upgrade --security when you want to target a severity band during installation.

6. Apply a Specific RHSA or CVE

Targeted remediation is useful when a scanner names one advisory, when you are working through a controlled change window, or when staging validation is limited to a defined patch set.

Inspect the advisory first:

dnf updateinfo info RHSA-2026:54576

Preview only that advisory:

sudo dnf upgrade --advisory=RHSA-2026:54576 --assumeno

Upgrading:
 dracut               x86_64 107-9.el10_2  rhel-10-for-x86_64-baseos-rpms 487 k
 dracut-config-rescue x86_64 107-9.el10_2  rhel-10-for-x86_64-baseos-rpms  19 k
 dracut-network       x86_64 107-9.el10_2  rhel-10-for-x86_64-baseos-rpms  67 k
 dracut-squash        x86_64 107-9.el10_2  rhel-10-for-x86_64-baseos-rpms  21 k

Transaction Summary
================================================================================
Upgrade  4 Packages

Total download size: 595 k
Operation aborted.

Apply the advisory when the preview matches expectations:

sudo dnf upgrade --advisory=RHSA-2026:54576

To remediate from a CVE identifier instead, preview and apply with --cve:

sudo dnf upgrade --cve=CVE-2026-15816 --assumeno

Upgrading:
 dracut               x86_64 107-9.el10_2  rhel-10-for-x86_64-baseos-rpms 487 k
 dracut-config-rescue x86_64 107-9.el10_2  rhel-10-for-x86_64-baseos-rpms  19 k
 dracut-network       x86_64 107-9.el10_2  rhel-10-for-x86_64-baseos-rpms  67 k
 dracut-squash        x86_64 107-9.el10_2  rhel-10-for-x86_64-baseos-rpms  21 k

Transaction Summary
================================================================================
Upgrade  4 Packages

Total download size: 595 k
Operation aborted.

A CVE can map to one or more packages. DNF uses repository advisory metadata to resolve the RPM set. Do not call routine dnf upgrade --security remediation a "hotfix" unless Red Hat documents the fix that way.

7. Verify Security Patches After Installation

Do not stop at DNF reporting Complete!. Confirm the package NEVRA changed:

rpm -q PackageKit

PackageKit-1.2.8-8.el10_2.x86_64

Check whether the advisory appears in the installed security list:

dnf updateinfo list security --installed | grep RHSA-2026:19141

RHSA-2026:19141 Important/Sec. PackageKit-1.2.8-8.el10_2.x86_64
RHSA-2026:19141 Important/Sec. PackageKit-glib-1.2.8-8.el10_2.x86_64

Re-open the advisory details if you need the CVE list or description after installation. Include the installed state because DNF treats available and installed advisories separately:

dnf updateinfo info --installed RHSA-2026:19141

After applying the update, record its transaction ID:

dnf history

Look for the transaction containing the upgrade --security, --advisory, or --cve command you used. You can then inspect that transaction with:

dnf history info ID

Replace ID with the transaction number from the history list.

Validate the workload itself when a service was patched. For example, confirm a daemon is still active after its package update:

systemctl is-active NetworkManager

active

If patching was triggered by a vulnerability scanner, rerun the relevant scan after remediation. The goal is identify, patch, verify package and advisory status, verify the service, then rescan.

8. Check Whether a Restart or Reboot Is Required

Installing a new kernel RPM does not switch the running kernel until you reboot into it. Compare the active kernel with the newest installed build:

uname -r

6.12.0-211.42.1.el10_2.x86_64

Then list the installed kernel-core versions:

rpm -q kernel-core

kernel-core-6.12.0-211.42.1.el10_2.x86_64
kernel-core-6.12.0-211.47.1.el10_2.x86_64

If a newer kernel is installed than the version reported by uname -r, the security update is on disk but the system has not booted into that kernel yet. Plan a reboot window before you treat the kernel fix as active.

The needs-restarting utility reports whether core libraries or services changed since the last boot:

needs-restarting -r

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

Exit code 0 means needs-restarting did not detect changes that require a reboot. Exit code 1 means it detected changes for which a reboot is recommended. User-space packages can still require a service restart even when a reboot is not required; validate critical applications after patching.

For kernel cleanup after reboot, see remove old kernels on RHEL.

9. RHEL Patch Management Workflow for Production

A practical production workflow looks like this:

Identify → Assess → Preview → Test → Patch → Restart/reboot → Validate → Record

Identify what is waiting with a summary first:

dnf updateinfo summary

Then list the individual security advisories:

dnf updateinfo list updates security

Assess each candidate advisory for severity, CVEs, affected packages, workload exposure, and reboot impact.

Preview the transaction:

sudo dnf upgrade --security --assumeno

Test in development or staging, then roll to production subsets when your environment supports staged deployment.

Patch with either the full security set:

sudo dnf upgrade --security

Or apply one targeted advisory when the change window is limited:

sudo dnf upgrade --advisory=RHSA-2026:54576

Restart or reboot services and the kernel as required, then validate with rpm -q, dnf updateinfo list security --installed, and application checks.

Record the RHSA or CVE, package versions, DNF history ID, host name, date, and validation result for audit and rollback planning.

Do not assume every DNF transaction can be cleanly reversed in production. Test updates before wide rollout and keep your normal recovery mechanism. For history rollback options, see YUM/DNF history rollback. For snapshot-based recovery planning, see LVM snapshot backup and restore.

Optional: automate security updates with dnf-automatic

RHEL can automatically download and install security updates with dnf-automatic. Install it with:

sudo dnf install dnf-automatic

In /etc/dnf/automatic.conf, set:

[commands]
upgrade_type = security

Then enable the installation timer:

sudo systemctl enable --now dnf-automatic-install.timer

Confirm the timer is active:

systemctl status dnf-automatic-install.timer

● dnf-automatic-install.timer - dnf-automatic-install timer
     Loaded: loaded (/usr/lib/systemd/system/dnf-automatic-install.timer; enabled; preset: disabled)
     Active: active (waiting) since Sat 2026-08-15 15:09:11 IST; 82ms ago
    Trigger: Sun 2026-08-16 06:09:24 IST; 15h left
   Triggers: ● dnf-automatic-install.service

Automatic installation is useful where unattended security patching fits the change-management policy. Production environments that require staged testing or explicit approvals may instead automate only detection or download and keep installation controlled.

10. Offline Patching, Hotfixes and kpatch

Offline RHEL systems

Offline environments should consume controlled, trusted RHEL content through an appropriate repository workflow. Common approaches include Satellite content management, synchronized internal mirrors, and deliberately prepared offline repositories.

Do not treat a hand-built directory of individually downloaded RPMs as the standard production patch model. Dependency completeness, advisory coverage, package signing, and long-term maintenance are difficult to guarantee that way. For a repository-based offline workflow, see create a local offline DNF repository.

Ensure the host is registered or pointed at approved content, refresh metadata, then use the same dnf updateinfo and dnf upgrade --security commands described above against the offline mirror.

What Red Hat means by a hotfix

hotfix is not the normal name for every RHEL security package update. Routine remediation is delivered through an RHSA, signed RPM updates, and DNF repositories. Call dnf upgrade --security a security update, security patch, or advisory remediation.

A Red Hat hotfix is a more exceptional, temporary fix scenario. The URL for this article retains hotfix for historical search equity, but the workflow centers on RHSA and CVE-driven DNF patching.

Kernel live patching with kpatch

RHEL provides kpatch for selected kernel security and bug fixes while the kernel continues running. Live patching does not cover every CVE, does not replace normal DNF patching, and depends on kernel and RHEL support entitlements. RHEL 10 live-patch support begins with RHEL 10.2.

Treat kpatch as a downtime-reduction option for eligible fixes, not as a substitute for installing updated kernel packages and planning reboots. Full kpatch installation and configuration belongs in a dedicated guide.

Summary

RHEL patch management starts with DNF advisory metadata, not manual RPM collection. dnf updateinfo summary and dnf updateinfo list updates security show what is waiting, while dnf updateinfo list security --installed shows what is already remediated on the host.

Before you change a system, inspect RHSA and CVE details, preview the transaction with --assumeno, and choose between dnf upgrade --security, dnf upgrade-minimal --security, or targeted --advisory and --cve remediation. Verify installed NEVRAs, advisory status, DNF history, and application health afterward. Kernel updates require a reboot plan; needs-restarting -r helps confirm whether the running system still matches installed packages.

Offline patching should use trusted repository content, not ad hoc RPM bundles. Kernel live patching with kpatch can reduce downtime for eligible fixes but does not replace normal security updates. Test patches before production rollout, record what you installed, and keep your standard recovery path available instead of assuming every transaction can be undone in place.

References

• Managing and monitoring security updates — Red Hat documentation for identifying, installing, and automating RHEL 10 security updates
• Applying patches with kernel live patching — Red Hat documentation for kpatch and RHEL 10 live patching
• Red Hat Security Advisories and CVE database — Red Hat security advisories and vulnerability information
• DNF Command Reference — upstream reference for updateinfo, --security, --advisory, --cve, and --secseverity