OpenSSH CVE-2026-123158: Alpine sshd password bypass in CISA KEV, how to fix

Summary. CVE-2026-123158, nicknamed SSHole, lets an attacker who can reach an SSH port log in to certain accounts without knowing a password on Linux systems where sshd uses musl libc without PAM. Alpine Linux is the main example. OpenSSH shipped a workaround in Portable OpenSSH 10.6p2 on 5 November 2026, and Alpine published fixed openssh packages the same day for every branch from 3.16 to edge, with point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4. The CVE record carries a CVSS 3.1 score of 8.1 (High). CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalogue on 9 November 2026 with a due date of 12 November and flagged it for forensic triage. GreyNoise saw its first successful exploitation on 7 November. A host is exposed only when four conditions hold: sshd without PAM, PasswordAuthentication yes, an account whose password field is *, and at least one account with a $5$ or $6$ hash. The fix is apk upgrade followed by an sshd restart, because the upgrade does not restart the running daemon. If you cannot patch now, set PasswordAuthentication no and restart sshd; Alpine says either step closes the hole. Containers that do not run sshd are not affected.

About this article. For platform, SRE and security teams running Alpine or other musl-based systems with SSH. On 11 November 2026 we checked every date, version and status against Alpine's advisory, release announcement, release data and security database, the OpenSSH 10.6p2 release notes and fix commit, the NVD record, CISA's KEV entry and BOD 26-04, the EU Cyber Resilience Act text and the Docker Official Images manifest. Exploitation details come from GreyNoise and are labelled as vendor research. The steps are defensive only; the regional notes are general information, not legal advice. No vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

Key dates

The timeline below comes from the OpenSSH release notes, Alpine's advisory, the NVD record, the Docker Official Images history, GreyNoise's tracker and CISA's KEV entry.

CISA lists it as an OpenBSD OpenSSH unexpected status code or return value vulnerability (CWE-394) and marks ransomware use as unknown. OpenSSH credits Özgün Kültekin of Wakefield with the report. For another open-source flaw CISA added to KEV this autumn, on 27 October, see our Brotli CVE-2026-111497 guide.

What goes wrong, in defensive terms

When sshd is built without PAM, it checks a password itself. It hashes the attempt with the C library's crypt() function and compares the result with the stored password field. For an account whose stored field is too short to hold a salt, sshd borrows the salt of another account, which is why the bug needs at least one real $5$ (SHA-256) or $6$ (SHA-512) hash on the machine.

Alpine explains the rest: musl's crypt() returns the string * as an error marker when the input is too long, and * is exactly what the stored field holds for an account with no password. The comparison matches and the login succeeds. OpenSSH says it considers the root cause to be outside sshd, but because the bug is exploitable through sshd, 10.6p2 avoids it there. Alpine's stable-branch packages carry a patch for the same problem.

Ignore the High attack complexity in the CVSS vector. Alpine says an attacker who knows an affected account name needs one connection, and one user with a password makes every account without one reachable. GreyNoise calls the flaw trivial to exploit, and CISA's assessment on the CVE record rates exploitation as active and technical impact as total.

Are you affected? Check all four conditions

Alpine lists four conditions, and all must be true.

Not affected, according to Alpine: containers that do not run sshd; systems with PasswordAuthentication no; openssh-server-pam with UsePAM yes; locked accounts whose shadow field starts with !; systems with no $-style hash; and cloud images configured through cloud-init, which writes PasswordAuthentication no.

Run these as root on a suspect host:

            cat /etc/alpine-release
apk info -v 2>/dev/null | grep '^openssh-server'
sshd -T | grep -i -E '^(passwordauthentication|usepam|permitrootlogin) '

# Accounts with no password set (field is exactly *)
awk -F: '$2=="*" {print $1}' /etc/shadow

# Accounts with SHA-256 or SHA-512 crypt hashes
awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadow
          

If the first awk command prints any account, the second prints at least one, and sshd -T shows password authentication on without PAM, treat the host as exposed until it is patched. Directory users served through musl-nscd have no shadow entry, so the awk check will not list them; count them as exposed accounts too.

The root account and doas

Alpine has shipped root with a * password field in its base image since about 3.16. OpenSSH's default PermitRootLogin prohibit-password protects root from this bug, so root itself is reachable only if PermitRootLogin yes is set. That protection does not help if another affected account can become root, for example through doas. Review your doas rules for passwordless entries on key-only users.

Alpine cloud images

Alpine says the official tiny-cloud images (qcow2, VHD and AMI) 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 but become exploitable as soon as any $6$ hash exists, for example when an administrator sets a console password or user data adds a user with a hashed password. An attacker then gets a shell as alpine and can use doas to become root.

Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package. Instances launched from earlier images do not fix themselves, so every running instance needs the update or the configuration change.

Other musl systems

NVD describes the flaw as affecting OpenSSH on Linux when musl libc is used without PAM, with Alpine as one example. Embedded and appliance builds can match that profile: on the oss-security list on 9 November, the medical-device security firm Medcrypt reported reproducing the issue independently on a stock Yocto image. If you build firmware or appliances with musl and OpenSSH, check your sshd build options and ask your suppliers. Mainstream glibc distributions that use PAM sit outside the configuration the advisories describe.

Fixed versions

Alpine published fixed openssh packages for every branch from 3.16 to edge. Package versions keep each branch's OpenSSH base and add a release number, so compare against this table, not against 10.6p2. Versions come from Alpine's advisory and security database, and branch dates from Alpine's release data.

A fix for an end-of-life branch is a one-off. Plan to move anything on 3.21 or older to 3.22 or later.

If you build OpenSSH from source on a musl system, use Portable OpenSSH 10.6p2, still the latest release on 11 November 2026. NVD's configuration marks OpenSSH before 10.6, 10.6 and 10.6p1 as vulnerable when paired with Alpine releases before the point releases above.

How to fix it on a host

Step 1: update and restart

            apk upgrade -U -a
rc-service sshd restart
apk info -v 2>/dev/null | grep '^openssh-server'
          

Alpine stresses the restart: upgrading the package does not replace the running sshd. Confirm the installed version matches the table for your branch.

Step 2: or disable password authentication now

If you cannot update straight away, turn off password logins. First confirm that SSH key login works, and keep your current session open until a new login succeeds. Alpine's advisory gives a sequence that writes a drop-in file and also edits the main config. The minimum is to make the effective setting no:

            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 | grep -i passwordauthentication
          

Alpine's default sshd_config reads the drop-in directory from 3.19 onward; older releases ignore it. On those releases, and wherever PasswordAuthentication yes appears in the main file or a Match block, edit /etc/ssh/sshd_config as the advisory describes. The last command must print passwordauthentication no.

Keep password logins off after patching unless you have a documented need. Key-only SSH removes this whole class of bug.

Step 3: tighten the accounts

• Lock service accounts that should never log in. Alpine notes that a locked account, one whose shadow field starts with !, cannot log in with a password or a key, so do this only for accounts nobody uses, not for key-only users you still need.

• Remove passwordless doas rules that are not essential.

• Keep PermitRootLogin prohibit-password, or set it to no.

• Restrict port 22 with security groups or firewall rules to known address ranges or a bastion.

Check whether you were attacked

Patching does not tell you whether someone got in first. Public exploit code appeared about four hours after the release, so review every host that was reachable with password logins on from 5 November onward. CISA requires US federal agencies to carry out a forensic triage of affected assets for this entry, not just patch, which is a sensible bar for everyone.

Alpine's guidance is to look in /var/log/messages for sshd lines recording an accepted password for an account that has no password, such as alpine, root or any key-only user:

            grep 'sshd' /var/log/messages* | grep 'Accepted password for'
          

Compare the account names with the list of * accounts from the earlier check. A password login to a key-only account is a strong signal.

GreyNoise's tracker, last updated on 11 November, records confirmed post-exploitation activity from eight attacker addresses on its sensors. The attackers checked whether they were in a container, queried AWS, Azure and Alibaba Cloud metadata services, tried to read root's SSH keys and /etc/shadow through doas, added keys to authorized_keys for alpine and root, and changed /etc/hosts and /etc/resolv.conf. One cluster, which GreyNoise calls GT10, installed a Python implant it names TAC Agent and registered it as a startup service. That is honeypot data, not a full picture, but it makes a checklist:

• Review every authorized_keys file, including root's, for keys you did not add.

• Check doas use, new users and groups, and recent changes to /etc/hosts, /etc/resolv.conf and /etc/init.d.

• Run rc-update show for unfamiliar boot services; GreyNoise says the agent keeps its configuration at ~/.config/tac/agent.json.

• On cloud instances, check audit logs for use of the instance's role credentials from unexpected addresses, and rotate them if the host was exposed.

• Look for outbound connections you cannot explain.

If you cannot rule out a login, Alpine's advice is to treat the machine as compromised. Preserve logs and a snapshot, isolate the host, rotate credentials and keys from a clean machine, and rebuild from a known-good image rather than cleaning in place.

Container and base-image guidance

Most Alpine containers are not affected

Alpine says containers that do not run sshd are not affected, which covers most application containers. The risk sits in images that install and run openssh-server: SFTP and file-drop containers, Git-over-SSH services, bastion and jump images, CI runners with SSH access, development containers and older apps that expect SSH for administration.

Search Dockerfiles and build scripts for openssh, check image SBOMs for openssh-server, and look for an sshd process in running containers. Community images matter too: on 7 November a user opened an issue asking the panubo/docker-sshd project to update for this CVE, and a Coolify community discussion pointed out that its Alpine install path enables sshd without explicitly turning off password logins.

Rebuild, do not just restart

The Docker Official Images manifest for alpine moved to 3.24.4 (latest), 3.23.8, 3.22.8 and 3.21.10 on 5 November. That alone does not fix your images. An image that installs OpenSSH at build time keeps whatever package was current when it was built, and 3.20 and older get no new base tags. Rebuild so the fixed package is pulled:

            FROM alpine:3.24
RUN apk upgrade --no-cache \
 && apk add --no-cache openssh-server \
 && mkdir -p /etc/ssh/sshd_config.d \
 && echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
          

Build with --pull and without cached layers, then confirm the version inside the image:

            docker build --pull --no-cache -t registry.example.com/sftp:patched .
docker run --rm --entrypoint apk registry.example.com/sftp:patched info -v | grep '^openssh-server'
          

For 3.24 the result must be openssh-server-10.3_p1-r2 or later; use the fixed-versions table for other branches. Then redeploy and retire old tags. Restarting an old container restarts the old sshd.

Base-image rules worth keeping

1. Do not run sshd in application containers. Use docker exec, kubectl exec or your platform's session tooling instead.

1. If a container must run sshd, make it key-only and bake PasswordAuthentication no into the image, as above.

1. Rebuild on a schedule, not only on alerts. An image built before 5 November keeps the vulnerable package until it is rebuilt.

1. Gate in CI. Fail the build if openssh-server is below the fixed version for its branch, and refresh your scanner's vulnerability database before trusting a clean result.

1. Triage scanner hits by package. The bug is in sshd. An image that carries only the OpenSSH client is lower priority, though it should still be updated on the next rebuild.

For wider base-image planning, including the Ubuntu change that affects many CI and Docker images, see our Ubuntu 22.04 end-of-standard-support plan.

A 24-hour response plan

CISA gave federal agencies three days from listing and asked for forensic triage, which shows how it rates the risk. A workable plan for everyone else:

The order matters. Turning off password logins takes minutes and needs no package download, so do it first on anything exposed, then patch.

India, EU and US notes

India. GreyNoise lists 12 systems in India among those the GT10 cluster successfully exploited. It rates that figure medium confidence, because it comes from artifacts found on an attacker's server covering only part of its scanning. If your team runs Alpine on VPS hosts, in cloud accounts or in containers, start with any internet-facing host where password SSH was left on for convenience. If you find signs of compromise, follow your CERT-In incident reporting process and your contractual breach-notice terms.

EU. Device and appliance makers that ship musl-based firmware with OpenSSH should check whether their products are affected. Since 11 September 2026, Article 14 of the Cyber Resilience Act has required manufacturers to send an early warning within 24 hours of becoming aware of an actively exploited vulnerability in their product, through ENISA's single reporting platform. Our guide to CRA vulnerability reporting explains the duty. Take legal advice on your own products.

US. The 12 November KEV deadline binds federal civilian executive branch agencies under BOD 26-04, which CISA issued on 10 June 2026 and which revoked BOD 22-01. Suppliers running Alpine-based services for those agencies may be asked for evidence of the fix. Our Langflow KEV guide explains why private companies should treat KEV listings as urgent too.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our cybersecurity services team can find Alpine hosts and sshd containers across your accounts, apply the configuration fix, rebuild base images and review hosts for signs of compromise. Talk to us at /contact-us/.

Last updated: 11 November 2026.

References

1. CVE-2026-123158 record, including CISA KEV and SSVC fields (API) — NIST National Vulnerability Database

1. OpenSSH release notes, OpenSSH 10.6p2 (5 November 2026) — OpenSSH

1. Security advisory: openssh-server password authentication bypass, 5 November 2026 — Alpine Linux

1. Known Exploited Vulnerabilities catalog entry for CVE-2026-123158 — CISA

1. SSHole (CVE-2026-123158) activity 2026, updated 11 November 2026 — GreyNoise

1. alpine: security bump 3.21.10, 3.22.8, 3.23.8 and 3.24.4, 5 November 2026 — Docker Official Images on GitHub

1. avoid password authn bypass, commit 4353fdc — OpenSSH Portable on GitHub

1. Re: sshole password authentication bypass, OpenSSH and musl libc, 9 November 2026 — oss-security mailing list

1. Alpine secdb, v3.24 main repository — Alpine Linux

1. Alpine Linux release branches and end-of-support dates (releases.json) — Alpine Linux

1. BOD 26-04: Implementation guidance for prioritizing security updates based on risk — CISA

1. CVE-2026-123158, issue 93, 7 November 2026 — panubo/docker-sshd on GitHub

1. Harden Alpine SSH installation against CVE-2026-123158 (SSHole), discussion 12484 — Coolify on GitHub

1. library/alpine manifest — Docker Official Images on GitHub

1. BOD 26-04: Prioritizing security updates based on risk, 10 June 2026 — CISA

1. Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 14 and 71 — EUR-Lex