OpenSSH 10.6p2 Fixes Critical Password Bypass on Alpine and musl Linux: What to Do Now

On 5 November 2026 the OpenSSH project released Portable OpenSSH 10.6p2. Its release notes say it contains "a critical security workaround that affects Linux systems that use the musl libc and PAM disabled." The bug lets an attacker get past password authentication in sshd, the OpenSSH server, on those systems. The same day, Alpine Linux published a security advisory confirming that its standard openssh-server package is affected. Alpine has shipped fixed packages for every release back to 3.16.

Alpine's description is blunt: "An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries." The bug only applies when specific conditions are met, which are listed below. But a lot of infrastructure runs Alpine, including appliances, cloud images, jump hosts and small services, so it's worth checking your own estate and your suppliers' today.

The bug was reported by Özgün Kültekin of Wakefield. OpenSSH says it considers "the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there." OpenSSH developer Damien Miller, quoted by LWN and The Hacker News, told operators of affected systems to "set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY."

Rescana's assessment: Critical. That matches OpenSSH's own "critical security workaround" label and Alpine's call to update now. Our card follows that OpenSSH wording.

Alpine and The Hacker News both noted that no CVE identifier had been assigned when they published. Afterwards MITRE published CVE-2026-123158. NVD lists the record as Received, with a Secondary CVSS 3.1 score of 8.1 (High) from MITRE (vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). That High band is MITRE's Secondary score, reported for reference. CVE-2026-123158 is not in CISA's Known Exploited Vulnerabilities catalog (catalogVersion 2026.11.04, checked 5 November 2026). The Hacker News reports that no attacks using the flaw have been seen. We are not aware of any public reports of exploitation.

Technical Information

When sshd is built without PAM (Pluggable Authentication Modules), it checks passwords itself. Alpine's advisory explains how. sshd hashes the password the user sent with the C library's crypt() function, then compares the result with the account's stored password field in /etc/shadow.

Two behaviors combine to cause the bypass:

1. Salt borrowing in sshd. Some accounts have a stored field that is too short to contain a salt (the random prefix of a hash). The most common case is a single *, which means no password is set. For these accounts sshd borrows the salt of another account on the machine, so that failed logins take a realistic amount of time. The Hacker News traces this to a July 2016 OpenSSH change that addressed CVE-2016-6210, a username-enumeration flaw.
2. musl's crypt() error value. For the $5$ (SHA-256) and $6$ (SHA-512) hash types, musl's crypt() refuses passwords longer than 256 bytes. When it refuses, it returns the string * to signal the error instead of returning NULL.

Put those together and the problem is clear. An attacker sends a password between 257 and 1,024 bytes long for an account whose stored field is *. sshd borrows a $5$ or $6$ salt from another account, and musl's crypt() rejects the long input and returns *. That * matches the stored *, so sshd accepts the login. The Hacker News notes that the 1,024-byte upper limit is sshd's own maximum password length.

Alpine lists the conditions that must all be true for a system to be exposed:

• It runs Alpine's openssh-server package, which is built without PAM, or it runs openssh-server-pam with UsePAM no.
• PasswordAuthentication is yes. That is the OpenSSH default unless you changed it.
• At least one account has * as its password field.
• At least one other local account has a $5$ or $6$ password hash.

The attacker also needs the name of an account with no password. Alpine stresses that "one user with a password is enough: it makes every account without one reachable."

According to Alpine, accounts with a * password field include:

• root, which has shipped as root:* in the base image since about Alpine 3.16. OpenSSH's default PermitRootLogin prohibit-password means root can only be reached directly if PermitRootLogin yes is set. That protection doesn't help if another reachable account can become root, for example through doas.
• Key-only users created with adduser without a password, or with usermod -p '*'.
• Users from a directory service through musl-nscd (nslcd, winbind, sssd), because they have no shadow entry.
• The alpine user in the official tiny-cloud images.

The tiny-cloud case deserves attention. Alpine says its official tiny-cloud images (the qcow2, VHD and AMI artifacts) from 3.18.11 through 3.24.3 ship an alpine user with a * password field and passwordless doas. They are safe on first boot. They become exploitable as soon as any $6$ hash exists on the machine, for example when an admin sets a console password or user-data adds a user with hashed_passwd. An attacker can then get a shell as alpine and use doas to become root.

OpenSSH 10.6p2 avoids the problem inside sshd. The Hacker News reports that the code change makes sshd refuse a match when the stored field is shorter than four characters. Alpine's stable-branch packages carry a patch for the same problem.

Affected Product Versions

OpenSSH (portable). OpenSSH 10.6p2, released 2026-11-05, contains the workaround. According to OpenSSH, the flaw affects Linux systems built and run with musl libc and PAM disabled. Damien Miller said, as quoted by LWN, that it "does not exist on non-Linux systems, Linux/glibc systems and Linux systems that use PAM for password authentication." If you build OpenSSH yourself on musl without PAM, move to 10.6p2. heise reported that on release day many other distributions and download mirrors were still offering 10.6p1.

Alpine Linux. Alpine says every release it checked is affected: 3.21 through 3.24 and edge, plus the older releases that no longer get regular updates (3.16 to 3.20). These are the fixed openssh package versions Alpine published:

Alpine point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fixed package. Alpine notes that 3.21 reached end of support on 2026-11-01, but it still published fixed packages for 3.21 and every release back to 3.16. Tiny-cloud images built from those point releases or later include the fix. Images from earlier point releases do not.

Other musl-based systems. The Hacker News reports that Kültekin's technical write-up names OpenWrt, Buildroot and Yocto as other musl-based systems to check. On OpenWrt, SSH runs on Dropbear by default, and Kültekin says Dropbear is not affected. On OpenWrt the flaw can only matter where an admin has installed the OpenSSH server. For Buildroot and Yocto, exposure depends on how each product was built: musl or glibc, OpenSSH or another SSH server, PAM on or off, and whether password login is enabled. That is exactly why you need to ask appliance and embedded suppliers directly.

Not affected, per Alpine and OpenSSH:

• Containers that don't run sshd. Alpine-based container images are not affected just because they are based on Alpine.
• Systems with PasswordAuthentication no.
• openssh-server-pam with UsePAM yes.
• Locked accounts with ! as the password field (user:!: in /etc/shadow).
• Systems where no account has a $-style password hash.
• Cloud images set up through cloud-init, which writes PasswordAuthentication no.
• Linux systems on glibc, systems that use PAM for password authentication, and non-Linux systems (Damien Miller, via LWN and The Hacker News).

Workaround and Mitigation

1. Update, then restart sshd (Alpine). Alpine's fix:

apk upgrade -U -a
rc-service sshd restart

Don't skip the restart. Alpine warns that "upgrading the package does not restart a running sshd," so the old daemon keeps running until you restart it. After the restart, check that the installed openssh package matches the fixed version for your branch in the table above.

2. Update OpenSSH (custom builds). If you build portable OpenSSH against musl without PAM, upgrade to 10.6p2 and restart sshd.

3. If you can't update yet, turn off password logins. Alpine and OpenSSH both say that setting PasswordAuthentication no closes the hole. Alpine's advice before you change anything: confirm that SSH key login works, and keep your current session open until a new login succeeds. Alpine publishes a set of commands for this. They write a drop-in file in /etc/ssh/sshd_config.d/, which Alpine's default config reads from 3.19 onward. They also change every PasswordAuthentication line in /etc/ssh/sshd_config to no, including lines inside Match blocks, add the setting at the top of the file, and save a backup. Finally they validate the config, restart sshd and print the result:

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
  /etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

The last command should print passwordauthentication no. Alpine's advisory also explains how to undo the change.

4. Reduce exposure while you work. If neither step above can happen right away, Miller's fallback is to disable SSH on affected systems. More generally, restricting who can reach port 22 shrinks the window: allowlists, a VPN or bastion, or a security group. That doesn't replace the fix.

5. Fix every running cloud instance, not just the image. For tiny-cloud instances started from images older than 3.21.10, 3.22.8, 3.23.8 or 3.24.4, Alpine says to update openssh or disable password authentication on every running instance. Rebuilding the image alone doesn't fix instances that are already running.

Indicators of Compromise

Neither OpenSSH nor Alpine has published network indicators, file hashes or attacker infrastructure. The Hacker News reports no known attacks. We have not added any indicators of our own. Alpine's hunting guidance:

• Look in /var/log/messages for sshd lines that read Accepted password for an account that has no password, such as alpine, root or any key-only user. On a correctly configured system these accounts should never log in with a password, so a match is a strong signal.
• On exposed machines, review doas use, recently created users, recently changed files and authorized_keys entries.
• Alpine's words: "If you cannot rule out a login, treat the machine as compromised."

Keep in mind that log retention on small Alpine hosts and appliances is often short. A missing log entry doesn't prove nobody logged in.

What to Do With Your Vendors Today

Most of your exposure to this bug probably sits outside your own servers. It's in the hosted services, managed appliances, network gear, IoT and embedded products, and vendor-run jump hosts that your critical suppliers operate on Alpine or other musl-based builds. Those systems are hard to see from outside, so ask directly. Send these three questions to your critical and internet-facing suppliers today:

1. Do you run any internet-facing or customer-reachable services or appliances with sshd on Alpine Linux or another musl-based, PAM-disabled build (for example Buildroot, Yocto or OpenWrt with OpenSSH installed) where password authentication is enabled? Ask them to include management interfaces and support or jump hosts, not only production services.
2. When will those systems run OpenSSH 10.6p2 or the fixed Alpine openssh package for their branch, and was sshd restarted afterwards? Ask for a date and the package version. "We updated" without a restart doesn't close the hole.
3. Until then, have you disabled password authentication (PasswordAuthentication no) or restricted SSH exposure on those systems? For appliances you manage yourself, ask whether the vendor supports disabling password SSH or blocking the management port without breaking support.

If a supplier confirms they were exposed, also ask whether they have checked logs for Accepted password for entries on password-less accounts, as Alpine recommends, and when they will tell you the result. A vendor who can't rule out a login should be handled as a potential incident under your contract's notification terms.

Keep a record of who answered, the fix date each vendor gave, and any interim control. Use CVE-2026-123158 to follow up with anyone who hasn't answered yet.

Need help working through suppliers running Alpine or musl-based appliances with exposed sshd? Our team can help you prioritize them and track their answers. Talk to an expert

Sources

• OpenSSH, Portable OpenSSH 10.6p2 release notes (also at openssh.com/releasenotes.html)
• Alpine Linux, Security advisory: openssh-server password authentication bypass (5 November 2026)
• The Hacker News, OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux
• LWN.net, OpenSSH musl/PAM-off password-authentication note (Damien Miller)
• heise online, OpenSSH and Alpine Linux warn of severe but niche bug
• NIST NVD, CVE-2026-123158
• Özgün Kültekin (Wakefield), technical write-up