OpenSSH vulnerabilities in embedded firmware: find the version, rank the CVEs, patch or backport

OpenSSH ships on devices with the flash and RAM for a full SSH stack, such as larger routers, gateways, HMI panels and industrial PCs running embedded Linux. Vendors choose it for SFTP, certificate authentication, PAM, post-quantum key exchange and a familiar configuration file, which puts it on enterprise gateways, edge and IoT gateways built on Debian, Ubuntu Core or Alpine, and Yocto-based controllers. Smaller routers, cameras and constrained devices tend to ship Dropbear instead; our Dropbear SSH vulnerabilities guide covers that server, and some images carry both, Dropbear for the field console and OpenSSH for a management VLAN.

Embedded images almost always use Portable OpenSSH, the version that the OpenSSH project maintains for non-OpenBSD systems, with a "p" suffix in its version such as 10.6p2. That suffix matters for CVEs: regreSSHion only affects Portable OpenSSH, and the musl bypass only affects Linux builds. All three common build systems ship it. OpenWrt's packages feed offers it alongside Dropbear, and Buildroot and OpenEmbedded-Core both carry a recipe; our embedded Linux build systems and SBOM guide explains how those recipes end up in an SBOM.

Six CVEs cover most of what a firmware scan of an OpenSSH image turns up today. The project's security page lists each advisory with the affected versions, and its release notes carry the details. Scores below are NVD's unless marked; EPSS values are FIRST's for 2026-11-13, and KEV status is from CISA's catalog version 2026.11.13.

High EPSS on Terrapin and CVE-2023-38408 reflects how widely SSH is deployed, not how reachable either flaw is on a device. The last two rows only apply when the device itself runs ssh-agent with agent forwarding to untrusted hosts, or uses the ssh client with VerifyHostKeyDNS turned on, which is off by default.

The security page is not the whole record. As of 2026-11-14 its newest entry is dated 9 April 2025, while the release notes list security fixes in every release since, including GSSAPI credential handling and sftp path checks in 10.6 and an ssh-agent locking flaw in 10.5. The 10.6p2 notes also say the project will make more frequent releases for now, because bugs found with AI tools are often rediscovered independently, which suggests attackers can find them too. Read the release notes for every version between yours and the current one, 10.6p2.

The musl password bypass matters for firmware because its preconditions are the normal state of many embedded Linux images. Alpine Linux's advisory explains the root cause: without PAM, sshd hashes the attempted password with crypt() and compares it with the stored field, and musl's crypt() returns the string * as an error when the key is over 256 bytes, which is exactly what an account with no password stores. The advisory lists the conditions as password authentication enabled (the OpenSSH default), an account whose password field is *, and at least one other account with a $5$ or $6$ hash; the attacker then sends a password of 257 to 1024 bytes and gets in on the first try.

Firmware builds meet those conditions easily. musl is the default C library on OpenWrt and a common choice in Buildroot; our glibc, uClibc and musl guide covers how to tell which one an image uses. OpenWrt's openssh package builds its default openssh-server variant with --without-pam, with PAM only in the separate openssh-server-pam variant, and Buildroot's openssh.mk passes --without-pam unless Linux-PAM is selected. Key-only service accounts with a * password, next to one admin account with a $6$ hash, are a common layout.

The fix is one upstream commit that touches three files and rejects stored password fields shorter than four characters, so it backports cleanly to older releases; Alpine shipped it in packages back to 9.0p1. Setting PasswordAuthentication no also closes the hole. One NVD detail changes how scanners see it: the record's configuration pairs OpenSSH before 10.6p2 with Alpine Linux versions, so a tool that requires the platform match will not flag an OpenWrt or Buildroot image that is just as exposed.

How dangerous regreSSHion is on a device depends on the C library more than on the hardware. The Qualys advisory describes a race in sshd's SIGALRM handler, which runs when a client fails to log in within LoginGraceTime and calls functions such as syslog() that are not async-signal-safe. Qualys calls it a regression of CVE-2006-5051, introduced by an October 2020 commit that first shipped in 8.5p1, and lists three ranges: before 4.4p1 vulnerable unless patched, 4.4p1 to before 8.5p1 not vulnerable, and 8.5p1 to before 9.8p1 vulnerable again.

Qualys exploited it on glibc-based Linux, where syslog() calls malloc() and free(), and needed about 10,000 attempts, roughly 6 to 8 hours against Debian 12's 9.2p1 on i386. The advisory says it did not investigate other C libraries. OpenSSH's 9.8 release notes add that systems without ASLR "may potentially have an easier path to exploitation", which describes many 32-bit embedded targets. A glibc-based HMI or gateway on 8.5p1 to 9.7p1 is therefore the highest-risk case; a musl or uClibc build in the same range still carries the bug, but the Qualys exploit does not cover it.

If you cannot ship a fix at once, Qualys and OpenSSH both give LoginGraceTime 0 as a mitigation, at the cost of making it easier to tie up every MaxStartups slot. Distributions backported the patch instead of upgrading: the Debian tracker lists bookworm's fix as 1:9.2p1-2+deb12u3 (DSA-5724-1), while bullseye's 8.4p1 was never affected.

Terrapin is a protocol flaw, so it needs both a vulnerable mode and an attacker on the network path. The Terrapin paper site says the attack requires "MitM capabilities at the network layer" and a connection secured by ChaCha20-Poly1305 or CBC with Encrypt-then-MAC, and that it lets the attacker remove messages from the start of the secure channel, such as the extension negotiation message. OpenSSH's own assessment on its security page is that there is "no discernible impact on the integrity of SSH traffic" beyond deleting the message that enables some keystroke timing features.

OpenSSH 9.6 added the "strict kex" countermeasure, which only takes effect when both client and server support it. A device on 9.6 or later is protected against clients that also implement it; an older device, or a newer device talking to an old field-service client, is not. The Terrapin FAQ's workaround is to disable [email protected] and the [email protected] MACs and use AES-GCM, while warning that a client without the remaining algorithms can lose access.

NVD files OpenSSH CVEs under cpe:2.3:a:openbsd:openssh, and it encodes the portable release in the CPE update field: CVE-2023-38408's configuration lists 9.3 and 9.3:p1 as separate vulnerable entries. The build systems follow that scheme. Buildroot sets the CPE vendor to openbsd and splits 10.6p2 into version 10.6 and update p2, OpenWrt declares cpe:/a:openbsd:openssh, and the OpenEmbedded-Core recipe marks CVEs that only affect distribution patches, such as RHEL's FIPS changes, as not applicable with a CVE_STATUS line.

Two mismatches follow. The package name (openssh-server, openssh-client, openssh-sftp-server) differs from the NVD product, so an SBOM entry often carries no usable CPE unless a tool maps it. Version ranges also drift: NVD's regreSSHion configuration includes versions up to and including 9.8, which a parser that drops the p1 suffix reads as covering the fixed 9.8p1. Our firmware SBOM guide covers how to keep identifiers and versions consistent.

Most OpenSSH exposure on devices comes from configuration, and the defaults favour general-purpose servers, not appliances. The sshd_config manual gives PasswordAuthentication yes, KbdInteractiveAuthentication yes, PermitRootLogin prohibit-password and a LoginGraceTime of 120 seconds as defaults. A device baseline that key management can support looks like this:

# Keys only, no passwords, no root shell over SSH
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
AuthenticationMethods publickey
PermitRootLogin no

# Listen on the management interface only
ListenAddress 192.0.2.10

# Limit pre-authentication load (regreSSHion, CVE-2025-26466)
LoginGraceTime 30
MaxStartups 10:30:60
PerSourcePenalties yes

# No forwarding unless the product needs it
DisableForwarding yes

# Current algorithms only
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]

Adjust it to the version you ship. PerSourcePenalties exists from 9.8 and is on by default there; the mlkem768x25519-sha256 key exchange exists from 9.9 and became the client default in 10.0, so drop it on older builds. DisableForwarding did not disable X11 or agent forwarding in 7.4 to 9.9, so on those versions also set X11Forwarding no and AllowAgentForwarding no. Keep [email protected] only if the device and its clients support strict kex (9.6 and later). Check the result with sshd -t and sshd -T before shipping.

Configuration alone does not cover two common integration mistakes. Generate unique host keys on each device at first boot instead of shipping one key in the image, and never ship a shared factory password; our hard-coded credentials guide covers both. Our weak cryptography guide explains algorithm choice in more depth, and U-Boot bootloader security covers keeping the root file system, and sshd_config with it, from being edited offline.

SoftWSP's automated scan unpacks a firmware image, catalogs the software packages in the extracted file system with their versions (the inventory our firmware SBOM guide describes), and matches each one against CVE records, CISA's KEV catalog and FIRST's EPSS scores. On OpenWrt-style images the opkg package revision is stripped before matching. This is deterministic code: the code scores, and AI narrates. You can inspect the resulting CycloneDX file in the free SBOM viewer.

Version matching follows NVD's records and inherits their limits, which are significant for OpenSSH: a package named openssh-server has to be tied to NVD's OpenBSD OpenSSH entry, the p release suffix has to be read correctly, and CVE-2026-123158 depends on libc and PAM, which a version does not show. AI's part is the written explanation of what matched, citing the component, version and record behind each sentence. An engineer reviews every finding before the report is delivered, and that review is where the package-to-CPE mapping, the libc and PAM build, the effective sshd_config, the accounts in the image and any vendor or distribution backport become a documented "affected" or "fixed" decision.

For where SSH service review fits in a full assessment, see the OWASP Firmware Security Testing Methodology guide and our KEV and EPSS prioritisation guide, or device & firmware security services to have a specific image reviewed.

This guide draws on the OpenSSH security page, release notes and Portable OpenSSH page, the sshd_config manual, the Qualys advisories for CVE-2024-6387 and CVE-2025-26465/26466, the Terrapin paper site, Alpine Linux's 2026-11-05 advisory and the upstream fix commit, the Debian Security Tracker, the OpenWrt, Buildroot and OpenEmbedded-Core OpenSSH build files, NVD, CISA's KEV catalog (version 2026.11.13) and FIRST EPSS data dated 2026-11-13, all read directly on 2026-11-14.