CVE-2026-83540 is a high severity (CVSS 8.8) authentication flaw in the Windows port of wolfSSHd, in wolfSSH 1.4.15 through 1.5.0. A logon token from one connection is not released before the next, so a less privileged user can end up logged in as a more privileged one. wolfSSL lists the fix in 1.6.0.
What's affected
The record covers wolfSSH from 1.4.15, which introduced the Windows port of wolfSSHd, through 1.5.0. Only the Windows build of the server is affected. The record says non-Windows builds of wolfSSHd are not.
The wolfSSL vulnerabilities page I fetched agrees on the range and the High rating. It says the Windows server shared one authentication context, and its logon token, across concurrent connections. Both password and public key logins wrote the shared token. It lists the fix as released in 1.6.0, with the change in pull request 1163, and credits internal wolfSSL testing.
The record gives no fixed version. I took 1.6.0 from the wolfSSL page. That is one source for the fix version, so check the project's release notes when you plan the upgrade.
How to check if you're exposed
Identify whether you run the Windows build of wolfSSHd at all. Look for the wolfsshd service (the exact service name depends on how it was installed) in the Windows service list, or search for the executable on servers where someone may have installed it:
Get-Service | Where-Object Name -like "*wolfssh*"
Then find its version from the build you installed, or from the package or installer you used. Anything from 1.4.15 to 1.5.0 is affected. If you only use wolfSSH as a library on Linux or an embedded device, this particular issue does not apply to you.
Finally, ask who can log in. The record says a less privileged user with a valid account is the one who can force a login as a more privileged user, so the number of accounts with SSH access sets your exposure.
What to do now
- Upgrade the Windows wolfSSHd server to 1.6.0, the release wolfSSL lists as the fix.
- Until then, limit SSH access to the smallest set of accounts and networks you can, and disable password logins in favour of keys if your setup allows.
- Review the authentication logs for logins as privileged users that do not match the account that opened the connection.
- Restart the wolfSSHd service after upgrading and confirm the new version.
- If you embed wolfSSH in a product, ship the fixed version to your customers and note it in your release notes.
Why it matters
The record lists two weaknesses, improper authentication, CWE-287, and insufficient session expiration, CWE-613. The shared token was a resource that should have been tied to one connection and released when it ended. When it was reused for the next connection, the identity from the earlier login leaked into the next one.
Bugs like this are timing and state problems, not input problems, so they are hard to find with fuzzing and easy to miss in review. They matter most on servers where accounts have very different rights, which is why the vector rates confidentiality, integrity and availability impact as high. The record does not list this CVE as exploited in the wild.
Quick check
Does this affect wolfSSH on Linux?
No. The record says non-Windows builds of wolfSSHd are not affected.
What is the fixed version?
wolfSSL's vulnerabilities page lists 1.6.0. The record does not name a fixed version, so confirm it in the release notes.
Sources
Last reviewed: 18 October 2026.
