Posts

Securing Alpaquita Linux against the SSHole OpenSSH bypass

Updated

Pasha Finkelshteyn

8

TLDR

  • CVE-2026-123158 can bypass OpenSSH password authentication on certain Linux systems that use musl libc without PAM. Exploitation requires a specific combination of SSH settings, shadow entries, and an oversized password.
  • BellSoft published fixed OpenSSH packages for every supported Alpaquita Linux branch within one day of disclosure: 10.6_p2-r0 for Stream and 25 LTS, and the backported 9.1_p1-r17 for 23 LTS.
  • The current Alpaquita Stream repository already provides the non-vulnerable OpenSSH 10.6_p2-r0. Systems must update the package and restart sshd to replace the running daemon.
  • Note that our pre-built Alpaquita Linux base container images do not include the sshd daemon by default. Since this vulnerability specifically targets the OpenSSH server, our containers are not affected out of the box. This is why no emergency updates were required for our container images.

What happened

OpenSSH 10.6p2, released on November 5, 2026, addresses a password-authentication bypass on Linux systems using musl libc with PAM disabled. The vulnerability is tracked as CVE-2026-123158 and is commonly known as SSHole. The NVD entry assigns it a CVSS 3.1 base score of 8.1, or High: the attack is network-accessible and requires no prior privileges or user interaction, but exploitation depends on a specific system and account configuration.

Without PAM, sshd can verify a password by calling crypt() and comparing the returned string with the value stored for the account in /etc/shadow. When a supplied password exceeds musl's supported length, musl's crypt() can return the single-character string * as an error indicator.

The vulnerable condition occurs when the target account's password field also contains a solitary *. OpenSSH may compare the two identical strings and treat the authentication attempt as successful, even though crypt() returned an error and the account was intended to have no usable password.

The attacker does not need to discover the account password. A sufficiently long password can produce the value already stored in the shadow entry.

Conditions required for exploitation

This vulnerability does not affect every OpenSSH installation. The vulnerable path requires all of the following conditions:

  • The system uses musl libc, and OpenSSH performs password verification without PAM, for example with UsePAM no.
  • PasswordAuthentication yes is effective for the connection.
  • The target account's password field is exactly *.
  • At least one other local account has a SHA-256 or SHA-512 crypt hash, beginning with $5$ or $6$.
  • The attacker submits a password between 257 and 1024 bytes.

To target root through password authentication, the server must also permit password-based root login, for example with PermitRootLogin yes. This setting is not a general prerequisite for exploiting another login-capable account.

Systems using PAM for password verification do not take this path, and systems with password authentication disabled are also protected from this attack vector. The Alpine Linux advisory identifies accounts locked with ! as unaffected by this specific comparison.

Protection provided by Alpaquita defaults

The default Alpaquita Linux root configuration contains two protections against this vulnerability.

First, the installer locks the root account with ! in /etc/shadow, rather than a solitary *. The stored value therefore does not match musl's error indicator.

Second, Alpaquita Linux ships with the following default SSH policy:

PermitRootLogin prohibit-password

This setting disables password authentication for root even when password authentication remains enabled for other accounts.

These defaults protect the standard root configuration but do not replace the security update. Custom images, manually created accounts, directory-backed users, altered shadow entries, or Match blocks in the SSH configuration can still create the required conditions.

The package update corrects the authentication path itself and does not depend on every system retaining the default account and SSH configuration.

Fixed OpenSSH packages

OpenSSH 10.6p2 is the first upstream portable release containing the fix, but Linux distributions may backport the correction to older maintained release lines. The complete distribution package version must therefore be checked rather than only the upstream OpenSSH version.

Alpaquita Linux branchFirst fixed OpenSSH package
Streamopenssh=10.6_p2-r0
25 LTSopenssh=10.6_p2-r0
23 LTSopenssh=9.1_p1-r17

None of these packages is vulnerable to CVE-2026-123158.

Alpaquita Linux 23 LTS remains on its established OpenSSH 9.1p1 release line. BellSoft backported the security change and published it as package revision r17. An installed 23 LTS package is protected when it is 9.1_p1-r17 or a later package from the same branch.

The current Alpaquita Stream repository already provides 10.6_p2-r0. A fully updated Stream system therefore uses a non-vulnerable OpenSSH package.

Fixed across all supported branches within one day

The vulnerability became public and OpenSSH 10.6p2 was released on November 5, 2026. BellSoft investigated the impact, updated Stream and 25 LTS to the fixed upstream release, and backported the correction to the OpenSSH version used by 23 LTS.

BellSoft delivered a fixed package for every supported Alpaquita Linux branch within one day of disclosure. The current Stream repository already contains the corrected OpenSSH version; users do not need to wait for a later Stream release.

Update and verify

Update the package index and installed packages:

apk update
apk upgrade

If a full system upgrade is not possible, update the OpenSSH server package separately:

apk update
apk upgrade openssh-server

Verify the installed package:

apk list -I openssh-server

Compare the output with the fixed-version table. On 23 LTS, 9.1_p1-r17 or a later package revision contains the backport. On Stream and 25 LTS, the installed package must be 10.6_p2-r0 or later.

Restart the SSH service:

rc-service sshd restart

Updating the package replaces the executable on disk, but an already running sshd process continues to execute the previous code until the service is restarted.

When updating a remote machine, keep the existing administrative session open. Establish a second connection and verify that key-based authentication works before closing the first session.

Temporary mitigation

If the corrected package cannot be installed immediately, disable password authentication:

PasswordAuthentication no
PermitRootLogin prohibit-password

Validate the effective SSH configuration before restarting the service:

sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|usepam'

If the configuration contains Match blocks, repeat the check with sshd -T -C for the relevant user and connection. A connection-specific rule may override the global PasswordAuthentication setting.

Confirm that key-based authentication works, restart sshd, and test a new connection while the existing session remains open.

Disabling password authentication mitigates this attack vector but does not replace the security update. Fixed OpenSSH packages are already available for every supported Alpaquita Linux branch, and the current Stream repository already carries 10.6_p2-r0.

Subcribe to our newsletter

figure

Read the industry news, receive solutions to your problems, and find the ways to save money.

Further reading