OpenSSL vulnerabilities in embedded firmware: find the version, check backports, fix

Because the OpenSSL version in a device is rarely chosen on its own. It arrives with the chip vendor's SDK, the board support package or the Yocto or Buildroot release the product was first built on, and changing it touches every program that links against libcrypto. The OpenSSL release strategy states that from 3.0.0 onward "API/ABI compatibility will be guaranteed for the same MAJOR version number", and that under the older scheme only a change of the last digit, such as 1.1.0 to 1.1.1, keeps binary compatibility. Moving from 1.0.2 to 1.1.1, or from 1.1.1 to 3.x, therefore means rebuilding and often patching the web server, the VPN client, the update agent and any vendor daemon that uses TLS, then retesting all of it on hardware that may be several years old.

Meanwhile the support clock runs out. The same release strategy page, last modified 7 May 2026, lists "Versions 3.0, 1.1.1 and 1.0.2" as no longer supported and names 3.5 as the current LTS, supported until 2030-04-08. The project's 1.1.1 end-of-life notice records that 1.1.1 was released on 11 September 2018 as an LTS and reached end of life exactly five years later, and that 3.0 would be supported until 7 September 2026. Its 1.0.2 vulnerability page states that 1.0.2 "is out of support since 1st January 2020" and that extended support is available for premium support customers.

End of life does not stop new CVEs from applying to those branches. The project's 1.1.1 vulnerability page listed 31 CVEs published after 11 September 2023 when read on 2026-11-10, two of them rated High:

The last two rows are the embedded problem in miniature. OpenSSL still lists the end-of-life branches as affected and names fixed letter releases for them, but the public git commits it links cover only supported lines. A device maker on 1.1.1 either buys extended support, ports the fix from a newer branch itself, or relies on a distribution that does. CVE-2026-84782 matters most to devices that speak DTLS, such as CoAP endpoints; our CoAP protocol security guide covers where DTLS sits in that stack.

They break the assumption that the version string tells you the patch level. CVE databases and scanners match on the upstream version range, so a library that reports 1.1.1d is flagged for every CVE fixed in 1.1.1e through 1.1.1w and later. A distribution or device vendor that backports fixes keeps the upstream number and changes only the package revision.

Debian's tracker for CVE-2022-0778 shows the pattern clearly. Upstream fixed the BN_mod_sqrt() loop in 1.1.1n, but Debian lists it fixed in buster's 1.1.1d-0+deb10u8 and bullseye's 1.1.1k-1+deb11u2, and in stretch's 1.0.2-based openssl1.0 package at 1.0.2u-1~deb9u7. Ubuntu lists the same fix in focal's 1.1.1f-1ubuntu2.12 and in bionic's openssl1.0 at 1.0.2n-1ubuntu5.8. For CVE-2023-0286, Debian lists the fix in 1.1.1n-0+deb10u4 and 1.1.1n-0+deb11u4, while upstream fixed it in 1.1.1t. A scanner reading only "1.1.1n" from any of those packages reports a false positive.

The reverse error is just as common. A device vendor that took a library from its SoC SDK may have applied no patches at all, and a package revision suffix proves nothing until the patch is located. Useful evidence, in order of strength:

Reachability matters as well. OpenSSL's description of CVE-2023-0286 says it requires CRL checking to be enabled and is "most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network", which many embedded clients have not. CVE-2022-0778, by contrast, is triggered during certificate parsing "prior to verification of the certificate signature", so almost any TLS client or server can reach it. When a backport or a configuration makes a CVE irrelevant, record that as a VEX statement rather than leaving it as an unexplained gap; our CSAF and VEX for device makers guide covers the format and the VEX generator drafts one.

Use exploitation data first, reachability second, and the CVSS base score to break ties. Public data as of 2026-11-09:

A KEV listing overrides everything else: CISA adds a CVE only when it has evidence of exploitation in the wild. Our KEV and EPSS prioritisation guide explains how the two signals combine, and the CVSS v4 vs v3.1 guide covers why a base score still needs device context.

Move to a supported branch where the product can take it, backport fixes where it cannot, and prove the result with a fresh scan.

Upgrade to a supported LTS. OpenSSL names 3.5 as the LTS supported until 2030-04-08, which covers most hardware support windows better than any older line. The OpenSSL release strategy guarantees API and ABI compatibility within a major version, so once the applications build against 3.x, later 3.5 patch releases drop in. Budget for the porting work on the applications, not only the library swap, and check the deprecated low-level APIs your vendor daemons use.

Backport where an upgrade is out of reach. For a branch past end of life, the options are OpenSSL's paid extended support, porting the upstream fix commit from a supported branch, or taking the patch a distribution already applied. Debian and Ubuntu trackers link the commits they used, which makes them a practical reference for a 1.1.1 backport. Note the patched revision in the package version or SBOM so the next scan and the next reviewer can see it.

Remove what the product does not use. OpenSSL's build configuration can leave out protocols and algorithms. A device that never uses DTLS, SSLv3 or legacy ciphers carries less code for future CVEs to land in; our weak cryptography in embedded firmware guide covers the algorithm side.

Rebuild, re-scan, publish. Rebuild every statically linked binary as well as the shared library, regenerate the SBOM, and compare it with the previous release to confirm that each copy changed. The SBOM diff tool compares two SBOM files, and our firmware diffing and patch analysis guide covers the binary view. The same inventory step applies to the other shared components in the image; see our BusyBox vulnerabilities in embedded Linux firmware guide for the shell and utilities side. Then publish the affected and fixed versions in your advisory.

SoftWSP's scan works from the firmware's software bill of materials. It identifies OpenSSL as a component with its version, normalises it to the NVD CPE for OpenSSL, strips OpenWrt-style package revision numbers so the upstream version can be matched, and matches that version against CVE records, CISA's KEV catalog and FIRST's EPSS scores. This part is deterministic code: the code scores, and AI narrates.

AI then writes the plain-language summary on top of that matching: which OpenSSL CVEs matched, which are KEV-listed or have a high EPSS score, and what the version evidence was. Every sentence cites the component, version and record it relies on, and an engineer reviews every finding before the report is delivered. The judgements this guide describes as manual stay with that engineer: whether a statically linked copy exists that the package records miss, whether a vendor or distribution backport closes a version-matched CVE, and whether a configuration makes a CVE unreachable. Because matching is version-based, a backported 1.1.1d-0+deb10u8 build is flagged for CVE-2022-0778; the review is where the Debian tracker evidence turns that flag into a documented not-affected decision.

For where this check fits in a full assessment, see the OWASP Firmware Security Testing Methodology guide, or device & firmware security services to have a specific image reviewed.

This guide draws on the OpenSSL project's release strategy, 1.1.1 end-of-life notice, vulnerability pages and OpenSSL_version(3) manual, the Debian and Ubuntu security trackers, NVD, CISA's KEV catalog (version 2026.11.09) and FIRST EPSS data dated 2026-11-09, all read directly on 2026-11-10.