CVE-2026-81535: wolfSSH Privilege Escalation Vulnerability

CVE-2026-81535 Overview

CVE-2026-81535 affects wolfSSH through version 1.5.0 when built with the --enable-fwd option. The DoChannelOpen() function in src/internal.c applies the forwarding policy callback only to direct-tcpip channel opens. forwarded-tcpip opens are admitted without any authorization check and are not capped in number. A malicious SSH peer can force an endpoint to allocate unbounded per-channel buffers for forwarding channels the application never authorized. A client also fails to match a forwarded-tcpip open against the forwards it registered through a tcpip-forward request, violating RFC 4254 section 7.2. This classifies as a Missing Authorization weakness [CWE-862].

Critical Impact
A malicious SSH server can open forwarding channels for arbitrary addresses and ports a client never requested, and either peer can exhaust memory on the other through unbounded channel allocation.

Affected Products

wolfSSL wolfSSH through version 1.5.0
Builds compiled with the --enable-fwd option
Both client and server SSH endpoints using wolfSSH forwarding

Discovery Timeline

2026-10-07 - CVE-2026-81535 published to NVD
2026-10-07 - Last updated in NVD database

Technical Details for CVE-2026-81535

Vulnerability Analysis

The flaw sits in how wolfSSH handles SSH channel opens for TCP/IP forwarding. SSH defines two forwarding channel types: direct-tcpip for client-requested forwards and forwarded-tcpip for channels initiated in response to a prior tcpip-forward global request. DoChannelOpen() enforces the forwarding policy callback and application authorization only on direct-tcpip opens. forwarded-tcpip opens bypass that gate entirely.

Two distinct consequences follow. First, neither direction limits the number of accepted forwarding channels, so a peer can repeatedly open channels and force per-channel buffer allocations without bound. Second, a client does not cross-check an incoming forwarded-tcpip open against the bind addresses and ports it registered with wolfSSH_FwdRemoteSetup(). A malicious server can therefore open forwarded channels naming addresses and ports the client never asked it to listen on.

Root Cause

The root cause is a missing authorization check. The code path treated forwarded-tcpip opens as implicitly trusted and skipped both the policy callback and the RFC 4254 section 7.2 requirement to match the open against a registered remote forward. There is also no direction check: a server should never receive a forwarded-tcpip open, but the original code accepted them.

Attack Vector

Exploitation requires an authenticated SSH session between the victim endpoint and a malicious peer. The attacker sends SSH_MSG_CHANNEL_OPEN messages with the forwarded-tcpip channel type. Each accepted open causes the victim to allocate channel state and per-channel buffers that the application layer never sanctioned.

         else {
             ChannelUpdatePeer(newChannel, peerChannelId,
                           peerInitialWindowSz, peerMaxPacketSz);
-            if (ssh->ctx->channelOpenCb) {
-                ret = ssh->ctx->channelOpenCb(newChannel, ssh->channelOpenCtx);
+        #ifdef WOLFSSH_FWD
+            /* A forwarded-tcpip open is a server-to-client message sent in
+             * response to a tcpip-forward request, so only a client should
+             * ever receive one. Reject opens arriving in the wrong direction
+             * up front, before any policy callback runs or channel state is
+             * updated. direct-tcpip is intentionally not direction-checked:
+             * either forwarding side may legitimately request a direct
+             * forward. */
+            if (typeId == ID_CHANTYPE_TCPIP_FORWARD &&
+                    ssh->ctx->side == WOLFSSH_ENDPOINT_SERVER) {
+                WLOG(WS_LOG_WARN, "Rejecting forwarded-tcpip channel open "
+                        "received by a server (wrong direction)");
+                fail_reason = OPEN_ADMINISTRATIVELY_PROHIBITED;
+                ret = WS_ERROR;
             }
+        #endif /* WOLFSSH_FWD */
+            if (ret == WS_SUCCESS) {
+                if (ssh->ctx->channelOpenCb) {
+                    ret = ssh->ctx->channelOpenCb(newChannel,
+                            ssh->channelOpenCtx);

Source: wolfSSH commit 616eb681. The patch rejects wrong-direction opens and routes every forwarding open through the policy callback.

Detection Methods for CVE-2026-81535

Indicators of Compromise

Unexpected growth in SSH process memory tied to wolfSSH-based clients or servers handling forwarding.
SSH debug logs showing repeated forwarded-tcpip channel opens without a prior application wolfSSH_FwdRemoteSetup() call.
Inbound forwarded-tcpip channels naming bind addresses or ports that the client never registered.

Detection Strategies

Audit builds for the --enable-fwd compile option and inventory applications linking wolfSSH at or below version 1.5.0.
Instrument the channelOpenCb callback (where set) to log and count channel open attempts per session, flagging anomalous rates.
Compare incoming forwarded channel bind targets against the application's registered forwards and alert on mismatches.

Monitoring Recommendations

Track per-session channel counts and per-channel memory allocation for long-lived SSH connections.
Alert on SSH sessions where channel open rates exceed normal operational baselines.
Capture packet metadata for SSH control traffic to retain evidence of forwarding abuse for forensic review.

How to Mitigate CVE-2026-81535

Immediate Actions Required

Upgrade wolfSSH past version 1.5.0 once a release incorporating the referenced commits is available.
Apply the upstream commits directly to vendored copies of wolfSSH if a tagged release is not yet published.
Disable the --enable-fwd build option in deployments that do not require TCP/IP forwarding.

Patch Information

Three upstream commits address the vulnerability: commit 616eb681 gates forwarded-tcpip opens through the policy callback and rejects wrong-direction opens; commit 79a7f299 ensures forwarded opens are matched on every client session rather than only after the first registration; commit e396a0a4 introduces the WOLFSSH_FWD_REMOTE tracking structure so inbound opens can be matched to registered forwards per RFC 4254 section 7.2.

Workarounds

Register a channelOpenCb with wolfSSH_CTX_SetChannelOpenCb() that rejects any forwarded-tcpip open the application did not authorize.
Restrict SSH peering to trusted hosts via network segmentation, firewalls, and host-based ACLs until patches are deployed.
Enforce resource limits on SSH processes (for example, cgroup memory caps) to contain channel allocation abuse.

bash

# Rebuild wolfSSH without forwarding support when not required
./configure --disable-fwd
make && sudo make install

# Verify the resulting binary does not advertise WOLFSSH_FWD
nm /usr/local/lib/libwolfssh.so | grep -i fwd || echo "Forwarding symbols absent"