SSH Vulnerabilities and How to Protect against them

Published: January 2025. Updated: August 2026. Reviewed by Encryption Consulting’s SSH and Key Management team.

Secure Shell (SSH) is the protocol most organizations trust for remote administration, file transfer, and machine-to-machine automation. That trust makes SSH implementations a high-value target, and the protocol has a real, documented history of vulnerabilities, from unauthenticated remote code execution in the SSH daemon itself to protocol-level handshake downgrades that work against almost every client and server on the market. This article is a reference for the specific, verified SSH CVEs and protocol weaknesses security teams need to track, how severe each one actually is, and the patch-and-rotation workflow that keeps a fleet ahead of the next disclosure. It does not cover attacker techniques against a healthy SSH deployment (see our guide on securing SSH against attacks) or what to do once a key is already compromised (see our incident response guide for exposed SSH keys).

What Makes an SSH Vulnerability Critical?

An SSH vulnerability is critical when it lets an attacker execute code, bypass authentication, or downgrade the connection’s cryptographic guarantees without needing valid credentials first. Three factors decide how seriously a given CVE should be treated:

• Authentication requirement. A pre-authentication flaw, one an attacker can reach before proving any identity, is far more dangerous than a post-authentication bug, because it removes the credential barrier entirely. CVE-2024-6387 is pre-auth; that is the main reason its CVSS base score reached 8.1 despite a high attack-complexity rating.
• Reach. A bug in the OpenSSH server binary (sshd) can affect every server running that version. A bug in the protocol itself, like the Terrapin prefix-truncation weakness, can affect dozens of independent client and server codebases at once (OpenSSH, PuTTY, libssh, Paramiko, AsyncSSH, and others), because it is not a coding mistake in one implementation but a gap in how the SSH Binary Packet Protocol handles sequence numbers during rekeying.
• Exploit maturity. A CVE with public proof-of-concept code and confirmed in-the-wild exploitation, as regreSSHion had within weeks of disclosure, moves from “patch this quarter” to “patch this week” regardless of its CVSS score.

None of this replaces reading the actual advisory. CVSS scores describe a generic worst case; your actual exposure depends on which OpenSSH build you run, whether the vulnerable code path is reachable from your network, and how quickly you can apply the fix.

What Are the Most Significant Verified CVEs Affecting SSH Implementations?

The CVEs below are verified against the National Vulnerability Database (NVD), vendor advisories, or the original security research, not restated from memory. Each entry lists the CVE ID, its CVSS base score, the affected version range, and the fix.

CVE-2024-6387, regreSSHion (CVSS 8.1, HIGH)

A signal handler race condition in sshd (CWE-362/CWE-364) lets an unauthenticated remote attacker trigger memory corruption by failing authentication within a specific timing window, potentially achieving remote code execution as root. It is a regression of a vulnerability originally fixed in 2006 (CVE-2006-5051) that was reintroduced. Affected: OpenSSH 8.5p1 through 9.7p1. Fixed in: OpenSSH 9.8 (released July 1, 2024). CVSS vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.

CVE-2023-48795, the Terrapin attack (CVSS 5.9, MEDIUM)

A protocol-level weakness in how the SSH transport layer handles extension negotiation and sequence numbers during the handshake lets a man-in-the-middle attacker truncate specific handshake messages, downgrading or disabling negotiated security features (for example, forcing weaker keystroke-timing obfuscation) without either party detecting it. Because the flaw sits in the protocol’s Binary Packet Protocol behavior rather than one codebase, it affected OpenSSH before 9.6, PuTTY before 0.80, libssh before 0.10.6, Paramiko before 3.4.0, AsyncSSH before 2.14.2, Dropbear through 2022.83, and other implementations using ChaCha20-Poly1305 or CBC-with-Encrypt-then-MAC. CVSS vector: AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N.

CVE-2025-26465 (CVSS 6.8, MEDIUM)

An OpenSSH client bug affecting installations with VerifyHostKeyDNS enabled. An attacker positioned on the network can exhaust client memory to force an error condition, then exploit how the client mishandles that failure to have a forged host key accepted without a warning, enabling machine-in-the-middle interception of credentials and session data. Affected: OpenSSH 6.8p1 through 9.9p1. Fixed in: OpenSSH 9.9p2 (disclosed February 18, 2025).

CVE-2025-26466 (pre-authentication denial of service)

A companion flaw disclosed alongside CVE-2025-26465. Asymmetric resource consumption, a small client request forces disproportionately large memory and CPU use on the server, lets an attacker degrade or crash sshd before authenticating. Affected: OpenSSH 9.5p1 through 9.9p1. Fixed in: OpenSSH 9.9p2.

CVE-2021-28041 (CVSS 7.1, HIGH)

A double-free bug in ssh-agent (CWE-415), relevant when agent forwarding reaches an attacker-controlled host or on systems with unconstrained agent-socket access. Affected: OpenSSH 8.2 through 8.4. Fixed in: OpenSSH 8.5 (published March 5, 2021). CVSS vector: AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H.

CVE-2020-14145 (CVSS 5.9, MEDIUM)

An observable discrepancy in how the OpenSSH client negotiates algorithms leaks enough timing information for a man-in-the-middle to infer parts of a prior, successfully established connection, information that can support a targeted downgrade attempt against later connections. Affected: OpenSSH client versions 5.7 through 8.4.

CVE-2018-15473 (CVSS 5.3, MEDIUM)

A username enumeration flaw in auth2-gss.c, auth2-hostbased.c, and auth2-pubkey.c: sshd fails faster for an invalid username than for a valid one, letting an attacker build a list of real accounts to target with credential attacks. Affected: OpenSSH through 7.7. Fixed in: OpenSSH 7.8 (published August 17, 2018).

CVE-2016-0777 / CVE-2016-0778 (client information disclosure)

A flaw in the OpenSSH client’s roaming feature, enabled by default since OpenSSH 5.4, that a malicious or compromised server could exploit to read parts of the client’s memory, including private key material, after authentication. Red Hat rated the impact Moderate. Fixed by disabling roaming by default in OpenSSH 6.6 and later; administrators on older builds can mitigate immediately by setting UseRoaming no in the client configuration.

Which Weak Algorithms and Cipher Configurations Create SSH Vulnerabilities?

Not every SSH vulnerability needs a patch to fix; some only need a configuration change, because the weakness is in an algorithm choice the protocol still permits for backward compatibility. Three deserve specific attention:

• CBC-mode ciphers (CVE-2008-5161). SSH implementations that still offer CBC-mode ciphers are subject to a documented plaintext-recovery attack against the block cipher chaining. The fix is not a software patch; it is removing CBC ciphers such as aes256-cbc from the server’s allowed Ciphers list in favor of AEAD or CTR-mode alternatives.
• ssh-rsa with SHA-1 signatures. OpenSSH disabled the ssh-rsa public key signature algorithm (which relies on SHA-1) by default starting in OpenSSH 8.8, released September 26, 2021, because SHA-1 collision attacks had become practical enough to undermine the signature’s integrity guarantee. RSA keys themselves are not broken; the SHA-1-based signature scheme around them is. Servers and clients that re-enabled ssh-rsa for compatibility should track which systems still need it and migrate them to rsa-sha2-256 or rsa-sha2-512.
• The Terrapin downgrade class (CVE-2023-48795). Beyond the single CVE, Terrapin demonstrated a broader lesson: even correctly implemented AEAD ciphers can be undermined by handshake-layer weaknesses that let an attacker strip negotiated protections before either side confirms them. Current OpenSSH versions add a strict key exchange mode that closes this gap; verify it is active rather than assuming an update alone is sufficient.

A quick way to check current exposure is ssh -Q cipher and ssh -Q key-sig against a running OpenSSH build, or an audit pass with ssh-audit, which flags deprecated ciphers, MACs, and key exchange algorithms directly against current guidance.

Who Owns SSH Vulnerability Patch Management in the Lifecycle?

SSH patch management fails most often because ownership is assumed rather than assigned. A working model splits the responsibility three ways:

• Platform or infrastructure team owns the OpenSSH package version on every host and is accountable for applying the patch within the agreed SLA once a fix ships.
• Security team owns advisory monitoring, severity triage, and the SLA itself, deciding whether a given CVE gets a 24-hour, 7-day, or 30-day remediation window based on exploitability and exposure.
• Application or service owners own anything that embeds an SSH library directly (a CI/CD agent using Paramiko, a custom tool linking libssh) rather than relying on the OS package, since those are easy to miss in an OS-level patch sweep.

Without a named owner for each of these, a CVE like regreSSHion sits in an advisory feed for weeks while teams assume someone else is handling it. This ownership gap is the same one our comprehensive guide to SSH key lifecycle management addresses for keys themselves; patch ownership and key ownership should live with the same accountable team wherever possible.

When Should You Rotate SSH Keys After a Vulnerability Disclosure?

Patching the software is not always enough; some disclosures mean the keys themselves need to be treated as potentially exposed. Rotate immediately, not on the next scheduled cycle, when any of the following apply:

• The vulnerability is a client-side memory disclosure bug (like CVE-2016-0777) where private key material could have been read from an affected client’s memory.
• A host key was accepted from an attacker under a machine-in-the-middle flaw such as CVE-2025-26465, since the client may have authenticated against, and disclosed information to, an impersonated server.
• ssh-agent forwarding was active on a host affected by an agent-compromise bug like CVE-2021-28041, since a compromised remote host could have manipulated the forwarded agent.
• A host running an unpatched, actively exploited pre-auth RCE, such as regreSSHion before patching, shows any sign of unauthorized access in its logs; rotate every key that host held or could reach.

Outside of an active disclosure, keys still need routine, non-emergency rotation triggers: personnel offboarding, contractor engagement end dates, and a fixed maximum key age. Our guide to mapping SSH key ownership covers how to know which keys exist and who is accountable for rotating them before a disclosure forces the question.

What Access Policy Reduces Exposure While a Patch Rolls Out?

Between the moment a CVE is disclosed and the moment every affected host is patched, access policy is the control that limits blast radius. Three measures matter most:

• Restrict source IPs. Firewall or security-group rules that limit SSH access (port 22 by default) to known administrative networks remove the exposure of a pre-auth vulnerability like regreSSHion to the entire internet while the patch is staged.
• Disable the vulnerable feature, not just wait for the patch. CVE-2025-26465 is only exploitable when VerifyHostKeyDNS is enabled; CVE-2016-0777 required SSH roaming. Turning off the specific feature is often faster than a fleet-wide package update and buys time without downtime.
• Enforce least privilege on the accounts SSH exposes. PermitRootLogin no and mandatory key-based authentication limit what an attacker gains even if a given host is briefly vulnerable, because the compromised session inherits a restricted account rather than root.

None of these replace patching. They exist to buy the time a real patch rollout across a large fleet actually takes.

How Do You Produce Audit Evidence for SSH Vulnerability Management?

An auditor or regulator reviewing SSH vulnerability management under a framework like PCI DSS, FIPS, or a SOC 2 control set will ask for proof, not a description of the process. Evidence to keep on hand includes:

• A dated inventory of OpenSSH (or other SSH implementation) versions across every host, tied to a source of truth rather than a spreadsheet someone updates manually.
• A record of when each tracked CVE was triaged, what SLA it was assigned, and the date it was actually remediated on each affected host, with the gap between disclosure and remediation visible.
• Configuration snapshots (or ssh-audit output) showing deprecated ciphers, MACs, and signature algorithms were disabled, not just that a version number changed.
• Key rotation logs tied to the specific disclosures that triggered them, showing rotation happened within a defined window of the trigger event described above.

Manual spreadsheets tend to fail this test under scrutiny because they cannot prove a negative, that no host was missed. A managed platform that logs every patch state, key rotation, and access change automatically produces this evidence as a byproduct of normal operation instead of a scramble before an audit.

What Is a Practical SSH Vulnerability Management Workflow?

A repeatable workflow turns the sections above into a process a team can actually run every week, not just during a fire drill:

1. Monitor advisories. Subscribe to the OpenSSH security page, your Linux distribution’s security list, and the NVD/CISA feeds for “openssh” and “SSH” so new CVEs reach the team the day they publish, not the day someone stumbles on a headline.
2. Triage severity against your environment. Score each CVE by CVSS, exploit maturity, and whether the vulnerable code path (a feature, a version range, a configuration flag) is actually present on your hosts. A 9.0 CVSS score in a feature you have disabled everywhere is lower priority than a 6.0 in a default configuration you run at scale.
3. Assign an SLA and an owner. Pre-auth RCE gets the shortest SLA (hours to days); a low-severity information disclosure requiring local access can go on the next maintenance window.
4. Patch and, where the trigger criteria above apply, rotate keys in the same change window. Patching without rotating leaves a client-side key-disclosure bug’s actual damage (a leaked key) unaddressed even after the software is fixed.
5. Verify the fix. Confirm the running version, not just the package manager’s reported version, actually rejects the vulnerable behavior, and re-run an ssh-audit pass to confirm no deprecated algorithm crept back in through a configuration management drift.
6. Record the evidence. Log the disclosure date, triage decision, patch date, and verification result in whatever system you would hand an auditor, ideally the same system automatically, not a follow-up task someone might skip.

Manual Patch Tracking vs. Automated Vulnerability Management: Which Scales?

The workflow above scales differently depending on whether it runs on spreadsheets or a platform built for it.

Capability	Manual / spreadsheet tracking	Automated vulnerability management platform
Host and version inventory	Point-in-time, goes stale between updates	Continuously discovered and current
Advisory-to-host mapping	Manual cross-reference against a CVE list	Automatic matching against the live inventory
SLA tracking	Relies on someone updating a tracker on time	Enforced with automated aging and escalation
Key rotation tied to disclosures	A separate, easily missed manual step	Triggered as part of the same remediation workflow
Audit evidence	Reconstructed under pressure before an audit	Generated continuously as a byproduct of operation
Scale ceiling	Breaks down past a few hundred hosts	Designed for thousands of hosts and keys

Manual tracking is not wrong for a small, static environment. It becomes a liability once host counts, cloud auto-scaling, and ephemeral CI/CD runners make the inventory itself a moving target, which describes most enterprise environments today.

What If an SSH Key Is Already Exposed?

Everything on this page is about preventing exploitation before it happens. If a key has already been exposed, either through a vulnerability like the ones above or through a leaked credential, the priority shifts to containment: identify every system the key can reach, revoke and rotate it, and determine what was accessed while it was live. That process, and how to run it under time pressure, is covered in full in our incident response guide for exposed SSH keys.

Decision Table: CVE, Severity, and Mitigation

CVE	CVSS	Affected versions	Primary mitigation
CVE-2024-6387 (regreSSHion)	8.1 HIGH	OpenSSH 8.5p1 to 9.7p1	Upgrade to OpenSSH 9.8+
CVE-2021-28041	7.1 HIGH	OpenSSH 8.2 to 8.4	Upgrade to OpenSSH 8.5+; restrict agent forwarding to trusted hosts
CVE-2025-26465	6.8 MEDIUM	OpenSSH 6.8p1 to 9.9p1 (client)	Upgrade to OpenSSH 9.9p2+; disable VerifyHostKeyDNS if not upgradable
CVE-2023-48795 (Terrapin)	5.9 MEDIUM	OpenSSH pre-9.6 and many other implementations	Upgrade affected client and server; confirm strict key exchange is active
CVE-2020-14145	5.9 MEDIUM	OpenSSH client 5.7 to 8.4	Upgrade client; avoid connecting through untrusted networks unpatched
CVE-2018-15473	5.3 MEDIUM	OpenSSH through 7.7	Upgrade to OpenSSH 7.8+
CVE-2008-5161	Not scored (algorithm weakness)	Any server offering CBC ciphers	Remove CBC ciphers from the server Ciphers list

Limitations

This reference has boundaries worth stating directly. New SSH CVEs are published on an ongoing basis; the list above reflects what was verified against NVD and vendor advisories as of this update and will age, which is why the “Updated” date at the top matters more than the publish date. CVSS scores describe generic severity, not your specific exposure; a 6.8 CVSS bug reachable from the open internet on a default configuration can matter more in practice than an 8.1 bug in a feature your organization never enables. This page also does not cover vulnerabilities in third-party SSH client or server implementations beyond OpenSSH in the same depth (Dropbear, PuTTY, libssh, and commercial SSH servers each maintain their own advisories worth tracking separately if you run them). Finally, patching and rotating keys addresses known, disclosed vulnerabilities; it does not protect against a zero-day that has not yet been published, which is why layered access controls matter regardless of patch status.

What Would Encryption Consulting Recommend?

Track SSH CVEs the same way you track any other critical infrastructure vulnerability class: with a named owner, a defined SLA by severity, and evidence you can hand an auditor without reconstructing it from memory. In practice, most organizations we work with lose control not at the patching step but at the inventory step, they cannot answer “which hosts run this vulnerable version” or “which keys does this host hold” fast enough when a CVE like regreSSHion drops.

Our SSH Secure platform closes that gap by discovering every SSH key and host across your environment continuously, mapping ownership so a disclosure has a named responder, and automating rotation the moment a defined trigger (including a vulnerability disclosure) fires, with a full audit trail generated automatically rather than assembled after the fact. Where the underlying question is “what does our SSH environment actually contain,” our encryption advisory services team runs the assessment and configuration review that vulnerability tracking depends on, mapped to FIPS, NIST, PCI DSS, and GDPR requirements where relevant.

Frequently Asked Questions

Is OpenSSH itself insecure?

No. OpenSSH is actively maintained, and its security team disclosed and patched every CVE covered on this page, most within a version or two of discovery. The risk in practice comes from unpatched deployments, not the project’s development process. Running a current, supported OpenSSH release and disabling deprecated algorithms addresses the overwhelming majority of known SSH vulnerabilities.

How fast should we patch a critical SSH CVE like regreSSHion?

For a pre-authentication, remotely exploitable flaw with public proof-of-concept code, treat it as an emergency change: internet-facing hosts within 24 to 48 hours, internal hosts within the same maintenance window if possible. Access-restriction controls (limiting source IPs, disabling the specific vulnerable feature) can reduce exposure immediately while the patch itself is staged and tested.

Does upgrading OpenSSH automatically fix weak algorithm configurations?

Not always. A version upgrade fixes coding-level bugs like regreSSHion, but a server can still be configured to allow deprecated ciphers, MACs, or the ssh-rsa SHA-1 signature scheme after the upgrade if the sshd_config was never updated. Pair every version upgrade with a configuration audit (ssh-audit is a practical tool for this) to confirm deprecated algorithms are actually disabled.

Do we need to rotate every SSH key after every CVE?

No. Rotate on the specific triggers described above, disclosures involving key material exposure, host key impersonation, or agent compromise, not reflexively on every advisory. Routine, non-emergency rotation should follow a scheduled cadence and offboarding triggers independent of the CVE calendar.

How is this different from your SSH hardening guide?

This page catalogs specific, verified vulnerabilities and CVEs and how to respond to each one. Our guide to securing SSH against attacks covers the broader set of attacker techniques (brute force, key theft, lateral movement) and the hardening controls that reduce SSH’s attack surface generally, whether or not a specific CVE is involved.

Conclusion

SSH vulnerabilities are not hypothetical. regreSSHion put unauthenticated remote code execution back on the table for any unpatched OpenSSH server running versions released between 2021 and 2024. Terrapin showed that even correctly implemented ciphers can be undermined at the handshake layer, across nearly every SSH implementation in use. Two more client-side flaws followed in 2025. The pattern is consistent: verified, disclosed, patchable, and repeatedly missed by organizations that treat SSH as a solved problem rather than infrastructure requiring the same vulnerability management discipline as anything else exposed to the network.

Close the gap with a named owner for patch management, a severity-based SLA, rotation triggers tied to actual disclosures, and evidence generated automatically rather than assembled during an audit. Pair that with the lifecycle ownership practices in our comprehensive SSH key lifecycle management guide and the hardening controls in our SSH attack-prevention guide, and SSH stops being the weak link it has repeatedly been in real breaches.

Please contact us at [email protected] if you want help auditing your SSH environment against these CVEs. We are here to help.

References

• NVD, CVE-2024-6387: nvd.nist.gov/vuln/detail/CVE-2024-6387
• NVD, CVE-2023-48795: nvd.nist.gov/vuln/detail/CVE-2023-48795
• NVD, CVE-2025-26465: nvd.nist.gov/vuln/detail/CVE-2025-26465
• Qualys Threat Research Unit, CVE-2025-26465 and CVE-2025-26466 analysis: blog.qualys.com
• NVD, CVE-2021-28041: nvd.nist.gov/vuln/detail/CVE-2021-28041
• NVD, CVE-2020-14145: nvd.nist.gov/vuln/detail/CVE-2020-14145
• NVD, CVE-2018-15473: nvd.nist.gov/vuln/detail/cve-2018-15473
• Red Hat, CVE-2016-0777 and CVE-2016-0778 advisory: access.redhat.com/articles/2123781
• Red Hat Bugzilla, CVE-2008-5161: bugzilla.redhat.com
• OpenSSH 8.8 release notes (ssh-rsa SHA-1 signature disabled by default): openssh.org/txt/release-8.8
• OpenSSH Security Advisories: openssh.org/security.html