Vulnerability Scans

If you handle payment details on your server, you’ve likely had to take part in the PCI circus and get an automated scan ran against your solution.

The scans check for common issues like software versions and unnecessary open ports, things that may point to deeper security issues on a server.

At the end of a scan, a PDF is generated that lets you know how you’ve scored and points out anything that needs changing before your server can be used for storing payment information. The issues that need resolving are typically flagged as critical or high.

Running one of these scans against a CentOS or RedHat server will likely return a worrying amount of software outdated issues, and the main point of this article is to let you know that it’s not as bad as it looks due to the RedHat backporting policy

Backported fixes

RedHat’s backporting policy is outlined on the link below:


The gist of it is that due to RedHat/CentOS being an enterprise, LTS style, operating system one of the main features is that the major version numbers that ship with a release won’t change for the duration. Just refusing to update packages isn’t really a viable option, as this would leave RedHat systems vulnerable to any security issues found during the operating systems lifecycle. Instead, RedHat take the security fixes from higher versions of the packages and include them in their own releases, whilst leaving out any new features that may change how the program fundamentally operates.

To illustrate this, here’s a fictitious example:

CentOS 5 launches with the package widgets, running version 9.1.20.

After launch of CentOS 5, a disclosure points out a number of vulnerabilities in widgets-9.1.20 and the widgets team push out a series of security patches.

Whilst they push out their updates, they take the opportunity to implement some new functionality that changes how widgets handles it’s plugins and call it widgets-9.2.0

This breaks a few of the older clients that interface with widgets-9.1.20

Instead of putting widgets-9.2.0 in the CentOS repositories, CentOS release a new package called widgets-9.1.21 that contains the security fixes but not the new plugin changes.

This way, CentOS can be sure that implementations of widgets will continue to work on CentOS 5.

Confusion arises when a PCI scan checks for the widget version. In that example, it would spot widgets-9.1.21, see that it’s lower than widgets-9.2.0 and flag up that the version of widgets on that server hasn’t had critical security patches applied.

CVE Numbers

Each failure on a PCI report should come with an accompanying CVE number, in the following format:


These numbers relate to a vulnerability, which can be looked up here:


Our main reason for being interested in them is that we can crosscheck a CVE with RedHat to see if the issue was resolved with a backport, or if we actually need to take action on it.

Each CVE can be checked against the RedHat website https://access.redhat.com/security/cve/ like so:


From that page, you can see that the vulnerability described in CVE-2014-0160 didn’t affect various versions of RedHat, though to a PCI scan it would probably flag as a failure.

To rectify this with your scanning agency, simply sending them that RedHat cve page, the backporting link from earlier and the version of the software in question should be enough to get them to revoke the failure.

Checking against RPM

A quick way to check whether or not a package has had the backport applied is to view the change log of the package. On RedHat-based operating systems you can use the below command where [PACKAGE] is the name of the package you would like to check.

  rpm -q --changelog [PACKAGE]

You can then search through this by using the grep command. For example to search whether or not PHP has had a backport applied for CVE-2016-1903 you would use the below command.

  rpm -q --changelog php | grep CVE-2016-1903