CVE-2026-81535 is a critical (9.1) authorization flaw in wolfSSH through 1.5.0 when built with the forwarding option. forwarded-tcpip channel opens skip the policy check that direct-tcpip opens get, and a client does not check them against its own requests. The record links fix commits, so update to a build that includes them.
What's affected
The record lists wolfSSH through 1.5.0, built with the enable-fwd configure option. Builds without forwarding enabled are outside the description.
The record links three fix commits in the wolfSSH repository. I could not confirm a numbered release that contains them from the pages I fetched, so check the wolfSSH release notes and changelog for the first release after 1.5.0 that lists the fix. If you build from source, you can also take the commits directly.
How to check if you're exposed
Find out whether you use wolfSSH at all. It is an embedded SSH library, so it often hides inside firmware and appliances. Look at your SBOMs, build files and vendor notices for wolfssh.
Then check the build. Look in your build configuration or logs for the forwarding option.
grep -ri "enable-fwd" config.log build/ 2>/dev/null
If forwarding was never enabled, this record does not apply to that build.
What to do now
- Find every product and firmware image that bundles wolfSSH, using SBOMs or a dependency scan.
- Check whether each build was configured with the forwarding option.
- Update to a wolfSSH release that includes the fix commits, after reading the release notes, or apply the three commits from the record.
- If you cannot update, rebuild without forwarding if you do not need it.
- Ask embedded vendors whether their firmware is affected, and for a fixed image.
Why it matters
The weaknesses are CWE-862, missing authorization, and CWE-863, incorrect authorization. The code checked policy for one kind of channel open but not for another. Two effects follow in the record. A malicious peer can make an endpoint allocate unbounded buffers for forwarding channels the application never allowed, and a malicious server can open forwarding channels to addresses and ports the client never asked for.
The second one matters for tools that use SSH to reach internal systems. RFC 4254 section 7.2 requires a client to check these opens, and the record says wolfSSH did not. It is not listed in CISA's KEV catalog.
Embedded libraries like wolfSSH are the hard part of this one. You may not have chosen it. A device vendor may have built it into firmware, and the forwarding option may have been enabled for a feature you never use. The practical work is discovery. An SBOM or a dependency inventory shows you which products contain it, and a vendor question tells you whether forwarding is compiled in.
The record describes two directions of abuse. On a server, a peer can open channels that policy never approved and push the endpoint to allocate unbounded buffers, which is a resource exhaustion problem. On a client, a malicious server can open forwarding channels to addresses and ports the client never requested. That second direction is the more interesting one for defenders, because it turns a trusted connection into a path to places the client's network can reach.
Because I could not confirm a numbered fixed release, the safe wording is this. Take a release that postdates 1.5.0 and that lists the fix in its notes, or apply the three commits the record links. Ask your vendor to say which.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Are default builds affected?
The record limits the issue to builds with the forwarding option enabled. Check your build flags before deciding.
Sources
- wolfSSH fix commit: gate forwarded-tcpip opens like direct-tcpip
- wolfSSH commit 79a7f29 referenced by the record
- wolfSSH commit e396a0a referenced by the record
Last reviewed: 19 October 2026.
