CVE-2026-83540: wolfSSHd Windows Privilege Escalation Flaw

CVE-2026-83540 Overview

CVE-2026-83540 is an authentication flaw in the Windows port of wolfSSHd, the SSH daemon shipped with wolfSSL's wolfSSH library. The daemon fails to release the Windows logon token acquired for one authenticated SSH connection before acquiring a new token for a subsequent connection. This token reuse allows login poisoning between connections, letting a lower-privileged user with valid credentials be logged in under the identity of a more privileged account. The defect was introduced with the initial Windows port in wolfSSH 1.4.15 and affects all releases through 1.5.0. Non-Windows builds of wolfSSHd are not affected. The weakness is classified under [CWE-287] Improper Authentication.

Critical Impact
A less privileged authenticated user can force a session to log in as a more privileged user, resulting in full confidentiality, integrity, and availability compromise of the target account on the Windows host.

Affected Products

wolfSSH wolfSSHd Windows port, version 1.4.15
wolfSSH wolfSSHd Windows port, versions 1.4.16 through 1.5.0
Non-Windows wolfSSHd builds are not affected

Discovery Timeline

2026-10-07 - CVE-2026-83540 published to NVD
2026-10-07 - Last updated in NVD database

Technical Details for CVE-2026-83540

Vulnerability Analysis

The Windows port of wolfSSHd uses LogonUserExExW to obtain a Windows logon token after password or public key authentication succeeds. The token is stored in the WOLFSSHD_AUTH context structure and used for impersonation during the session. When a new connection authenticates against the same context path, the daemon acquires a new token without closing the previously held handle. The stale token can remain associated with the authentication context and be consumed by a subsequent connection, binding the new SSH session to the prior user's security context.

A less privileged user with a valid account on the server can time connections so that an administrator's token is still resident when their own authentication completes. The result is a session executing under the higher-privileged identity, defeating the per-connection authentication boundary expected from an SSH daemon.

Root Cause

The root cause is a missing resource release in the authentication code path in apps/wolfsshd/auth.c. The patch introduces a new wolfSSHD_AuthCloseToken helper that calls CloseHandle on the stored token and clears the pointer. The fix invokes this helper immediately before LogonUserExExW is called, guaranteeing that no prior token can persist across authentications. The underlying weakness is improper authentication state management ([CWE-287]).

Attack Vector

Exploitation requires network access to the SSH service and valid low-privileged credentials on the target Windows host. The attacker initiates an SSH connection shortly after, or concurrent with, a higher-privileged user's session. Because token acquisition races against release, the attacker's post-authentication session can inherit the privileged token stored in the shared authentication context. No user interaction from the victim is required beyond having previously authenticated.

// Patch: close any prior token before acquiring a new one
// Source: https://github.com/wolfSSL/wolfssh/commit/9777bc5ce810d6c418a1473e9e8c40cdb0026e5a
     }
 
     if (ret == WSSHD_AUTH_SUCCESS) {
+        /* Close any prior token before acquiring a new one. */
+        wolfSSHD_AuthCloseToken(authCtx);
+
         if (LogonUserExExW(usrW, dmW, pwW, LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, NULL,
             &authCtx->token, NULL, NULL, NULL, NULL) != TRUE) {
             wolfSSH_Log(WS_LOG_ERROR, "[SSHD] Windows failed with error %d when login in as user %s, "

// Patch: new helper to close and clear the impersonation token
// Source: https://github.com/wolfSSL/wolfssh/commit/b6bd975ccfac6aadf29b98e35e09114bef3840a9
     return auth->token;
 }
 
+/* Close and clear the impersonation token. Safe to call more than once. */
+void wolfSSHD_AuthCloseToken(WOLFSSHD_AUTH* auth)
+{
+    if (auth != NULL && auth->token != NULL &&
+            auth->token != INVALID_HANDLE_VALUE) {
+        CloseHandle(auth->token);
+        auth->token = NULL;
+    }
+}
+
 static int CheckPasswordWIN(const char* usr, const byte* pw, word32 pwSz, WOLFSSHD_AUTH* authCtx)

Detection Methods for CVE-2026-83540

Indicators of Compromise

Windows Security event ID 4624 (successful logon) entries triggered by the wolfsshd process that do not match the SSH authentication username recorded in the daemon logs.
SSH session activity under a privileged account with no corresponding interactive or network logon from that user's workstation.
Rapid, overlapping successful authentications to wolfSSHd from distinct source addresses against different user accounts within a short window.

Detection Strategies

Correlate wolfSSHd application logs (authenticated username and source IP) with Windows Security logon events to identify mismatches between the SSH-authenticated principal and the token used for process execution.
Monitor child processes spawned by wolfsshd.exe and flag cases where the process owner differs from the user that completed SSH authentication.
Baseline per-user SSH session concurrency and alert when a low-privileged user's connection coincides with privileged-account process execution under the daemon.

Monitoring Recommendations

Enable Windows auditing for logon events (4624/4625) and process creation (4688) with command-line logging on hosts running wolfSSHd.
Forward wolfSSHd logs and Windows event logs to a central analytics platform for cross-source correlation.
Track the installed wolfSSH version across Windows fleet inventory and alert on hosts running versions 1.4.15 through 1.5.0.

How to Mitigate CVE-2026-83540

Immediate Actions Required

Upgrade wolfSSHd on Windows to a release containing commits 9777bc5 and b6bd975 (post-1.5.0 fixed build).
Restrict SSH access to the daemon with network ACLs so only trusted administrative workstations can reach the service while patching is in progress.
Audit recent SSH session activity on affected hosts for signs of unexpected privileged logons.

Patch Information

The fix is implemented across two commits in the wolfSSH repository. Commit b6bd975 introduces the wolfSSHD_AuthCloseToken helper in apps/wolfsshd/auth.c and its declaration in apps/wolfsshd/auth.h. Commit 9777bc5 invokes the helper before LogonUserExExW to ensure any prior token is released. See the wolfSSL Security Vulnerabilities page and the wolfSSH GitHub repository for the fixed release.

Workarounds

Disable the Windows build of wolfSSHd and route administrative SSH access through an unaffected SSH daemon until the patch is applied.
Limit accounts permitted to authenticate to wolfSSHd to a single privilege tier so cross-privilege token poisoning cannot occur.
Enforce single-session usage by stopping and restarting the wolfSSHd service between authenticated sessions where operationally feasible.

bash

# Verify installed wolfSSH version on a Windows host
wolfsshd.exe -V

# Example: restrict inbound SSH to administrative subnet via Windows Firewall
netsh advfirewall firewall add rule name="wolfSSHd-Restrict" ^
    dir=in action=allow protocol=TCP localport=22 ^
    remoteip=10.0.0.0/24 program="C:\Program Files\wolfSSH\wolfsshd.exe"