sshole (CVE-2026-123158): How to Check Alpine Servers and Docker Images for the OpenSSH Password Bypass

Alpine fixed every branch by adding OpenSSH’s workaround to the version it already ships, so the upstream version stays the same and only the package revision changes: 10.3_p1-r1 is vulnerable on Alpine 3.24, 10.3_p1-r2 is fixed. ssh -V prints OpenSSH_10.3p1 for both.

As of Nov 6, 2026, Alpine’s security database (secdb) lists CVE-2026-123158 only for edge. Scanners that read it, such as Trivy and Grype, may not flag images on Alpine 3.21–3.24 yet, so a clean scan is not proof. Check the package version directly until the database catches up.

Run cat /etc/alpine-release and apk info -v openssh-server openssh-server-pam. If the package is below the fixed build for your branch, upgrade with apk upgrade -U -a.

Next, see whether the bug can reach you today. sshd -T | grep -Ei '^(usepam|passwordauthentication|permitrootlogin) ' shows whether password logins are on (the default), whether root may use a password and, for openssh-server-pam, whether PAM is used. awk -F: '$2=="*"{print $1}' /etc/shadow lists accounts without a password. Root is one of them on Alpine 3.16 and newer, but the default PermitRootLogin prohibit-password refuses root passwords, so root counts only where it is set to yes. The bug needs such an account plus one account that does have a password.

Users created with adduser -D get a locked ! field, and sshd without PAM refuses them, so a common fix for “account is locked” was to replace ! with *. Any user changed that way is exposed while the server is unpatched.

For a running container: docker exec <container> apk info -v openssh-server. For an image: docker run --rm --entrypoint apk <image> info -v openssh-server. Containers that don’t run sshd are not affected, whatever packages they contain.

An image keeps the package that was current when it was built. Rebuild every image that installs openssh-server with docker build --pull so the base and the package are fresh, push it and redeploy; restarting the old image changes nothing.

We checked 14 popular image variants on Nov 6. Gitea, Forgejo, Gogs and the Jenkins SSH agent turn password logins off, and linuxserver/openssh-server enables them only with PASSWORD_ACCESS=true; these are not exposed in their default setup, but most still ship the vulnerable package until a rebuilt tag is published. atmoz/sftp:alpine builds from before Nov 5 were exposed in their documented setup: key-only users are stored as * and password logins stay on. The tracker lists image-by-image status.

Alpine’s official cloud images (tiny-cloud) from 3.18.11 through 3.24.3 create an alpine user with no password and passwordless doas. Instances launched from them need the update or the mitigation on each running machine; replacing the image only helps new instances.

Images that set PasswordAuthentication no through cloud-init are not exposed, but upgrade anyway.

Restart sshd with rc-service sshd restart: upgrading the package doesn’t replace the daemon that is already running. If readlink /proc/$(pidof sshd)/exe ends in (deleted), the old binary is still in memory.

Then look back: search /var/log/messages for “Accepted password for” on accounts that have no password, such as root, alpine or key-only users. If you can’t rule out such a login, treat the host as compromised.

Add a drop-in such as /etc/ssh/sshd_config.d/00-no-passwords.conf with PasswordAuthentication no, restart sshd, and confirm that key login still works before you close your session. Review Match blocks: they can turn password logins back on for some users or addresses.

On Alpine 3.15 and older there is no fixed package, so this setting is the only protection until you upgrade to a supported release.