Date: October 6, 2026
Severity: High
Affected Users: Operators of wolfSSHd on Windows, wolfSSH versions 1.4.15 through 1.5.0. Non-Windows builds are not affected.
Fixed In: wolfSSH v1.6.0 (PR 1163)
Summary
On Windows, wolfSSHd used a single authentication context, and the logon token stored in it, for every concurrent connection. A user with a valid account could end up logged in as a different, more privileged user.
Background
wolfSSHd authenticates a user, obtains a Windows logon token for that user, and later uses the token to start the user’s shell or SFTP session with that user’s permissions. The token is what determines who the session acts as, so it must belong to exactly one connection and exactly one authenticated user.
On POSIX systems wolfSSHd forks a child process for each connection, and each child has its own copy of its state. On Windows, wolfSSHd handles each connection in a thread of one process, so state is shared unless it is explicitly made per-connection.
The Vulnerability
The Windows build of wolfSSHd created one authentication context at startup and passed the same context to every connection thread. Both password logins and public key logins stored the resulting Windows logon token in that shared context.
With two connections in flight, a login on one connection could overwrite the token that another connection had stored. The second connection’s session then started with a token that belonged to someone else. If that other user had more privileges, the session ran with them. Exploiting this does not require an attacker to guess anything about another user’s credentials: the attacker needs only a valid account of their own and a connection that overlaps in time with a login by a more privileged user.
The same sharing also meant a token left over from an earlier login was overwritten without being closed.
The Fix
wolfSSH v1.6.0 gives each connection its own authentication context on Windows:
- wolfSSHd allocates a new context for every accepted connection, and frees it when the connection ends.
- A prior token is closed before a new one is acquired, in both the password and the public key paths.
- Token cleanup goes through one helper, which closes the handle and clears the field, so a handle is never closed twice or left dangling.
These changes shipped in PR 1163.
Recommendation
If you run wolfSSHd on Windows, update to wolfSSH v1.6.0 or later. Systems running wolfSSHd on Linux, macOS, BSD or QNX are not affected.
Credit
This issue was found during internal wolfSSL testing.
References
wolfSSH PR 1163
wolfSSH v1.6.0 release
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