SOCLYDE logo
Current languageEN
Cybersecurity newsCybersecurityopenssh

OpenSSH patch closes an Alpine login bypass

OpenSSH and Alpine fix a login bypass affecting some musl configurations. Update the correct package and restart sshd to apply the protection.

Published on

By Soclyde Team

An administrator checks a new connection while keeping a separate maintenance terminal open

In summary

  • OpenSSH 10.6p2 was released on November 5 to prevent an authentication bypass.
  • Exposure depends on musl, PAM, account state and password login settings.
  • On Alpine, check the patched package and restart the SSH daemon.

Explore next

Soclyde resources

Article contents

OpenSSH released portable version 10.6p2 on November 5, 2026 to prevent a login bypass on some Linux configurations using musl without PAM. Alpine has shipped patched packages. Small teams administering applications over SSH should identify exposed hosts and confirm that the running process has actually received the fix.

Check the combination of settings

Alpine lists password authentication enabled, an account with an asterisk in its password field, and another local account with a SHA-256 or SHA-512 password hash among the requirements. Under these conditions, access may be possible without knowing a password. This does not mean that every Linux installation or Alpine container is vulnerable.

Your SSH key does not describe the server

An administrator may always use a key while sshd still offers password authentication to other accounts. What matters is the effective server configuration. BleepingComputer explains the difference between an account without a password and a service that refuses password logins; The Hacker News examines the musl scope. Check Point’s published tests add that the other account used in the process must be active.

Update while preserving a working connection

Follow Alpine’s advisory for the installed branch, then restart sshd. Distribution packages can contain the fix without carrying the upstream 10.6p2 version number, so compare the full package version with the official list. If you temporarily disable password authentication, retain a maintenance session and first test a fresh authorised key login. Do not close your only working connection before completing that check.

Review login records as well

Alpine recommends reviewing accepted password logins for accounts that should not have passwords, doas activity, and changes to accounts or authorised keys. Keep two conclusions separate: the host is patched, and no intrusion has been identified. The first does not establish the second. If access remains uncertain, have the host examined before introducing replacement secrets.

A small business using Alpine still needs to organise hosting-console and recovery passwords even when SSH uses keys. Soclyde keeps those credentials in an encrypted vault on the user’s devices. It does not patch sshd or inspect logins. Where an intrusion is confirmed, access replacement must take place in the affected services.

Takeaway

Inventory Alpine hosts running sshd, inspect their configuration and retain evidence of the package update and daemon restart. Our password incident guide can help organise the account work that follows an incident.

Frequently asked questions

Is every Linux server affected?

No. The advisory concerns certain musl configurations without PAM, with password authentication enabled and the account conditions listed by Alpine.

Does normally using an SSH key make a host safe?

Not by itself. Your own use of a key does not prove that the server rejects password authentication. Check the effective sshd configuration.

Is a package update enough?

Alpine also requires restarting sshd. Replacing the package does not automatically replace the running daemon.

References

Sources and references

Need advice?

Design your password strategy with Soclyde

Schedule a dedicated walkthrough with the team to see how local-first security adapts to your stack.

Talk with us

Keep reading