SSHole (CVE-2026-123158): Check and Fix the OpenSSH Flaw on Alpine and musl

Have Linux servers and container images checked for flaws like SSHole? WZ-IT inventories hosts and images, applies updates and monitors new vulnerabilities, see CVE monitoring and managed server operations. Book a meeting

On 5 November 2026 the OpenSSH project released OpenSSH 10.6p2, an urgent security release. It closes CVE-2026-123158, which its discoverer Özgün Kültekin named "SSHole": on Linux systems with musl libc and without PAM, sshd accepts an overlong password for accounts whose shadow field is *. The standard case is Alpine Linux with the openssh-server package.

According to the OpenSSH project, the flaw exists neither on Linux with glibc nor on systems that check passwords through PAM. Debian, Ubuntu, RHEL and Proxmox VE are glibc-based and use PAM in their default configuration; Red Hat explicitly states its products are not affected. The flaw matters where Alpine is used as a base, often without anyone noticing: in container images with their own sshd (Git servers, bastion and jump containers, SFTP services), on hosts set up with Alpine instead of Debian, and in Coolify deployments on Alpine servers.

This article lists the preconditions in detail, the patched versions per Alpine branch, the state of exploitation and concrete check commands for hosts and containers. All information is as of 9 November 2026.

Table of Contents

1. The flaw at a glance
2. How the bug arises
3. Who is affected and who is not
4. Affected and patched versions
5. Is the flaw being exploited? State as of 9 November 2026
6. How to check hosts and containers
7. Immediate mitigation and update
8. Rebuild container images instead of only updating packages
9. Coolify, Git servers and bastion containers
10. Checking for signs of an attack
11. Debian, Ubuntu and Proxmox: why the scanner still reports
12. Our approach at WZ-IT
13. Further guides

The flaw at a glance

Sources: CVE record, NVD, OpenSSH 10.6p2 release notes, Alpine advisory, BSI warning of 6 November 2026 (German).

The vector describes a flaw that can be exploited over the network without user interaction and without prior privileges (AV:N, PR:N, UI:N). AC:H (high complexity) stands, according to the CVSS specification, for conditions outside the attacker's control. The CNA gives no reasoning; the obvious reading is that the preconditions that must hold on the target system at the same time are meant (assessment). The release notes call the bypass in sshd a "critical security workaround"; according to OpenSSH the root cause lies outside sshd.

How the bug arises

The bug arises from the interplay of four behaviours. The description follows the Alpine advisory and the discoverer's page:

1. Accounts that are not meant to log in with a password often carry *. In /etc/shadow, key-only accounts, root (on Alpine since about version 3.16) and many service accounts have an asterisk in the hash field. No valid password hash is *, so password login is ruled out according to shadow(5). Other states are different: a field starting with ! is locked, and an empty field allows login without a password according to shadow(5), unless the application refuses access anyway. In this article, "account without a password" means an account with exactly *.
2. musl reports errors as *. The crypt() function of musl libc returns the string * instead of NULL on error. An error also occurs when the key is longer than 256 bytes and a SHA-256 or SHA-512 salt is used. According to the discoverer, crypt() returns NULL on error as POSIX requires, and libxcrypt returns a failure token such as *0 (depending on its configuration also NULL); none of these matches *, and sshd rejects the login.
3. sshd borrows a foreign salt. Since the fix for CVE-2016-6210 (detecting existing users through timing differences), sshd without PAM also hashes for accounts without a usable hash. The salt comes from another account. For that, at least one account with a $5$ or $6$ hash must exist. In the source code (pick_salt()), sshd takes the salt of the first account whose hash starts with $. Whether an existing $5$ or $6$ hash is actually used as the salt therefore depends on the order of the accounts.
4. The comparison matches. crypt() returns *, the shadow field contains *, both are equal: sshd treats that as the correct password.

For this the attacker sends a password of 257 to 1024 bytes for an account name they know. For an exploitable system, Alpine describes it as one connection, works every time, no retries. The CVE text differs and says "between 256 and 1024 characters", the discoverer's page says "257 and 1024 characters" and describes the musl limit in bytes. Alpine gives 257 to 1024 bytes, which matches the 256-byte limit of musl (KEY_MAX 256 in crypt_sha512.c).

With PAM password checking the bug does not occur according to the OpenSSH project; according to the discoverer, PAM, which most distributions use, does not call crypt() at all for an account with *. The fix in OpenSSH 10.6p2 (commit 4353fdc) no longer accepts a stored hash shorter than four characters in auth-passwd.c. A single * can therefore no longer count as a match.

Who is affected and who is not

According to the Alpine advisory, all four conditions have to be met at the same time. They are minimum requirements: access restrictions such as AllowUsers and DenyUsers, or AuthenticationMethods with several methods that must all be completed (sshd_config), can still prevent the login.

A single account with a $5$ or $6$ hash can make accounts with * reachable. That can be a password an admin set for the console, or a user created through cloud-init with hashed_passwd.

Typical target accounts according to Alpine:

• Key-only accounts created with adduser without a password.
• Users from a directory service via musl-nscd (nslcd, winbind, sssd), if they have no shadow entry.
• root: since about Alpine 3.16 the account carries root:*. The default PermitRootLogin prohibit-password protects root as long as nobody sets PermitRootLogin yes.
• The user alpine on the official tiny-cloud images (qcow2, VHD, AMI) from 3.18.11 to 3.24.3. It has a * and passwordless doas. According to Alpine, the images are safe on first boot and become exploitable as soon as a $6$ hash exists on the machine. Images from 3.21.10, 3.22.8, 3.23.8 and 3.24.4 contain the fix.

Not affected according to Alpine:

• Containers that do not run sshd.
• Systems with PasswordAuthentication no.
• Locked accounts with ! in the shadow field (line starts with user:!:). According to Alpine they can log in with neither password nor key (statement of the advisory for sshd without PAM).
• Systems on which no account has a $ hash.
• Cloud images configured through cloud-init where cloud-init writes PasswordAuthentication no. That holds only as long as it stays that way: ssh_pwauth: true enables password login again, and without a value the existing setting stays unchanged (cloud-init).

Two points are easily misunderstood. First, it is not "any password for any account": the target account must carry exactly *, the password must be 257 to 1024 bytes long, and another account needs a $5$ or $6$ hash. Second, an account with * is not protected against this flaw even though it cannot log in with an ordinary password: according to Alpine, an account with ! in the field is locked and therefore not affected.

Beyond Alpine, the discoverer names further musl systems to check: OpenWrt, Buildroot and Yocto, and Docker images based on them (Help Net Security). Dropbear and OpenBSD are not affected according to the discoverer.

Affected and patched versions

Upstream, the CVE record formally lists all OpenSSH Portable versions before 10.6p2 on Linux as affected; that does not say that every one of these versions is technically affected. The libc is what decides: on glibc systems or with PAM the bug does not occur (see below).

On Alpine, the patched packages keep their older version number because the fix was backported to the packages of the stable branches. Alpine has published patched packages for every branch from 3.16 to edge:

Sources: package versions from the Alpine advisory, support state from the Alpine releases. The package versions match the APKINDEX files of the main repositories (x86_64) of branches 3.16 to edge as of 9 November 2026. The entry in the 3.22 APKBUILD reads 10.0_p1-r11: CVE-2026-123158.

For branches before 3.16 the advisory does not state whether they are affected. We recommend replacing images and servers on these versions anyway.

Other distributions (as of 9 November 2026):

Damien Miller of the OpenSSH project put the boundary this way in his announcement: the flaw does not exist on non-Linux systems, on Linux with glibc, or on Linux systems that use PAM for password authentication.

Is the flaw being exploited? State as of 9 November 2026

The sources report at different points in time. The following table separates who says what:

Assessment:

• Established: A proof of concept is public. The CVE record points to reproduction repositories, and the BSI confirms availability. Previdian warns that the public scripts are unverified and could contain malicious code.
• Observed attempts: Previdian reports attempts and root access to one of its own honeypots. Independently, the SANS Internet Storm Center observed exploit attempts in honeypots from 5 November; its report of 8 November leaves open whether they succeeded. We found no documented compromise of production systems as of 9 November 2026. The earlier statement from Field Effect does not contradict this; it refers to the time of disclosure.
• Not established: a broad wave of attacks. 20 attempts on 4 sensors do not allow a statement about how widespread attacks are.

In practice the open state of exploitation changes nothing. A successful attack needs one connection and the name of an account with *, and names like alpine, root or git are easy to guess. A host that meets the preconditions has to be treated as exploitable until it is updated or password login is disabled.

How to check hosts and containers

The commands are written for Alpine hosts with OpenRC and BusyBox. They only read and do not change any configuration.

Step 1: Is the system running Alpine, and which sshd is running?

cat /etc/alpine-release
ldd /usr/sbin/sshd; echo "ldd exit status: $?"
apk list -I 'openssh*'
ls -l /proc/$(cat /run/sshd.pid)/exe

On musl systems ldd shows an entry such as ld-musl-x86_64.so.1, on glibc systems libc.so.6. Empty output or an error message is not proof of glibc: the binary is missing or the check failed, and the exit status decides. apk list -I lists the installed OpenSSH packages with their version, which you compare against the table above. That shows the package state, not the state of the running process: a daemon started before the update keeps running the old code until it is restarted. The last line shows the binary that is actually running if sshd was started by OpenRC with the default PID file: /usr/sbin/sshd is the build without PAM, sshd.pam the PAM build and sshd.krb5 the Kerberos build, which is built with PAM support (the Alpine advisory does not cover this variant).

Note on checking PAM: the package name alone does not prove whether PAM is used. The OpenRC service of Alpine 3.22 picks the binary based on the configuration: with GSSAPIAuthentication yes or KerberosAuthentication yes it starts sshd.krb5, with UsePAM yes it starts sshd.pam, otherwise sshd. The installed variant, the binary that was started and UsePAM have to fit together. In addition, since OpenSSH 10.0 (Alpine 3.22 and newer) the authentication phase runs in a separate sshd-auth binary, and in the Alpine package openssh-server-pam libpam is linked to sshd-auth.pam, not to sshd. ldd /usr/sbin/sshd | grep -i pam is therefore not a test for PAM.

Step 2: Is password login active?

sshd -T | grep -i -E '^(passwordauthentication|usepam|permitrootlogin|allowusers|authenticationmethods) '
sshd -T -C user=alpine,host=localhost,addr=127.0.0.1 | grep -i -E '^(passwordauthentication|usepam) '
grep -n -i -E '^[[:space:]]*(PasswordAuthentication|Match|UsePAM|Include|AllowUsers|AuthenticationMethods)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf

sshd -T shows the configuration of the binary that is called and usually needs root privileges. If sshd.pam or sshd.krb5 is running, call that binary instead of sshd and pass the configuration path (-f) and the start options of the service; otherwise the output does not reliably reflect the running service. Without -C, Match blocks are not applied; with -C user=...,host=...,addr=... sshd -T prints the configuration for a specific connection (sshd(8)). Adjust user and addr to the accounts and source addresses you want to check. For permitrootlogin, without-password may appear, the older name for prohibit-password. The third line is only a pointer to Match blocks, Include lines and access restrictions; it evaluates neither the conditions of Match blocks nor includes outside the given paths. sshd -T -C is authoritative. In the default sshd_config of the Alpine package (checked for 3.22), PasswordAuthentication is not set, so the OpenSSH default yes applies.

Step 3: Are there target accounts and salt sources?

awk -F: '$2=="*"{print $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow

The first line lists accounts whose field is exactly * (possible targets). The second lists accounts with a $5$ or $6$ hash (possible salt sources). Accounts with ! at the start of the field are locked and do not appear. Both commands read only /etc/shadow; users from a directory service without a shadow entry do not appear there and have to be looked at separately.

Evaluation:

The evaluation does not replace a case-by-case review. The state of the running daemon, the binary actually started, the salt selection and additional access controls all play a part. Whether the target account may log in via SSH at all is restricted by directives such as AllowUsers. The example configuration of the Gitea image below shows this.

Step 4: Find containers

Running containers with an sshd in their process list (docker top reads the processes from the host; the Alpine version is printed as well):

for c in $(docker ps -q); do
  if docker top "$c" | grep -q '[s]shd'; then
    echo "$c $(docker inspect -f '{{.Config.Image}}' "$c"): sshd process, Alpine $(docker exec "$c" cat /etc/alpine-release 2>/dev/null || echo 'no')"
  fi
done

Search your own Dockerfiles in the repository for an installed OpenSSH server (openssh-client is excluded):

find . -type f \( -name 'Dockerfile*' -o -name '*.Dockerfile' \) -exec grep -nHEi 'openssh([^-a-z]|$)|openssh-server|sshd' {} \;

This is a search heuristic: comments, client configurations and other mentions of sshd can match as well. Check hits for an Alpine base (FROM alpine, FROM node:...-alpine) and then in the running container with steps 1 to 3.

Immediate mitigation and update

Immediately: disable password login. Alpine names this as the minimum measure when the update is not yet possible. Before that, make sure key-based login works, and keep the current session open until a new login has been tested. As root:

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T -C user=alpine,host=localhost,addr=127.0.0.1 | grep -i passwordauthentication

The last line must print passwordauthentication no. The drop-in only takes effect if the configuration includes the directory: Alpine's default sshd_config reads sshd_config.d from version 3.19, older releases or custom configurations ignore it, and Match blocks can override the setting for individual connections. Check the accounts and addresses you want to secure with -C. For older releases and for Match blocks that override the setting, the Alpine advisory gives a sed command that sets PasswordAuthentication to no in /etc/ssh/sshd_config and creates a backup sshd_config.bak.

Then: update.

apk upgrade -U -a
apk list -I 'openssh*'
rc-service sshd restart

The second line checks the package version against the table. The restart is mandatory: Alpine explicitly points out that the package update does not replace the running daemon. On systems without OpenRC, restart with the respective init system; in containers, restart the container from the new image.

UsePAM yes alone is not a substitute. In the default variant openssh-server PAM is not compiled in. The update, disabling password login, or switching to openssh-server-pam with UsePAM yes, which Alpine lists as not affected, are effective.

Rebuild container images instead of only updating packages

An apk upgrade in a running container only changes its writable layer. The image stays unchanged, and when the container is recreated, for example during a redeployment, the vulnerable version starts again. For containers this means:

1. Rebuild the image without build cache. A layer with apk add openssh from the build cache still delivers the old package.

   docker build --pull --no-cache -t my-image:new .
   docker run --rm --entrypoint sh my-image:new -c "apk list -I 'openssh*'"
   

   The output must show at least the version from the table for the Alpine branch of the base image. A container that is already running keeps its old image: it has to be recreated from the new image. Logs that exist only inside the container or on a tmpfs are lost in the process; save them first.

2. Update third-party images and recreate the containers.

   docker compose pull
   docker compose up -d --force-recreate
   

   This delivers patched packages only if the maintainer has published an updated image. If none is available yet, keep password login disabled in the container or rebuild the image with your own Dockerfile.

3. Remove old tags from your own registry so that no deployment pulls them again through that tag (check references by digest or by other tags separately). Merely flagging them does not prevent a pull.

4. Check the process: The Dockerfile either uses apk add without a fixed package version and is rebuilt regularly, or it pins package versions and has a managed update process. A pinned Alpine tag alone does not keep an image up to date.

For containers, sshd is restarted as soon as the container is started from the new image; no rc-service call is needed for that.

Coolify, Git servers and bastion containers

Coolify hosts on Alpine. Coolify lists Alpine Linux in its supported operating systems. If the installation script detects no OpenSSH server, it installs the openssh package on Alpine via apk add openssh, which brings openssh-server (without PAM) as a dependency, and enables and starts the service. It does not set PasswordAuthentication and only checks PermitRootLogin. The Coolify documentation on OpenSSH recommends PubkeyAuthentication yes and PermitRootLogin prohibit-password. If the openssh-server installed by the installer runs on a Coolify host on Alpine, the first condition is met. If SSH is preinstalled instead, or another variant is started, the variant running there applies (check as above). The remaining conditions decide whether the host is attackable. The Coolify community has an open hardening proposal from 7 November 2026 that explicitly does not claim that Coolify itself is vulnerable. There was no maintainer reply on 9 November 2026. If Coolify runs on Debian or Ubuntu (glibc, PAM), the flaw does not affect the host.

Git server images. The Dockerfile of the official Gitea image (branch main, as of 9 November 2026; published tags may differ) is based on Alpine 3.24, installs openssh and creates the user git with echo "git:*" | chpasswd -e: so the account with * exists. The bundled sshd template, however, sets PasswordAuthentication no, PermitRootLogin no and AllowUsers for the Git user. In the default configuration the second condition is therefore missing. Anyone who mounts their own sshd_config or changes the template should check exactly these lines. The Forgejo image follows the same pattern: Alpine 3.24, openssh, user git:* and an sshd template with PasswordAuthentication no, PermitRootLogin no and AllowUsers.

SSH containers for file transfer. The panubo/sshd image is an Alpine image with sshd. According to its README, password login is off by default and can be enabled with SSH_ENABLE_PASSWORD_AUTH=true. With password login enabled, one of the preconditions is met; the remaining preconditions and the package state of the image decide whether it is attackable.

Bastion and jump containers. It is worth asking what password login is needed for. A bastion host that only accepts keys can set PasswordAuthentication no permanently; we recommend that even without SSHole.

Checking for signs of an attack

An update does not undo a login that has already happened. Check as described in the Alpine advisory:

grep 'Accepted password for' /var/log/messages
grep '^alpine:' /etc/shadow

Every line Accepted password for <account> in which <account> is an account with * (alpine, root, a key-only account, git) is suspicious. If the account's shadow entry shows * and the log shows a successful password login, exploitation may have taken place (BleepingComputer). The current shadow value does not necessarily match the state at the time of the login. In containers, sshd messages end up, depending on the image, in the container log (docker logs <container>) or in a log file inside the container. They survive a normal restart of the container. They are lost when the container is removed and recreated (for example during a redeployment) unless they sit on a volume, a bind mount or in an external logging system; data in the writable layer does not persist once the container is destroyed (Docker). Back up the logs before recreating, for example with docker logs <container> > sshd-container.log 2>&1. That captures only the output docker logs provides; back up a log file inside the container (such as /var/log/messages) separately, for example with docker cp.

Also check (according to the Alpine advisory):

• use of doas,
• newly created users and newly created or changed files,
• authorized_keys of all accounts for unknown keys.

Beyond the advisory, we also check the use of sudo and the outgoing connections of the host.

Previdian names 89.116.89[.]18 as the observed source address. The absence of this address in the log proves nothing because it is a single observation by one vendor. If a login cannot be ruled out, Alpine treats the machine as compromised. Our recommendation in that case: rotate keys, tokens and credentials that were on the host and rebuild the host cleanly instead of hunting for individual changes.

Debian, Ubuntu and Proxmox: why the scanner still reports

The CVE record lists "OpenBSD OpenSSH before 10.6p2" on the Linux platform as the affected range. The machine-readable statement contains no condition on the libc. Scanners that only compare the version number with the record can therefore also flag Debian bookworm (OpenSSH 9.2p1) and trixie (10.0p1). Debian lists these packages formally as "vulnerable" but rates the urgency "unimportant". Red Hat states its products are not affected.

The reverse case happens on Alpine: patched packages keep their older version number (3.22 has 10.0_p1-r11), and a scanner that only compares against 10.6p2 shows fully patched Alpine hosts as vulnerable.

The same approach works in both directions:

• On glibc systems with PAM (Debian, Ubuntu, Proxmox, RHEL), substantiate the finding with the output of ldd /usr/sbin/sshd (libc.so.6 instead of ld-musl; an error or empty output is no proof) and the distribution's statement, and document it as not applicable.
• On Alpine, check against the package version per branch from the table, not against 10.6p2.
• On both sides, record exceptions with date and source so the next audit can follow them.

Our approach at WZ-IT

• Inventory: We record where sshd runs: on hosts, VMs and in container images, plus the base (Alpine or musl versus Debian or Ubuntu) and the package variant with or without PAM.
• Harden: We disable password login on affected systems, test key-based login and restart sshd.
• Update: We apply the patched packages, rebuild container images without build cache and check the package version in the new image.
• Check for traces: We review logs, accounts and authorized_keys and rotate keys and credentials if there is a suspicion.
• Monitor continuously: In managed operation, updates and CVE monitoring are included, which evaluates advisories from vendors and distributions. For Docker hosts, Docker server management covers the Linux host, the container runtime and the agreed deployment and backup scope. The server audit reviews existing systems once.

Do you know where sshd runs in your environment? In the server audit we record hosts and container images with SSH access and check base, package state and configuration. In managed operation, updates and CVE monitoring are included. Book an initial call (non-binding and free of charge)

Further guides

• Coolify CVE overview 2025/2026, vulnerabilities in Coolify and update obligations.
• Coolify operations by WZ-IT, self-hosted PaaS on your own servers.
• Why companies need CVE monitoring, how vulnerabilities are tracked in a structured way.
• PHP flaws CVE-2026-109618 and CVE-2026-109619, finding affected software and rebuilding container images.
• Linux kernel vulnerabilities 2026, patch management as a management task.
• Linux server hardening: checklist based on CIS and BSI, SSH configuration as part of hardening.
• Linux patch management, process, deadlines and evidence.
• Managed server operations, the hub for Linux servers and Docker hosts.
• Linux kernel TCP flaw CVE-2026-98432: patch Proxmox, Debian, Ubuntu - another current security case (as of November 2026)
• APT vulnerability CVE-2026-109518 in Debian and Ubuntu - another current security case (as of November 2026)
• CWPdoor: check for the Control Web Panel backdoor - another current security case (as of November 2026)
• Node-RED editor without adminAuth: CVE-2026-58115 (Siemens IoT2050) - another current security case (as of November 2026)

Have your sshd estate checked? We compare hosts and container images with the preconditions of the flaw, harden sshd and rebuild affected images. Book a meeting

Sources

• OpenSSH, release notes 10.6p2
• OpenSSH, release notes 10.0
• OpenSSH developer list, announcement "urgent security release: 10.6p2" (Damien Miller)
• OpenSSH Portable, commit 4353fdc "avoid password authn bypass"
• Alpine Linux, security advisory: openssh-server password authentication bypass
• Alpine Linux, releases and support periods
• Alpine Linux, APKBUILD openssh (3.22-stable)
• Alpine Linux, OpenRC service sshd (3.22-stable)
• CVE Program, CVE-2026-123158
• NVD, CVE-2026-123158
• CISA, Known Exploited Vulnerabilities Catalog
• BSI, cybersecurity warning on OpenSSH of 6 November 2026 (German)
• Debian Security Tracker, CVE-2026-123158
• Ubuntu, CVE-2026-123158
• Red Hat, CVE-2026-123158
• Proxmox VE, installation and system base
• OpenSSH Portable, xcrypt.c with pick_salt() (V_10_6_P1)
• musl libc, crypt_sha512.c
• OpenBSD, sshd_config(5)
• OpenBSD, sshd(8)
• Linux man-pages, shadow(5)
• cloud-init, module reference
• FIRST, CVSS v3.1 Specification
• Docker, Storage
• Özgün Kültekin, sshhole.com
• Previdian, CVE-2026-123158
• SANS ISC: Scans for Sshole Vulnerability (CVE-2026-123158)
• Help Net Security, OpenSSH flaw exploited in the wild just hours after disclosure
• The Hacker News, Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure
• BleepingComputer, OpenSSH flaw lets attackers log into password-disabled Linux accounts
• Field Effect, OpenSSH fix for authentication bypass on Alpine Linux
• Coolify documentation, installation and supported operating systems
• Coolify documentation, configuring OpenSSH
• Coolify, install.sh
• Coolify discussion 12484, Harden Alpine SSH installation against CVE-2026-123158
• Gitea, Dockerfile
• Gitea, sshd_config template for Docker
• Forgejo, Dockerfile
• Forgejo, sshd_config template for Docker
• panubo/docker-sshd