Story · 3 sources · 3 articlesfirst Oct 7, 18:39 UTCupdated Oct 8, 11:10 UTC (2d ago)

wolfSSH 1.6.0 Fixes Five Flaws Including Critical MITM ECDSA Host-Key Bypass; Canada's Cyber Centre Urges Updates

highVulnerabilityimportance 63CVE-2026-16516 CVE-2026-83540 CVE-2026-84897 CVE-2026-81535 CVE-2026-83742 CVE-2023-48795

What's new: A GBHackers report (2026-10-08T11:10:31Z) added detail beyond the prior merge: CVSS scores for the top two flaws (CVE-2026-16516 at CVSS v4 9.0; CVE-2026-83540 at 7.7), the characterization of the Windows flaw as exploitable by a lower-privileged user, a one-byte description of the SFTP path overflow, and the attribution of the new strict-key-exchange default to mitigating Terrapin…

Merged summary · glm-5.3 · rewritten as coverage arrives

wolfSSL's wolfSSH 1.6.0 (released October 6, 2026) patches five vulnerabilities in versions through 1.5.0 — led by a critical man-in-the-middle host-key verification bypass (CVE-2026-16516, CVSS v4 9.0) — and Canada's Cyber Centre followed with advisory…

wolfSSL published wolfSSH 1.6.0 on October 6, 2026, fixing five vulnerabilities affecting versions through 1.5.0: one critical, one high, and three medium. The critical flaw, CVE-2026-16516 (CVSS v4 9.0 per GBHackers), allows an active man-in-the-middle attacker to replace the server's ECDSA host key with a key on a different curve so that signature checks succeed — but only when the application uses a weak or permissive public-key-checking callback, so not every client is exposed. The high-severity CVE-2026-83540 (CVSS 7.7 per GBHackers) affects Windows wolfSSHd 1.4.15 through 1.5.0, where shared logon tokens can let one authenticated — GBHackers characterizes it as lower-privileged — user take on another account's identity across concurrent sessions. The three medium fixes address unauthenticated Diffie-Hellman group-exchange CPU abuse (CVE-2026-84897), policy-bypass TCP forwarding (CVE-2026-81535), and an authenticated SFTP NUL overflow (CVE-2026-83742), which GBHackers describes as a one-byte SFTP path overflow. Version 1.6.0 also enables strict key exchange — GBHackers notes it is on by default and mitigates the Terrapin attack (CVE-2023-48795) — and requires 2048-bit minimum RSA user keys. On October 7, 2026, the Canadian Centre for Cyber Security issued advisory AV26-1016 covering wolfSSH versions before 1.6.0 and directing administrators to the 1.6.0 release; that bulletin names no CVE identifiers and gives no technical detail. No source reports active exploitation. The reports do not conflict — the Canadian bulletin is a general update advisory while Cyber Security News and GBHackers supply the underlying CVE detail, differing only in granularity (e.g., GBHackers adds CVSS scores and the Terrapin link).

wolfSSL released wolfSSH 1.6.0 on October 6, 2026, fixing five vulnerabilities affecting versions through 1.5.0: one critical, one high, and three medium.
CVE-2026-16516 (critical; CVSS v4 9.0 per GBHackers): a man-in-the-middle can swap the server's ECDSA host key to a different curve so signature checks succeed, but only if the application uses a weak public-key-checking callback.
CVE-2026-83540 (high; CVSS 7.7 per GBHackers): affects Windows wolfSSHd 1.4.15 through 1.5.0, where shared logon tokens can give one authenticated (lower-privileged per GBHackers) user another account's identity across concurrent sessions.
CVE-2026-84897: unauthenticated Diffie-Hellman group-exchange CPU abuse (medium).

VendorswolfSSL

ProductswolfSSH wolfSSHd

OrganizationswolfSSL Canadian Centre for Cyber Security

CountriesCanada

Coverage timelineoldest first · each row is one article

Oct 7, 18:39 UTC · 3d ago
Canadian Centre for Cyber Security· 30
wolfSSL security advisory (AV26-1016)
Canada's Cyber Centre warned that wolfSSH before 1.6.0 is vulnerable and urged administrators to update.
Oct 8, 10:23 UTC · 2d ago
Cyber Security News· 48
wolfSSH 1.6.0 Fixes 5 Security Flaws Including Critical MITM Host Key Verification Bypass
wolfSSL released wolfSSH 1.6.0, fixing five flaws including a critical SSH host-key verification bypass.
Oct 8, 11:10 UTC · 2d ago
GBHackers· 63
wolfSSH Patches 5 Security Vulnerabilities, Including Critical SSH Authentication Bypass

Vulnerabilities in this storyAll →

CVE-2023-487955.993%
The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks…
published Dec 18, 2023· openbsd openssh
CVE-2026-165169.0—
ECDSA host-key curve confusion in wolfSSH
published 3d ago· wolfSSL wolfSSH

CVE	Vulnerability	CVSS	EPSS	Affected	Exposure	Published
CVE-2023-48795	The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks… The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust. NVD description · AI analysis pending	5.9	93%	openbsd openssh openbsd putty openbsd filezilla client +1 more	—	Dec 18, 2023
CVE-2026-16516 +3 related CVEs CVE-2026-84897 CVE-2026-81535 CVE-2026-83742	ECDSA host-key curve confusion in wolfSSH wolfSSH does not verify that the ECDSA curve identifier in a KEXDH_REPLY host-key blob matches the algorithm negotiated during key exchange. In ParseECCPubKey() the blob algorithm string is turned into a curve via NameToId and wcPrimeForId without comparison to ssh->handshake->pubKeyId, and the RFC 5656 curve identifier is discarded with GetSkip(). An active network man-in-the-middle can substitute a host-key blob on a different ECDSA curve for which the attacker holds the private key, so signature verification succeeds and the client accepts the wrong host key. This affects wolfSSH clients whose public-key callback is lax, such as trust-on-first-use, an algorithm-name-only check, or a fingerprint of the already-parsed key; the advisory does not name versions. No public proof of concept is known and the issue is not in CISA KEV. Do: Apply the wolfSSL-published wolfSSH fix as soon as it is available for your build, and until then require a strict host-key check that binds the accepted key to the negotiated algorithm and curve rather than trusting the parsed blob alone. Do not rely on trust-on-first-use, algorithm-name-only callbacks, or fingerprints computed from the already-parsed key. Prefer a pinned known host key and treat any unexpected ECDSA curve change as a failed authentication.	9.0 group max	—	wolfSSL wolfSSH	—	3d ago
CVE-2026-83540	Login poisoning in Windows wolfSSHd (wolfSSH 1.4.15–1.5.0) The Windows port of wolfSSHd fails to release the Windows logon token from one authenticated session before acquiring a token for the next connection when password or public-key authentication is used. A less-privileged user who already has a valid account on the server can use that leftover token so a later connection is logged on as a more privileged user. Impact is full compromise of the higher-privileged account's access (confidentiality, integrity, and availability) on that host. Only Windows builds of wolfSSHd from the initial Windows port in wolfSSH 1.4.15 through 1.5.0 are affected; non-Windows builds are not. It is not listed in CISA KEV and no public proof-of-concept is known. Do: Upgrade the Windows port of wolfSSHd to a wolfSSH release newer than 1.5.0 as soon as the vendor fix is available, and treat every Windows host running wolfSSHd 1.4.15 through 1.5.0 as affected. Until patched, restrict which local accounts may authenticate to wolfSSHd and review recent sessions for logons that do not match the connecting user. Non-Windows builds do not need this change.	7.7	—	wolfSSL wolfSSHd (Windows port of wolfSSH) 1.4.15 through 1.5.0	—	3d ago

CVE

Vulnerability

CVSS

EPSS

Flags

Affected

Exposure

Published

CVE-2023-48795

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks…

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.

NVD description · AI analysis pending

5.9

93%

openbsd openssh
openbsd putty
openbsd filezilla client
+1 more

—

Dec 18, 2023

CVE-2026-16516

ECDSA host-key curve confusion in wolfSSH

wolfSSH does not verify that the ECDSA curve identifier in a KEXDH_REPLY host-key blob matches the algorithm negotiated during key exchange. In ParseECCPubKey() the blob algorithm string is turned into a curve via NameToId and wcPrimeForId without comparison to ssh->handshake->pubKeyId, and the RFC 5656 curve identifier is discarded with GetSkip(). An active network man-in-the-middle can substitute a host-key blob on a different ECDSA curve for which the attacker holds the private key, so signature verification succeeds and the client accepts the wrong host key. This affects wolfSSH clients whose public-key callback is lax, such as trust-on-first-use, an algorithm-name-only check, or a fingerprint of the already-parsed key; the advisory does not name versions. No public proof of concept is known and the issue is not in CISA KEV.

Do: Apply the wolfSSL-published wolfSSH fix as soon as it is available for your build, and until then require a strict host-key check that binds the accepted key to the negotiated algorithm and curve rather than trusting the parsed blob alone. Do not rely on trust-on-first-use, algorithm-name-only callbacks, or fingerprints computed from the already-parsed key. Prefer a pinned known host key and treat any unexpected ECDSA curve change as a failed authentication.

9.0

group max

—

wolfSSL wolfSSH

—

3d ago

CVE-2026-83540

The Windows port of wolfSSHd fails to release the Windows logon token from one authenticated session before acquiring a token for the next connection when password or public-key authentication is used. A less-privileged user who already has a valid account on the server can use that leftover token so a later connection is logged on as a more privileged user. Impact is full compromise of the higher-privileged account's access (confidentiality, integrity, and availability) on that host. Only Windows builds of wolfSSHd from the initial Windows port in wolfSSH 1.4.15 through 1.5.0 are affected; non-Windows builds are not. It is not listed in CISA KEV and no public proof-of-concept is known.

Do: Upgrade the Windows port of wolfSSHd to a wolfSSH release newer than 1.5.0 as soon as the vendor fix is available, and treat every Windows host running wolfSSHd 1.4.15 through 1.5.0 as affected. Until patched, restrict which local accounts may authenticate to wolfSSHd and review recent sessions for logons that do not match the connecting user. Non-Windows builds do not need this change.

7.7

—

wolfSSL wolfSSHd (Windows port of wolfSSH) 1.4.15 through 1.5.0

—

3d ago