Vulnerability Disclosure: wolfSSH (CVE-2026-81535)

Date: October 6, 2026
Severity: Medium
Affected Users: Applications built with –enable-fwd (port forwarding), wolfSSH versions 1.4.8 through 1.5.0.
Fixed In: wolfSSH v1.6.0 (PR 1059, 1148, 1220)

Summary

With forwarding enabled, wolfSSH admitted forwarded-tcpip channel opens without consulting the application’s forwarding policy callback, and a client accepted them for forwards it had never requested. A peer could cause an endpoint to allocate buffers for forwarding channels the application never authorized.

Background

SSH has two kinds of TCP forwarding channels. A direct-tcpip channel is opened by the client and asks the server to connect somewhere on its behalf. A forwarded-tcpip channel goes the other way: after a client sends a tcpip-forward request asking the server to listen on a port, the server opens a forwarded-tcpip channel to the client for each connection it accepts. RFC 4254 section 7.2 describes it as the answer to a forward the client asked for.

In wolfSSH the application controls forwarding through a callback, fwdCb. The library asks the callback before it sets up or admits a forwarding channel, which lets an application decide what is allowed.

The Vulnerability

Two checks were missing.

direct-tcpip opens were gated by the forwarding callback, but forwarded-tcpip opens were not. They were admitted without the callback being consulted, so the application’s policy was bypassed.
A client accepted a forwarded-tcpip open even when it had never sent a tcpip-forward request for the address and port named in it. A peer could send such opens unprompted.

Each admitted channel makes the endpoint allocate buffers. By opening forwarding channels the application had not authorized, a peer could make the endpoint spend memory on them.

The Fix

wolfSSH v1.6.0 closes both gaps in three changes:

PR 1059: forwarded-tcpip opens are gated like direct-tcpip opens. Both require a forwarding callback and are refused when none is set. A forwarded-tcpip open that arrives at a server is rejected as wrong-direction before any policy hook runs.
PR 1148: a client keeps a list of the forwards it registered with wolfSSH_FwdRemoteSetup() and refuses forwarded-tcpip opens that name anything else. A cancelled forward stops matching.
PR 1220: this matching applies to every client session, including one that has registered nothing, so such a client refuses all opens it has nothing to answer for.

A related hardening in this release has the client refuse tcpip-forward and cancel-tcpip-forward requests outright, and auth-agent@openssh.com channel opens it did not ask for.

Upgrade Notes

These fixes change behavior that applications may depend on:

An application that uses forwarding must now provide a fwdCb. Without one, forwarding channel opens are refused.
An application that tracks its own list of forwards, and sends tcpip-forward itself, can turn off the client’s matching with wolfSSH_SetFwdRemoteMatch(WOLFSSH_FWD_MATCH_OFF).

Recommendation

Update to wolfSSH v1.6.0 or later. Applications built without –enable-fwd are not affected.

Credit

Thank you to zhangph (GitHub afldl) for reporting this issue.

References

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now