In this blog post we take a look at “backported fixes” and how they apply to infrastructure vulnerability scanning. It’s easy to assume that identifying vulnerabilities is as simple as reading a version number and checking it against a list of known issues. In many cases, that works well but sometimes, version numbers lie. We attempt to break down what backporting is, what it is, how it can create confusion (and false positives) and how vulnerability scanners deal with this problem.
Backporting is the process of taking a security patch or feature from a newer version of software and applying it to an older version without changing the version. It is most commonly seen in enterprise and long-term support (LTS) Linux distributions, like Debian, Ubuntu, CentOS, and Red Hat Enterprise Linux (RHEL). Backporting is most commonly used by these vendors to address security issues in older software and packages, however it can be used to address wider any applicable bug were the newer version addresses a stability issue.
Software maintainers in these ecosystems prioritize stability. Rather than upgrading to the latest version of a package, which may introduce new features or bugs. Vendors choose to “backport” only the relevant security fixes into the older, trusted version that has already undergone extensive testing.
During a review of a remote web server, through evaluation of the exposed HTTP headers it is discovered that the server is running Apache HTTP Server 2.4.41. Based on the version number alone, you might assume it’s vulnerable to CVE-2024-39573 a known vulnerability patched in Apache 2.4.52.
$ curl -skI http://10.10.120.6 HTTP/1.1 200 OK Date: Tue, 27 May 2025 14:52:23 GMT Server: Apache/2.4.41 (Ubuntu) Last-Modified: Tue, 24 Sep 2024 11:28:34 GMT ETag: "2aa6-622dbce5127b9" Accept-Ranges: bytes Content-Length: 10918 Vary: Accept-Encoding Content-Type: text/html
However, Ubuntu may have already backported the fix into their 2.4.41 build, and the vulnerability no longer applies even though the version number still reads 2.4.41. In fact, if we check Ubuntu’s changelog or package metadata there is an explicit security update note relating to CVE-2024-39573:
This tells us that Ubuntu Apache version 2.4.41 received several security updates but the version remained the same.
There are solid reasons why vendors backport instead of upgrading to the latest version:
For these reasons, a system running “older” software might actually be secure if the appropriate fixes have been backported.
Most vulnerability scanners begin with service detection — identifying open ports and the software/services running on them. A key part of this process is version identification. For the example already provided, the scanner will be able to make an accurate detection and identification of the Apache web server. Once the scanner sees a HTTP banner such as:
Server: Apache/2.4.41 (Ubuntu)
It is able to extract the version number and check the version number against a database of known vulnerabilities (CVEs). If Apache 2.4.41 is listed as vulnerable to certain CVEs, the scanner raises an issue. However, there is a problem in the information that was extracted from the banner. The 2.4.41 version string does not reflect whether the package has been patched by the OS vendor. The “(Ubuntu)” part of the version string provides an indication to the scanner that the service may be backported, but overall there isn’t enough information to accurately determine the affected vulnerabilities. As a result, the scanner might flag a vulnerability that doesn’t actually exist or is applicable on the system. These are known as false positives.
When a scanner performs an unauthenticated external scan, it has no special access. It can’t inspect package metadata or installed patches. It’s forced to rely on what the service tells it usually through its banner or response headers. This is where backporting becomes problematic. Most services including Apache, Nginx, OpenSSH, and others don’t update their banner strings when security fixes are backported. Even on authenticated scans its not always possible to be 100% sure that the external services are related to that of the internal package versions. This could be due to a reverse proxy or load balancer between the scanner and the external service. Often this results in vulnerability scanners airing on the side of caution and reporting on all version information it discovered regardless of it’s source despite having access to the package and version details of the server.
Leading vulnerability scanners especially those used in infrastructure scanning incorporate logic to reduce false positives caused by backporting. These strategies include:
1. OS Fingerprinting
Scanners attempt to identify the underlying operating system (e.g., Ubuntu 20.04, RHEL 8) and cross-reference the distro’s patch history.
2. Vendor Patch Awareness
Some scanners maintain vendor-specific backport data, allowing them to suppress alerts for known backported fixes on specific platforms.
3. Credentialed Scanning
When provided with authenticated access, scanners can query the system directly to list installed packages, patch levels, and actual binaries drastically reducing guesswork.
4. Custom Rules and Overrides
Security teams can often define suppression rules based on their knowledge of the environment. For example, ignoring all CVEs affecting Apache 2.4.41 on Ubuntu 20.04 if they’ve verified it’s patched.
Despite these techniques, false positives can’t always be eliminated especially in blackbox scanning scenarios. That’s why context matters, and why understanding backporting is essential for accurate vulnerability assessments.
Backporting is a common and effective strategy for keeping systems secure without the disruption of frequent upgrades. But it introduces ambiguity especially for tools that rely heavily on version strings to identify vulnerabilities.
For security professionals and system administrators, the key takeaway is this: version numbers are not the whole story. Understanding your distro’s backporting policies, leveraging credentialed scans, and reviewing scanner findings critically are essential to avoid chasing ghosts.
As infrastructure scanning matures, tools continue to evolve in sophistication. But as long as banners remain frozen in time and version strings stay vague, human judgment backed by good data will remain a necessary part of the vulnerability management process.
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network, and cloud infrastructure. AppCheck are authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA).
No software to download or install.
Contact us or call us 0113 887 8380
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network and cloud infrastructure. AppCheck are authorised by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA)
