How Red Hat Backports Security Patches: A Complete Guide to RHEL Vulnerability Management

The Backporting Problem

If you have ever managed a RHEL server and run rpm -q openssl, you have probably seen something like this:

$ rpm -q openssl
openssl-3.0.7-27.el9_4.x86_64

Then you check the upstream OpenSSL project and see that the latest release is 3.3.1. Your immediate reaction: my server is three minor versions behind, it must be full of unpatched vulnerabilities. You run a vulnerability scanner. It reports 47 CVEs. Your security team files urgent tickets. Your ops team scrambles to plan an emergency maintenance window.

And almost every one of those 47 CVEs is a false positive.

This is the single most common misunderstanding in RHEL vulnerability management. The version number 3.0.7 does not mean your system has the same code as upstream OpenSSL 3.0.7. Red Hat has taken the security fixes from OpenSSL 3.0.8, 3.0.9, 3.0.10, 3.0.11, 3.0.12, 3.0.13, 3.0.14, 3.1.x, 3.2.x, and 3.3.x and backported them into their 3.0.7 branch. The result is a package that has the version number 3.0.7 but contains all the security patches from every later release.

The key insight is this: on RHEL, the version number tells you the API/ABI compatibility baseline. The release number (the part after the hyphen, like 27.el9_4) tells you the actual patch level. A scanner that only looks at the version and ignores the release will get RHEL wrong every single time.

This is not a RHEL-specific quirk. Every enterprise Linux distribution that provides long-term support — SUSE, Ubuntu LTS, Debian Stable — does some form of backporting. But Red Hat's approach is the most aggressive and the most misunderstood, partly because RHEL's 10-year support lifecycle means packages can drift very far from upstream versions while remaining fully patched.

What Is Backporting?

Backporting is the practice of taking a specific fix from a newer version of software and applying it to an older, stable version. The term comes from "porting back" — a change is written for version N+1 and then adapted to work on version N.

When the OpenSSL project fixes CVE-2024-0727 in version 3.0.14, they write a patch against their current 3.0.x development tree. Red Hat takes that patch — sometimes the exact commit, sometimes a modified version that accounts for their own changes — and applies it to their 3.0.7 branch. The resulting RPM bumps the release number from, say, openssl-3.0.7-24.el9 to openssl-3.0.7-27.el9.

Red Hat does this because their customers — banks, hospitals, government agencies, defense contractors — cannot tolerate arbitrary major-version upgrades. An upgrade from OpenSSL 3.0.x to 3.3.x could change API behavior, remove deprecated functions, introduce new cipher suite defaults, or alter TLS negotiation behavior. Any of these changes could break applications that have been validated and certified against the 3.0.x API.

The contract Red Hat makes with its customers is this: we will keep your system's packages at the same major version for the entire support lifecycle (typically 10 years), and we will backport every security fix so you never have to choose between security and stability. This is the core value proposition of RHEL.

The downside is that it makes version-based vulnerability assessment fundamentally broken. Every tool, process, or human that equates "older version number = vulnerable" will produce incorrect results on RHEL and its derivatives (Rocky Linux, AlmaLinux, Oracle Linux, CentOS Stream).

How Backporting Works: The Flow

The following diagram illustrates how a security fix flows from upstream to RHEL packages. Notice that the version number stays the same — only the release number changes.

The critical detail: the RHEL 9 package version stays at 3.0.7 even after patching, but the release number changes from -24 to -27. Similarly, RHEL 8 maintains its own independent backport branch at 1.1.1k. Each RHEL major version has its own package branch, and each branch receives its own backported patches.

How Red Hat Versioning Works: NEVRA Explained

RPM packages use the NEVRA naming convention: Name-Epoch:Version-Release.Architecture. Understanding each component is essential for accurate vulnerability assessment on RHEL.

Let's break down a real package identifier:

openssl-1:3.0.7-27.el9_4.x86_64
   │     │  │     │         │
   │     │  │     │         └─ Architecture: x86_64 (CPU arch)
   │     │  │     │
   │     │  │     └─ Release: 27.el9_4
   │     │  │          │  │
   │     │  │          │  └─ .el9_4 = RHEL 9, minor release 4
   │     │  │          └─ 27 = 27th build (THIS changes with patches)
   │     │  │
   │     │  └─ Version: 3.0.7 (stays the same across backports!)
   │     │
   │     └─ Epoch: 1 (overrides version comparison order)
   │
   └─ Name: openssl

The Version field (3.0.7) corresponds to the upstream OpenSSL version that Red Hat originally based their package on. This number never changes during the lifecycle of a RHEL major version. It exists solely to identify the API/ABI compatibility baseline.

The Release field (27.el9_4) is what actually indicates the patch level. Each time Red Hat backports a security fix, rebuilds the package, or applies a bug fix, the release number increments. The suffix .el9 means RHEL 9, .el8 means RHEL 8, and the optional _4 indicates the RHEL minor release (9.4 in this case).

The Epoch field is rarely used but overrides all other version comparison logic when present. It exists to handle cases where a package's version numbering scheme changed (for example, if upstream switched from date-based to semver versioning). When comparing two package versions, RPM checks Epoch first, then Version, then Release.

Here are real-world examples of how this plays out across different packages:

Look at the openssh row: upstream is at 9.8p1, but RHEL 9 ships 8.7p1. That's a full major version behind. Yet CVE-2024-6387 — the regreSSHion vulnerability that made headlines worldwide — is fixed in RHEL's 8.7p1-38.el9 package because Red Hat backported the patch. A version-only scanner would flag this as critically vulnerable. It is not.

Red Hat's Security Data Sources

Red Hat publishes security data through four primary channels. Each serves a different audience and use case, but they all describe the same underlying information: which packages fix which CVEs.

RHSA — Red Hat Security Advisories

RHSAs are the primary mechanism for communicating security patches to customers. Each advisory follows the format RHSA-YYYY:NNNN (e.g., RHSA-2024:1879) and includes the following information:

• Severity rating (Critical, Important, Moderate, Low)
• List of CVEs addressed by the update
• Affected products and architectures
• Updated package names with exact NEVRA versions
• Description of the security issues and fixes

A single RHSA can fix multiple CVEs in one package update, or it can cover updates to multiple packages that address a common vulnerability. RHSAs are published at access.redhat.com/security/security-updates.

OVAL — Open Vulnerability and Assessment Language

OVAL definitions are XML-based, machine-readable vulnerability descriptions that automated scanners use to determine whether a system is patched. Red Hat publishes OVAL data for RHEL 7, 8, and 9 at access.redhat.com/security/data/oval/v2/. Each OVAL definition contains test criteria that specify the exact package version-release required to resolve a vulnerability. This is what makes OVAL the gold standard for RHEL vulnerability scanning — it accounts for backporting by checking the release number, not just the version.

CSAF — Common Security Advisory Framework

CSAF is the JSON-based successor to OVAL for newer advisories. Red Hat publishes CSAF data at access.redhat.com/security/data/csaf/v2/advisories/. CSAF advisories use a structured JSON format that is easier to parse than XML and includes product tree definitions, vulnerability status per-product, and remediation information. As the industry shifts toward CSAF (mandated by the EU Cyber Resilience Act for some vendors), expect this format to become increasingly important.

Red Hat CVE Database

The per-CVE database at access.redhat.com/security/cve/ provides Red Hat's assessment of every CVE, including their independent severity rating, affected products, and fix status. The fix status can be one of:

• Affected — the vulnerability impacts this RHEL version and a fix is planned
• Fix deferred — a fix is planned but not yet scheduled for release
• Will not fix — Red Hat has determined a fix is not warranted (see FAQ below)
• Not affected — the vulnerable code is not present in Red Hat's build
• Under investigation — Red Hat is still assessing impact

For any specific CVE, visit access.redhat.com/security/cve/CVE-YYYY-NNNN to see the full assessment. The API powering this data is also available programmatically, which is what the interactive tool below uses.

Why Naive Scanners Get RHEL Wrong

Most vulnerability scanners work by extracting a list of installed packages and their version numbers, then comparing those versions against a database of known-vulnerable versions. This approach works well for ecosystems where the version number directly corresponds to the upstream release (Alpine, Arch, Homebrew). It fails catastrophically on RHEL.

Here is what happens when a version-only scanner evaluates an RHEL 9 system with openssl-3.0.7-27.el9:

1. The scanner extracts the version: 3.0.7.
2. It queries the NVD for OpenSSL vulnerabilities and finds every CVE fixed in versions 3.0.8 through 3.3.1.
3. It compares: 3.0.7 < 3.0.8, 3.0.7 < 3.0.9, etc. — every one matches.
4. It reports dozens of CVEs as "present" on your system.
5. Every single one is a false positive because Red Hat already backported those fixes.

The correct approach is to check the full NEVRA (including the release number) against Red Hat's OVAL data. OVAL definitions say things like: "if openssl is earlier than 1:3.0.7-27.el9_4, then CVE-2024-0727 is present." This test correctly accounts for backporting because it compares the full Epoch:Version-Release, not just the version.

In practice, the false positive differential is enormous. When scanning a Rocky Linux 9 container image, ScanRook's benchmarks show that different scanners produce wildly different finding counts depending on how they handle backported packages. Scanners that use OVAL data produce fewer, more accurate results. Scanners that rely on version-only matching flood your reports with false positives that waste engineering time and erode trust in the scanning process.

ScanRook handles RHEL scanning through triple-source enrichment: it queries OSV for ecosystem-level data, downloads and parses Red Hat OVAL definitions for release-specific patch status, and queries the Red Hat per-package security API for additional context. This layered approach eliminates false positives from backporting while still catching vulnerabilities that any single source might miss.

Red Hat CVE Lookup Tool

Enter an RPM package name to see CVEs that Red Hat has tracked for it, including severity ratings and advisory links. This tool queries Red Hat's public security data API to show you exactly which vulnerabilities have been addressed through backported patches.

How OVAL Works — With Real XML Examples

OVAL (Open Vulnerability and Assessment Language) is the machine-readable format that makes accurate RHEL scanning possible. It was originally developed by MITRE and is now maintained by the Center for Internet Security (CIS). Red Hat publishes OVAL definitions as XML files that contain precise test criteria for every RHSA they release.

Here is a simplified but representative OVAL definition for a hypothetical OpenSSL security update:

<definition id="oval:com.redhat.rhsa:def:20241879"
            class="patch">
  <metadata>
    <title>RHSA-2024:1879 - Important: openssl security update</title>
    <affected family="unix">
      <platform>Red Hat Enterprise Linux 9</platform>
    </affected>
    <reference ref_id="RHSA-2024:1879" source="RHSA"
               ref_url="https://access.redhat.com/errata/RHSA-2024:1879"/>
    <reference ref_id="CVE-2024-0727" source="CVE"
               ref_url="https://access.redhat.com/security/cve/CVE-2024-0727"/>
    <reference ref_id="CVE-2024-2511" source="CVE"
               ref_url="https://access.redhat.com/security/cve/CVE-2024-2511"/>
    <description>
      OpenSSL is a toolkit implementing the SSL and TLS protocols.
      Security Fix(es):
      * openssl: denial of service via null dereference (CVE-2024-0727)
      * openssl: unbounded memory growth with session handling (CVE-2024-2511)
    </description>
  </metadata>

  <criteria operator="AND">
    <!-- Check: is this RHEL 9? -->
    <criterion test_ref="oval:com.redhat.rhsa:tst:20241879001"
               comment="Red Hat Enterprise Linux 9 is installed"/>

    <!-- Check: is openssl older than the fixed version? -->
    <criterion test_ref="oval:com.redhat.rhsa:tst:20241879002"
               comment="openssl is earlier than 1:3.0.7-27.el9_4"/>

    <!-- Check: is the package signed by Red Hat? -->
    <criterion test_ref="oval:com.redhat.rhsa:tst:20241879003"
               comment="openssl is signed with Red Hat redhatrelease2 key"/>
  </criteria>
</definition>

Let's break down what each element means and how a scanner uses it:

• definition id — A unique identifier that maps to the RHSA number. The numeric suffix 20241879 corresponds to RHSA-2024:1879.
• class="patch" — This definition describes a security patch. Other classes include "vulnerability" (describing the flaw itself) and "inventory" (describing system properties).
• affected platform — Which RHEL versions this definition applies to. Separate OVAL files exist for RHEL 7, 8, and 9.
• reference elements — Cross-references to the RHSA advisory and the specific CVEs it addresses.
• criteria — The actual test logic. The operator="AND" means ALL conditions must be true for the system to be considered vulnerable. The critical test is the version comparison: openssl is earlier than 1:3.0.7-27.el9_4.

When a scanner processes this definition, it performs an Epoch:Version-Release comparison using RPM's version comparison algorithm. If the installed openssl package has EVR 1:3.0.7-24.el9, that is earlier than 1:3.0.7-27.el9_4, so the system is vulnerable. If the installed EVR is 1:3.0.7-27.el9_4 or later, the criteria evaluates to false and the system is patched.

This is the correct way to assess RHEL security. The OVAL definition does not care that 3.0.7 is behind upstream — it only checks whether the release number is high enough to include the backported patch. This is why OVAL-based scanning produces dramatically fewer false positives than version-only scanning on RHEL.

Red Hat's OVAL data is available for free download. The files are organized per RHEL version:

• RHEL 9 OVAL definitions
• RHEL 8 OVAL definitions
• RHEL 7 OVAL definitions

Red Hat vs Debian vs Alpine: Different Approaches to Security Patching

Red Hat is not the only distribution that backports, but their approach differs significantly from other major Linux distributions. Understanding these differences is important for teams that manage heterogeneous infrastructure.

Debian uses a similar backporting strategy for its stable releases. A Debian Stable package might show openssl 3.0.11-1~deb12u2 where the u2 suffix indicates the second security update. Debian's approach is slightly less aggressive than Red Hat's — Debian may upgrade to a newer upstream point release (3.0.11 instead of staying at 3.0.7) if the security team determines it's safe to do so.

Alpine takes the opposite approach entirely. Alpine tracks upstream closely and typically ships the latest upstream version or one very close to it. This makes version-based scanning more accurate on Alpine but means that Alpine users experience more frequent package changes and potential API breakage. For container workloads where images are rebuilt frequently, this tradeoff is often acceptable.

For a deeper discussion of scanning approaches across different package ecosystems, see our article on installed-state scanning vs. advisory matching.

Frequently Asked Questions

Further Reading

• Red Hat's official backporting policy — Red Hat's own explanation of their backporting process
• Red Hat OVAL v2 data — Machine-readable vulnerability definitions for RHEL 7, 8, 9
• Red Hat CSAF advisories — JSON-based security advisory feed
• Red Hat CVE Database — Per-CVE status for every RHEL product
• Red Hat Enterprise Linux Life Cycle — Support timeline and phase definitions
• OVAL project at CIS — The OVAL standard specification

Related ScanRook articles