AI analysis
The Windows port of wolfSSHd fails to release the Windows logon token from one authenticated session before acquiring a token for the next connection when password or public-key authentication is used. A less-privileged user who already has a valid account on the server can use that leftover token so a later connection is logged on as a more privileged user. Impact is full compromise of the higher-privileged account's access (confidentiality, integrity, and availability) on that host. Only Windows builds of wolfSSHd from the initial Windows port in wolfSSH 1.4.15 through 1.5.0 are affected; non-Windows builds are not. It is not listed in CISA KEV and no public proof-of-concept is known.
What to do: Upgrade the Windows port of wolfSSHd to a wolfSSH release newer than 1.5.0 as soon as the vendor fix is available, and treat every Windows host running wolfSSHd 1.4.15 through 1.5.0 as affected. Until patched, restrict which local accounts may authenticate to wolfSSHd and review recent sessions for logons that do not match the connecting user. Non-Windows builds do not need this change.
Affected
| wolfSSL wolfSSHd (Windows port of wolfSSH) | 1.4.15 through 1.5.0 |
Estimated exposure
—No basis for an estimate.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
When password or public key authentication is used with the Windows port of wolfSSHd, the Windows logon token acquired for one authenticated connection is not released before a token is acquired for a subsequent connection, resulting in user login poisoning between connections. A less privileged user with a valid account on the server can exploit this to force a login as a more privileged user. The vulnerability was introduced with the initial Windows port of wolfSSHd in wolfSSH version 1.4.15 and affects all versions through 1.5.0. Non-Windows builds of wolfSSHd are not affected.