Debian and Red Hat backport security fixes into the version they already shipped, so a patched package can keep an older upstream version number. To check, read the package changelog or compare the exact package version with the vendor advisory, not the upstream release number.
What backporting means
Red Hat defines backporting as taking a fix for a security flaw out of the most recent upstream version and applying it to an older version of the package the vendor distributes. Debian explains the reason in its security FAQ: the most important guideline is to make as few changes as possible, because people rely on the exact behaviour of a release once it is made. Changing an API or ABI, even slightly, can break a system.
So moving to a new upstream version is usually not the fix. The relevant change is lifted out and applied to the old code.
Both vendors say the same practical thing. Debian: the version number for a package may suggest you are still running a vulnerable version, and you should check the changelog or compare against the advisory. Red Hat: looking at a version number alone will not tell you whether you are vulnerable.
Why this trips up ops and auditors
A press article says "upgrade to version X.Y.Z to fix this". A scanner sees version 2.4.4 and the fix is in 2.4.5. Your Debian host runs 2.4.4 with the fix applied. Without backport awareness, the scanner flags a false positive and someone loses a day chasing it.
The reverse also happens. A version that looks new may not include the fix if the vendor has not yet backported it. Do not accept a version number as evidence either way.
How to check a package
- Find the advisory from your vendor for the issue, for example a DSA for Debian.
- Note the fixed package version the advisory names. It is the vendor's version string, including any distro suffix.
- On the host, list the installed version with your package manager.
- Compare the two strings using the package manager's version ordering, not by eye.
- Or read the package changelog for the CVE ID. Both Debian and Red Hat treat the changelog as a valid record.
- Record the result in the ticket with the commands you ran.
Tell your scanner
Many scanning tools can read vendor advisory data, which lets them compare against the vendor's fixed version. If yours reports an upstream version only, treat its findings for distribution packages as leads to verify. Ask the tool owner whether it consumes vendor feeds. Debian's FAQ is blunt on this point: if a vulnerability management tool lists open issues, the Debian team will not generally answer questions about it, so the follow-up goes to the tool vendor.
When it is not a false positive
A package really can be unpatched. Debian notes that some issues are not fixed in a stable release at all, for example low-impact ones deferred to a point release, and its Security Tracker holds the status for each CVE. Check the tracker note before declaring victory or defeat.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow how a finding gets checked for whether it can really be exploited, then compare that with a pure version match.
Safeguard offers reachability analysis and SBOM scanning, which helps separate findings that matter from version-only matches. You can run a free scan.
Quick check
Is an older version number always vulnerable on Debian?
No. Debian says it backports fixes, so you should check the changelog or compare the exact version to the advisory.
Should I upgrade to the newest upstream version instead?
Usually not. Moving to a new upstream version can change behaviour. Apply the vendor's security update for your release.
Sources
- Debian, Security FAQ
- Red Hat, Backporting security fixes
Last reviewed: 19 October 2026.
