wolfSSH does not validate that the ECDSA curve identifier in a KEXDH_REPLY host key blob matches the algorithm negotiated during key exchange. In ParseECCPubKey() (src/internal.c), the blob's algorithm string is used to derive the curve via NameToId/wcPrimeForId without checking against the negotiated ssh->handshake->pubKeyId, and the RFC 5656 curve identifier string is discarded via GetSkip() rather than compared. An active network man-in-the-middle attacker can substitute a host key blob containing a different ECDSA curve, causing the client to import the key on the wrong curve. Because the attacker controls the private key for the substituted curve, signature verification passes. Exploitation requires an active MitM position and a lax public key check callback (e.g., TOFU, algorithm-name-only check, or fingerprint match against the parsed key).

There are packages installed that are affected by multiple vulnerabilities referenced in the following CVEs:

  - wolfSSH does not validate that the ECDSA curve identifier in a KEXDH_REPLY host key blob matches the
    algorithm negotiated during key exchange. In ParseECCPubKey() (src/internal.c), the blob's algorithm
    string is used to derive the curve via NameToId/wcPrimeForId without checking against the negotiated
    ssh->handshake->pubKeyId, and the RFC 5656 curve identifier string is discarded via GetSkip() rather than
    compared. An active network man-in-the-middle attacker can substitute a host key blob containing a
    different ECDSA curve, causing the client to import the key on the wrong curve. Because the attacker
    controls the private key for the substituted curve, signature verification passes. Exploitation requires
    an active MitM position and a lax public key check callback (e.g., TOFU, algorithm-name-only check, or
    fingerprint match against the parsed key). (CVE-2026-16516)

  - In wolfSSH through 1.5.0 built with --enable-fwd, DoChannelOpen() in src/internal.c gates only direct-
    tcpip channel opens with the forwarding policy callback. forwarded-tcpip opens are admitted without an
    authorization check and are not capped in number, allowing a malicious SSH peer to make an endpoint
    allocate unbounded per-channel buffers for forwarding channels the application never authorized. A client
    also does not check a forwarded-tcpip open against the forwards it registered with a tcpip-forward
    request, as RFC 4254 section 7.2 requires, so a malicious server can open forwarding channels for
    addresses and ports the client never asked it to forward. (CVE-2026-81535)

  - When password or public key authentication is used with the Windows port of wolfSSHd, the Windows logon
    token acquired for one authenticated connection is not released before a token is acquired for a
    subsequent connection, resulting in user login poisoning between connections. A less privileged user with
    a valid account on the server can exploit this to force a login as a more privileged user. The
    vulnerability was introduced with the initial Windows port of wolfSSHd in wolfSSH version 1.4.15 and
    affects all versions through 1.5.0. Non-Windows builds of wolfSSHd are not affected. (CVE-2026-83540)

  - Unsigned integer underflow in wstrncat() in src/port.c in wolfSSL wolfSSH from v1.4.11 through v1.5.0 on
    non-Windows platforms allows an authenticated remote attacker to write one out-of-bounds null byte past
    the end of a stack buffer by sending a crafted SFTP path. wolfSSH_RealPath() in src/ssh.c appends each
    path component with a remaining-size bound (outSz - curSz) rather than the full destination size, so once
    the accumulated path reaches half the output buffer the size_t computation n - strlen(s1) - 1 wraps to
    near SIZE_MAX. The strncat() call is then effectively unbounded and copies the whole component; when that
    component exactly fills the remainder of the buffer, its terminating null is written one byte past the
    end. The caller's own length check keeps the copied data inside the buffer, so the overflow is limited to
    that single null byte, which may corrupt an adjacent stack value and crash the process. Applications that
    call the public wolfSSH_RealPath() with an output buffer smaller than the input path are additionally
    exposed to an unbounded copy, because the word32 expression outSz - segSz in that length check also wraps.
    (CVE-2026-83742)

  - src/internal.c in wolfSSL wolfSSH through 1.5.0 admits the server-to-client Diffie-Hellman group exchange
    messages SSH_MSG_KEX_DH_GEX_GROUP (31) and SSH_MSG_KEX_DH_GEX_REPLY (33) when a server receives them from
    an unauthenticated client. IsMessageAllowedServer() applies no direction check to the key exchange message
    range: when the peer is keying and no particular message is expected, which is the state a server is in
    for the whole window after it processes the client's KEXINIT because nothing sets handshake->expectMsgId
    there, the function falls out of its expectation branch without a verdict and reaches a numeric bound that
    admits every message id from 30 through 34. A client that negotiates diffie-hellman-group-exchange-sha256
    and then sends message 31 makes the server run the client-side handler DoKexDhGexGroup(), which validates
    the attacker-supplied group with two 8-round Miller-Rabin primality tests, one on p and one on (p-1)/2, on
    a value of up to 8192 bits. The handler then returns success: the server stores the attacker's prime and
    generator, generates a Diffie-Hellman key pair in the attacker's group, and sends the client-role message
    SSH_MSG_KEX_DH_GEX_INIT (32) back to the attacker. Published RFC 3526 safe primes are the worst-case input
    and cost the attacker nothing to obtain. The primality validation was added in 1.5.0; versions from 1.2.0
    through 1.4.22 admit the same message and enter the same client-role path without the primality cost.
    Message 33 is admitted as well, but on a server it is rejected before any cryptography because no public
    key check callback is registered, so it carries no comparable cost. Builds that define
    WOLFSSH_NO_DH_GEX_SHA256, which is implied by WOLFSSH_NO_DH or NO_SHA256, are unaffected. (CVE-2026-84897)

ID	Name	Product	Family	Type	Severity
473609	Alpine: multiple wolfssh packages: security update to 1.6.0-r0	Tenable Cloud Security	Alpine Linux Local Security Checks	Local	critical
473609	Alpine: multiple wolfssh packages: security update to 1.6.0-r0	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	Local	critical

Detections

Analytics

CVE-2026-16516

critical

Tenable Plugins

critical

critical