# OpenSSH Authentication Bypass on Alpine Linux Servers

URL: https://intellegosoftworks.com/blog/openssh-authentication-bypass-alpine-linux
Published: 2026-11-05
Updated: 2026-11-05
Written by: Intellego Softworks

> OpenSSH authentication bypass CVE-2026-123158 affects certain musl-based Linux servers that verify passwords without PAM. On vulnerable Alpine Linux systems, the flaw can allow access to accounts that should not accept password logins. OpenSSH 10.6p2 and Alpine’s backported packages address the issue. This article explains the affected configurations, immediate mitigation, and the checks administrators should perform after updating.

On November 5, 2026, OpenSSH published an emergency fix for a serious flaw that can bypass password authentication on certain Linux servers. Tracked as **CVE-2026-123158**, the OpenSSH authentication bypass carries a CVSS 3.1 score of 8.1 (High). The affected configurations use the musl C library and verify SSH passwords without PAM, making some Alpine Linux servers a particular concern.

Under the right conditions, an attacker can remotely access an account that is not supposed to accept a password. OpenSSH released 10.6p2 to address the problem, while Alpine published patched packages for its own releases. This does not mean every Linux server running SSH is vulnerable.

## Which servers are affected by the OpenSSH flaw?

Alpine Linux's [November 5 security advisory](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) identifies four conditions that must exist together:

- The OpenSSH server checks passwords without PAM. Alpine's standard `openssh-server` package is built this way, and `openssh-server-pam` can also be exposed when configured with `UsePAM no`.
- SSH password authentication is enabled through `PasswordAuthentication yes`.
- At least one account has `*` in its password field, meaning the account has no valid password for normal password-based login.
- Another local account has a password hash beginning with `$5$` or `$6$`.

An attacker who can connect to SSH and knows the name of an eligible account may then gain access without knowing a real password. Accounts created for SSH-key-only access are especially relevant. Not setting a password for an account does not disable password authentication at the SSH server level.

Certain Alpine cloud images also contain a default `alpine` user that can be exposed. Where that user has passwordless `doas` access, a successful login can lead to root privileges. Direct password-based root login, however, is blocked by OpenSSH's default `PermitRootLogin prohibit-password` configuration. It would be inaccurate to say that all affected installations allow direct root login.

## How can an account with no password accept a login?

The issue comes from an unexpected interaction between OpenSSH's password checking and an error returned by musl. On Linux, an asterisk (`*`) in an account's password field indicates that the account has no valid password hash.

Without PAM, OpenSSH can verify password attempts using the `crypt()` function. For certain inputs longer than 256 bytes, musl refuses to compute the hash and returns `*` as its error value. OpenSSH can also use password-hash settings taken from another account when checking an account without a valid hash. Under the vulnerable conditions, the error value and stored password field end up matching.

That makes password submissions between 257 and 1,024 bytes capable of passing authentication on affected systems. Security researcher Özgün Kültekin explains the history of these interacting behaviors in the [original technical investigation](https://sshhole.com/). The failure is not a break in SSH encryption. It is an authentication error caused by components assigning different meanings to the same value.

## How should administrators fix the vulnerability?

The upstream fix is included in [OpenSSH 10.6p2](https://www.openssh.org/releasenotes.html#10.6p2). Distribution vendors can also backport the correction into older OpenSSH package versions. Alpine, for example, lists `10.3_p1-r2` for version 3.24, `10.2_p1-r1` for 3.23, `10.0_p1-r11` for 3.22, and `9.9_p2-r1` for 3.21 among its fixed packages. It also issued special updates for older branches back to Alpine 3.16, including releases that are otherwise out of support.

On Alpine, the vendor recommends updating packages with:

```sh
apk upgrade -U -a
```

The running SSH daemon must then be restarted:

```sh
rc-service sshd restart
```

Installing a new package does not automatically replace an existing `sshd` process in memory. On remotely managed servers, administrators should confirm they have a working method of reconnecting, preferably with console access available, before changing SSH settings or restarting the service.

If the update cannot be applied immediately, Alpine recommends setting `PasswordAuthentication no` as a temporary measure. First verify that SSH key access works. The configuration can be checked with `sshd -t` before restarting the daemon. Administrators should also review included configuration files and `Match` rules, since these can change the effective settings for particular users or connections.

## What should businesses check beyond the package version?

This vulnerability shows why using SSH keys for daily administration does not necessarily mean password authentication is disabled. Deployment accounts, default users created by cloud images, and long-standing SSH configuration files deserve attention.

Start by identifying which servers use Alpine or another musl-based system. Check whether the SSH service is actually running, whether it relies on PAM, and whether password login remains enabled. An ordinary Alpine application container that does not run an SSH daemon is not affected simply because its base image is Alpine.

Systems that previously ran an exposed configuration also warrant a log review. Alpine recommends searching `/var/log/messages` for `Accepted password for` entries relating to accounts that should not accept password logins. Such entries call for investigation. If unauthorized access cannot be ruled out, updating the package is only one part of the response; administrators should also inspect user accounts, keys, and elevated privileges.

## How can Intellego help secure server access?

Through our [DevOps services](https://intellegosoftworks.com/services/devops), Intellego Softworks helps businesses manage server configurations, security updates, monitoring, and deployment processes. We can assess existing infrastructure, plan and test updates, and prepare changes that preserve reliable access to production systems.

Responding to an issue like this involves more than checking a version number. The running service, its authentication settings, local account permissions, and the images used to build servers all matter. To review your infrastructure or improve your maintenance process, explore our [consultancy services](https://intellegosoftworks.com/services/consultancy) or [contact us](https://intellegosoftworks.com/contact).

## Questions and answers

### Are Ubuntu and Debian servers affected?

Typical installations using glibc and PAM-backed SSH authentication are not affected by the specific musl-without-PAM interaction described here. Custom-built packages or unusual authentication configurations should still be checked against their actual components.

### Is SSH key authentication enough to prevent the attack?

No. Leaving an account without a password and disabling password authentication on the server are different things. Affected systems need the security fix or an effective `PasswordAuthentication no` configuration.

## Sources

- [OpenSSH - Portable OpenSSH 10.6p2 Release Notes (November 5, 2026)](https://www.openssh.org/releasenotes.html#10.6p2)
- [Alpine Linux - openssh-server Password Authentication Bypass Security Advisory](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/)
- [Özgün Kültekin - *sshole: Original Technical Investigation](https://sshhole.com/)
- [OpenSSH Portable - Authentication Bypass Fix Commit](https://github.com/openssh/openssh-portable/commit/4353fdc43ef646c43a8dda7025cc1a898caf1482)
- [Tenable - CVE-2026-123158 Vulnerability Record and CVSS Score](https://www.tenable.com/cve/CVE-2026-123158)
- [The Hacker News - OpenSSH Emergency Fix on Alpine Linux](https://thehackernews.com/2026/11/openssh-issues-emergency-fix-for-flaw.html)