The OpenSSH project released version 10.6p2 on 5 November 2026 to address a password-authentication bypass affecting some Linux systems built and run without Pluggable Authentication Modules. The project describes the change as a critical security workaround. The issue is narrowly conditional, but administrators should not dismiss it simply because it does not affect every Linux distribution or every SSH configuration. SSH is commonly exposed to the internet and often provides privileged access to servers, making accurate exposure checks important.
The flaw depends on musl and disabled PAM
The OpenSSH release notes state that the update avoids a password-authentication bypass exploitable through sshd on some Linux systems when the server is built and run with PAM support disabled. The project says the root cause is outside sshd but can be exploited through it and avoided there. The release was reported by researcher Özgün Kültekin. The project’s wording is precise: this is not a blanket statement that all OpenSSH installations are vulnerable, but a warning about a particular combination of build and authentication conditions.
Alpine confirms exposure in its non-PAM SSH package
Alpine Linux published a distribution-specific advisory on 5 November describing the affected package configurations. It says the standard openssh-server package is built without PAM, while the openssh-server-pam package is affected when UsePAM is set to no. The advisory lists Alpine releases 3.21 through 3.24 and edge among the checked affected releases, and older unsupported branches. This is useful operational guidance, but it should not be simplified into a claim that every Alpine host is exposed. The important questions are which C library the OpenSSH binary uses, whether PAM support is disabled in the build and whether password authentication is allowd in the server configuration. Custom builds, containers and appliances may differ from the default packages supplied by a distribution.
Alpine’s advisory describes additional conditions: password authentication must remain allowd, the system must contain an account with a locked-password marker of an asterisk, and at least one local account must have a SHA-256 or SHA-512 crypt password hash. A key-only account can meet the first account condition because it may have no password set. Alpine says systems with PasswordAuthentication no, or the PAM package running with UsePAM yes, are not affected under the stated conditions. These details matter more than the distribution name alone. Check package-manager security notices, distribution backports and build configuration before deciding whether a system is affected. A package may include a fix without changing the upstream version string, while a locally compiled daemon may not receive a vendor update automatically. Container images also need attention: rebuilding a base image does not update containers that continue running an older image layer.
OpenSSH is changing how it handles security fixes
Upgrade to OpenSSH 10.6p2 or the fixed package supplied by the operating-system vendor after checking the applicable advisory. If an immediate update is not possible and the affected configuration is present, the OpenSSH release notes and technical discussion identify disabling password authentication as a mitigation. That change can interrupt automation or users who depend on passwords, so verify that working key-based access and recovery access exist before applying it remotely.
The 10.6p2 notes also say the project has received a growing number of security reports produced by AI models or with AI assistance. OpenSSH says many reports do not have security impact when assessed against a realistic threat model, but it welcomes reports that include human triage, analysis, test cases and proposed fixes. The maintainers also say they have seen cases where an AI-identified bug was independently discovered by another researcher, and that they will make more frequent releases to provide fixes sooner.
Alpine published fixed package versions for supported and older branches, including 10.3_p1-r2 for 3.24, 10.2_p1-r1 for 3.23, 10.0_p1-r11 for 3.22 and 9.9_p2-r1 for 3.21. The distribution says administrators must restart sshd after upgrading because replacing the package does not replace the daemon already running in memory. Its advisory also recommends reviewing authentication logs for successful password logins to accounts that should not have passwords, including key-only users, and checking subsequent doas activity. This gives operators both a patch path and indicators to investigate possible access.