CVE-2026-81535: wolfSSH SSH client accepts unsolicited forwarded-tcpip channel opens without an authorization check
wolfSSH builds with forwarding enabled (--enable-fwd) through 1.5.0 admit forwarded-tcpip channel opens without an authorization check or a count limit, and clients do not match them against their registered forwards. A malicious SSH peer could drive unbounded buffer allocation or cause unrequested forwarding channels. The record shows an NVD base score of 9.1, no KEV listing, and three patch commits, and no confirmed exploitation appears in the sources consulted.
Overview
The record describes a missing authorization check (CWE-862) in wolfSSH builds with forwarding enabled (--enable-fwd) through 1.5.0. The forwarding policy callback in DoChannelOpen() in src/internal.c covers only direct-tcpip channel opens. Forwarded-tcpip opens are accepted without an authorization check and without a count limit. Clients are also affected, because they do not match incoming forwarded-tcpip opens against the forwards they registered.
Impact
- A malicious SSH peer may cause an endpoint to allocate per-channel buffers for forwarding channels the application never authorized. The record does not state an upper bound.
- A malicious server may open forwarding channels to addresses and ports the client never asked it to forward.
- NVD assigns a base score of 9.1 (critical) with a network vector, no privileges or user interaction required, and high confidentiality and integrity impact. wolfSSL lists a score of 6.3 under a newer CVSS revision.
- Real-world consequences depend on how an application uses forwarding (inference).
Affected products and versions
- The record lists two entries: one recorded as before 1.6.0, and one from 1.4.8 up to and including 1.5.0.
- The description names builds through 1.5.0 compiled with --enable-fwd as the vulnerable configuration.
- Behavior for versions before 1.4.8 is not clearly described in the record and remains unknown.
- That 1.6.0 is the fixed release is an inference from the before 1.6.0 range. The record does not state a fixed version explicitly.
Exploitation status
This CVE is not listed in the CISA KEV catalog in the record. No confirmed exploitation appears in the sources consulted. The EPSS probability is 0.00268 (percentile 0.17921, dated 2026-10-23). The SSVC exploitation value is none and automatable is no.
Remediation and mitigation
- Update wolfSSH to a release that includes the fixes. The record links three patch commits: commit 616eb681, commit 79a7f299 and commit e396a0a4.
- Where forwarding is not required, avoid builds with --enable-fwd until the library is updated (inference from the stated build condition).
- Review application-level forwarding policies and resource limits for forwarding channels while patching is pending.
Detection guidance
- Inventory wolfSSH deployments and check build configuration for --enable-fwd.
- Monitor for unusually high counts of forwarded channel opens and for steady memory growth on SSH endpoints.
- Where feasible, compare logged tcpip-forward registrations with channel opens to spot forwards that were never requested.
Limitations of the available information
- The record contains no vendor advisory text beyond the three commit references.
- The exact fixed version, the boundary for versions before 1.4.8, and the behavior of non-forwarding builds are not stated explicitly.
- No exploitation evidence is present in the sources consulted, so exposure in practice cannot be quantified from this record.
Frequently asked questions
Which wolfSSH builds are affected by CVE-2026-81535?
The description covers builds through 1.5.0 compiled with --enable-fwd. The record also lists a range before 1.6.0, and behavior for versions before 1.4.8 is not clearly described.
Is this vulnerability known to be exploited?
It is not listed in the CISA KEV catalog in the record, and no confirmed exploitation appears in the sources consulted.
What should administrators do now?
Update wolfSSH to a release that includes the patch commits linked in the record. If forwarding is not needed, avoid building with --enable-fwd until the update is applied.
This analysis was drafted with AI assistance from verified source data and automatically checked against it.