CVEs (Common Vulnerabilities and Exposures) are constantly being discovered and patched. When discovered, it means a new security flaw exists in either an operating system or a piece of software and should be patched as soon as possible. Fixing the vulnerabilities, of course, is up to the developers. Patching those vulnerabilities, however, is up to the admin (or user). Thing is, you might not know if you’re using a piece of software that includes one or more CVEs.

How do you uncover this information? Do you have to spend hours researching? Not really. In fact, all you need to know is the CVE you’re looking for and the piece of software it affects. With those two bits of information in hand, you can quickly discover if what’s installed on your Red Hat Enterprise Linux-based distribution contains that vulnerability.

I’m going to show you how to do just that.

SEE: 40+ open source and Linux terms you need to know (TechRepublic Premium)

What you’ll need

The only thing you’ll need to make this work is a running instance of an RHEL-based Linux distribution (such as AlmaLinux, Rocky Linux or Fedora Linux). You don’t even need a user account with sudo privileges (just a regular ol’ user).

You will need to know which CVE you’re looking for. I prefer to head over to the official home of CVE listings at You can do a quick package-based search to view a complete list of packages that have associated CVEs.

With that OS and CVE ready, let’s check for vulnerabilities.

How to Run a CVE Check

Here’s the deal: The CVE check is quite simple. We’re going to pipe the changelog output from the rpm command to the grep command to list any possible CVEs. The syntax of the command is:

rpm -q --changelog PACKAGE | grep CVE

Where PACKAGE is the name of the installed software to be checked, and CVE is the full name of the CVE in question. Before we do that, let’s take a look at the non-piped output of the OpenSSH package. Issue the command:

rpm -q --changelog openssh

The output should be a complete listing of the changelog for openssh (Figure A).

Figure A

The entire changelog of the installed version of openssh on Alma Linux.

You could scroll through the entire listing for the CVE you’re looking for, or you could pipe it through grep and have the command do the heavy lifting. Let’s say you’re looking for CVE-2020-14145, which is described as:

In OpenSSH 7.9, due to accepting and displaying arbitrary stderr output from the server, a malicious server (or man-in-the-middle attacker) can manipulate the client output, for example, to use ANSI control codes to hide additional files being transferred.

To check against that vulnerability, the command would be:

rpm -q --changelog openssh | grep CVE-2020-14145

If you see anything in the output, it means openssh has been patched against that vulnerability (Figure B).

Figure B

OpenSSH has been patched against CVE-2020-14145 in AlmaLinux.

If you don’t see anything in the output, it means openssh has not been patched and you should upgrade immediately. As long as the developers of openssh have patched the source and it’s available in the distribution repositories, the upgrade should take care of the issue.

To upgrade the package in question, issue the command (which does require sudo privileges):

sudo dnf upgrade PACKAGE

Where PACKAGE is the software in question. Once the upgrade completes, run the CVE check again to see if the package has been patched for the vulnerability. If not, keep coming back to the upgrade, and (hopefully) the software maintainers will get that issue fixed asap.

And that’s all there is to checking for CVE vulnerabilities in the packages you have installed on your RHEL-based Linux distributions.

Subscribe to TechRepublic’s How To Make Tech Work on YouTube for all the latest tech advice for business pros from Jack Wallen.

Image: MyImages_Micha, Getty Images/iStockphoto