OpenSSL vulnerabilities by version: 1.0.2 to 4.1

How many CVEs does my OpenSSL version have?

The column “CVEs according to the NVD” counts CVEs whose NVD configuration lists the version as vulnerable, queried on 4 November 2026 through the NVD API under cpe:2.3:a:openssl:openssl, without rejected entries, each hit re-checked against its configuration. CVE-2019-0190 appears for every version; it concerns mod_ssl in the Apache HTTP Server and lists OpenSSL only as the environment. It is taken out. Where the NVD has no CVSS score of its own, the CISA-ADP score applies; that is the case for almost all CVEs from 2026.

The right column counts the version ranges OpenSSL itself states on its vulnerabilities page, with its own rating Low, Moderate, High or Critical. The column “Shipped in” names which build system ships this version at its release tag.

$ curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:openssl:openssl:3.0.19&noRejected"  \
| jq .totalResults

28

Why does the NVD score OpenSSL vulnerabilities higher than OpenSSL does?

OpenSSL rates in its own levels and states the preconditions of a vulnerability in its description. The NVD and CISA-ADP score by CVSS. Of the 63 OpenSSL CVEs from 2026, OpenSSL rates 49 as Low, 11 as Moderate and 3 as High. OpenSSL rates the four CVEs with CVSS 9.0 or higher as Low or Moderate.

For devices the precondition is what counts. CVE-2026-31789 affects only 32-bit platforms, so devices with 32-bit ARM Linux too; but it needs a certificate of over 1 GB that the application prints or logs.

Which OpenSSL CVEs are missing from the version query?

For a line past its end of support, OpenSSL no longer enters version ranges, and the NVD almost never lists these lines after that either. The last entry for 3.1 dates from 20 January 2025, for 3.2 from 30 September 2025, for 3.3 from 7 April 2026. Since the respective end of support, OpenSSL has reported 37 vulnerabilities for 3.0 and a newer line but not for 3.1; for 3.2 there are 35, for 3.3 21. The code of these vulnerabilities is in the line before and in the line after. 3.1, 3.2 and 3.3 are therefore probably affected; OpenSSL has not checked this. One example: OpenSSL names CVE-2025-9230 for 1.0.2, 1.1.1, 3.0 and 3.2 to 3.5, not for 3.1. For 3.1.8, 3.2.6 and 3.3.7 the NVD number is not a finding.

13 CVEs with OpenSSL as CNA have no configuration in the NVD and are missing from every version query: eleven with status “Deferred”, among them CVE-2024-12797 (High, raw public keys in 3.2 to 3.4) and CVE-2025-9230 to -9232, plus CVE-2026-54876 and CVE-2026-14456 with “Awaiting Analysis”. The right column of the table above includes them.

For 3.0.22, 1.1.1w and 1.0.2u OpenSSL keeps reporting vulnerabilities, with fixes in 3.0.23, 1.1.1zj and 1.0.2zs. These versions exist only for customers with a support contract; the public repository has no tag 3.0.23.

Which OpenSSL version is still supported?

OpenSSL releases twice a year, in April and in October. Every two years, in April of odd years, a version becomes an LTS with five years of support; the next is 4.2 in April 2027. Other lines from 3.5 on get 13 months of support. According to the release strategy, API and ABI stay compatible within the same major version: 3.0 and 3.5 both use libssl.so.3 and libcrypto.so.3. With 4.0, .so.4 begins.

Which OpenSSL version is in Yocto, OpenWrt and Buildroot?

Read from the recipe and the Makefile at the release tags, as of 4 November 2026. Yocto also adds single fixes to the recipe as patches without changing the version number; Kirkstone 4.0.35, for example, patches for CVE-2024-41996 and CVE-2023-50781 on top of 3.0.19. What a build lists as fixed is therefore in the recipe and its patches; the version number alone is not enough.

The default image of OpenWrt 24.10.8 and 25.12.6 contains no OpenSSL; TLS there comes from mbedTLS. OpenSSL only enters the build with packages that need it. The package feed of an OpenWrt line keeps being updated after the release: at tag v24.10.8 it is 3.0.21, in the package feed 3.0.22.

$ curl -s "https://api.github.com/repos/openembedded/openembedded-core/contents/meta/recipes-connectivity/openssl?ref=yocto-5.0.21"  \
| jq -r '.[].name' | grep openssl_

openssl_3.5.8.bb

Where is the OpenSSL version in my firmware?

OpenSSL writes its version with the date as text into libcrypto, from 3.0 on in the form “OpenSSL 3.0.22 25 Aug 2026”, up to 1.1.1 with two spaces before the date. In the package checked, this text sits only in libcrypto, not in libssl. The file name of the library names only the major line: libssl.so.3 for every version from 3.0 to 3.6, libssl.so.4 from 4.0 on, libssl.so.1.1 for 1.1.x, and in the original libssl.so.1.0.0 for 1.0.x.

Checked on the package libopenssl3_3.0.22-r1_arm_cortex-a7_neon-vfpv4.ipk from the OpenWrt 24.10.8 package feed, 32-bit ARM, SHA-256 1ac68ea8fd17b168…, unpacked.

$ strings -a usr/lib/libcrypto.so.3 | grep -E "^OpenSSL [0-9]"

OpenSSL 3.0.22 25 Aug 2026

$ strings -a usr/lib/libssl.so.3 | grep -E "^lib(ssl|crypto)\.so"

libcrypto.so.3
libssl.so.3

$ curl -s https://raw.githubusercontent.com/openssl/openssl/OpenSSL_1_1_1w/include/openssl/opensslv.h  \
| grep "define OPENSSL_VERSION_TEXT"

# define OPENSSL_VERSION_TEXT    "OpenSSL 1.1.1w  11 Sep 2023"

How do I check this by hand?

1. 1

   Read the version: strings -a libcrypto.so.* | grep -E "^OpenSSL [0-9]" in the unpacked file system, openssl version on the device. If OpenSSL is statically linked into a program, there is no library of its own; then run strings on the program itself.

2. 2

   Find every copy: besides the system library, some applications bring their own OpenSSL with a version of its own.

3. 3

   Establish the origin: Yocto, OpenWrt, Buildroot or a distribution. For Yocto, read the patches in the recipe; they fix CVEs without a new version number.

4. 4

   Query the NVD with cpe:2.3:a:openssl:openssl:<version> and read OpenSSL's vulnerabilities page; it also lists the CVEs without an NVD configuration. For 3.1, 3.2 and 3.3, also read the vulnerabilities of the neighbouring lines.

5. 5

   Check the preconditions: many vulnerabilities affect only CMS, PKCS#7, CMP, QUIC, DTLS or 32-bit platforms. Whether the firmware uses these parts decides whether they can be exploited.

6. 6

   Check the CISA KEV catalogue for actively exploited vulnerabilities.

Can this run automatically?

LegacyMind reads the libraries and packages with their versions from the image and matches each one against the public vulnerability sources, with the location in the image and a note on whether a vulnerability is actively exploited. If the image gives no evidence of a version, the field stays empty.