Backport

A backport is a change, most often a security fix, taken from a newer release of a piece of software and applied to an older version that is still in use. The newer release contains the fix as its author wrote it. The older version has different surrounding code, so the fix has to be adapted, rebuilt, and tested for that version. Backporting is how a Linux distribution can keep a pinned version of a package for years and still deliver security fixes for it after upstream has moved on.

What is a backport?

Software projects fix bugs in their current branches. When the PHP project fixed the PHP2Shell vulnerabilities in October 2026, it released PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. For the end-of-life 7.4, 8.0, and 8.1 branches, it published source-only fix branches with minimal mitigations and no binaries. Older versions got nothing. Enterprise Linux 9 ships PHP 8.0, Enterprise Linux 8 ships PHP 7.2, 7.4, and 8.0 as module streams, and CentOS 7 ships PHP 5.4. Distributions built their fixed 7.4 and 8.0 packages from the upstream fix branches. PHP 5.4 had no fix branch, so CIQ engineers backported the fix into the CentOS 7 package themselves. That means reading the upstream patch, finding the equivalent code in the older version, rewriting the change to fit, building the package, and testing it.

A backport is deliberately narrow. It carries the fix and nothing else. The version number stays the same, apart from a release suffix such as 8.0.30-3.4.el9_6_ciq, and the behavior applications depend on is unchanged. That is the distinction between a backport and an upgrade: an upgrade moves to a newer version with everything that version changed, while a backport moves one fix into the version already in production.

Why backports matter

Enterprise environments pin versions on purpose. An application certified against PHP 8.0, a kernel module built against a specific kernel, or a configuration management setup tested against one release of a package should not change without warning for the people who depend on it. Pinning gives stability, but a pinned version also stops receiving upstream fixes the moment upstream moves on. Backporting is what makes pinning safe. It separates two things that are otherwise coupled: the version you run and the security fixes you receive.

Enterprise Linux distributions, including Rocky Linux, work this way: each release ships a fixed set of package versions, and security fixes are backported into them for the life of the release. Long-term support from Rocky Linux from CIQ Pro (RLC Pro) extends the same model. RLC Pro LTS pins a specific minor release and keeps backporting fixes to it after the rolling release has moved on.

One consequence trips up vulnerability scanners. A scanner that reads only the upstream version number can flag PHP 8.0.30 as vulnerable to PHP2Shell, because the PHP project never shipped a fixed 8.0 release. The distribution's patched 8.0.30 build is not vulnerable. Scanners get the right answer when they read the advisories for the exact release a host runs. Nessus scans of RLC Pro hosts now read CIQ advisories, down to each pinned LTS release. Administrators can also check the package release suffix.

What it takes to backport a security patch

Backporting is engineering work, and the effort rises with the distance between the versions.

Step	What it involves
Understand the fix	Read the upstream patch and advisory, sometimes under embargo, and understand what the bug is and why the change fixes it
Locate the code	Find the equivalent code in the older version. Functions get renamed or restructured between releases, so the patch may not apply cleanly
Adapt the change	Rewrite the fix for the old code, preserving the behavior the fix is meant to protect without introducing new behavior
Build	Produce packages for each architecture and, on Enterprise Linux 8 and 9, each module stream that gets the fix
Test	Confirm the fix closes the vulnerability and that existing applications still work
Publish	Sign the packages, publish them with an advisory, and document the fixed versions so administrators can verify

The greater the gap, the harder the work. PHP 8.0 reached end of life upstream in November 2023. PHP 5.4, released in 2012 and shipped with CentOS 7, reached end of life in 2015, and no upstream fix branch covers it. CIQ Bridge engineers backported the PHP2Shell fix into the CentOS 7 PHP 5.4 package. Not every version gets a fix. PHP 7.2 and 7.3 have no upstream fix branch, and the Enterprise Linux 8 php:7.2 stream has no patched build, so hosts on it need to switch to a patched stream or apply interim mitigations.

Backports and the speed of security response

Google's threat intelligence group found that most of the growth in exploitation in 2026 came from attackers weaponizing vulnerabilities quickly after disclosure. A version stays exposed until a fixed package for it is published, so the time a distributor takes to backport, build, and publish a fix matters for security. For PHP2Shell, CIQ released fixed packages for RLC Pro LTS 9.6 and 9.2 about three and a half hours after the upstream fix went public. Fixes for RLC Pro 8, 9, and 10, RLC Pro LTS 8.6, and CIQ Bridge followed over the next two days. The Enterprise Linux 8 php:7.2 and php:8.0 streams have no patched build. Nathan Blackham, who leads the CIQ engineers who shipped these fixes, wrote about the response the day it happened, and the PHP2Shell guide lists every fixed package.

Backports at CIQ

Backporting security fixes to the versions customers run is a core part of what CIQ does for RLC Pro. RLC Pro LTS releases receive backported fixes for up to four years of security patching on even-numbered minor versions, so a pinned release keeps getting fixes without a version change. CIQ Bridge backports Critical and Important fixes for a curated set of priority packages on CentOS 7.9, where no upstream fix exists at all, while you migrate to RLC Pro or RLC Pro Hardened.