OpenSSH for Windows CVE-2026-83769

Vendor-released patch: Microsoft has published fixed builds for every affected platform - Windows 11 24H2 to 10.0.26100.9711 or later, Windows 11 25H2 to 10.0.26200.9711 or later, Windows 11 26H2 to 10.0.26300.9711 or later, Windows 11 26H1 to 10.0.28000.3231 or later, Windows 11 23H2 to 10.0.22631.7652 or later, Windows 10 22H2 and 21H2 to 10.0.19044.7807 or later, Windows 10 1809 and Windows Server 2019 (including Server Core) to 10.0.17763.9376 or later, Windows Server 2022 to 10.0.20348.5761 or later, and Windows Server 2025 (including Server Core) to 10.0.26100.33650 or later; apply these via Windows Update, WSUS or the Microsoft Update Catalog following the guidance at https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-83769, and prioritise multi-user and Remote Desktop-capable servers where local non-administrative accounts are common. Since exploitation requires a pre-existing low-privileged local account, the practical compensating controls are access-based rather than network-based: if OpenSSH for Windows is not operationally required, remove the OpenSSH Server optional feature or disable the sshd service (trade-off: loss of local/remote SSH-based management and automation on that host), and where it must remain, tighten who is permitted to log on locally by removing unnecessary users from the local Users group and the Remote Desktop Users group and enforcing the 'Deny log on locally' right for service and low-trust accounts (trade-off: may disrupt legitimate interactive workflows and must be tested before rollout). Running sshd under a dedicated least-privileged service account instead of a highly privileged context reduces the payoff of a successful elevation, though it can break host-key, authorized_keys and file-permission scenarios and requires validation. Finally, monitor Windows event logs and crash dumps for repeated sshd process terminations, which are consistent with either accidental or deliberate triggering of the use-after-free, and use that telemetry to spot post-compromise attempts; note that no public exploit code has been identified at the time of analysis, so these detections should be treated as proactive rather than response to known tooling.