CVE-2026-123158 lets anyone who can reach sshd log in without the password on Linux hosts that run musl libc without PAM, when password login is on and the right accounts exist. Alpine is the example. OpenSSH 10.6p2 and Alpine's fixed packages close it. Don't start with the patch. Start by listing every Alpine host running sshd, name an owner for each, and turn password login off everywhere.
Are we exposed, and what does 12 November mean?
CISA added the flaw to its Known Exploited Vulnerabilities (KEV) list on 9 November, with a due date of 12 November. The entry calls it an authentication bypass in OpenBSD OpenSSH on Linux, marks forensic triage as required, and lists ransomware use as unknown. The due date comes from Binding Operational Directive 26-04 and binds US federal civilian agencies. For everyone else it's a benchmark, and we'd use it as yours.
NVD lists an 8.1 High score from MITRE with high attack complexity, which is why the setup conditions below matter: the bug needs a specific configuration. Its record says that for some account setups, any password between 256 and 1024 characters gets in. CISA's own assessment in that record: exploitation active, not automatable.
Alpine's advisory names four conditions, all at once:
- sshd comes from
openssh-serverwithout PAM, or fromopenssh-server-pamwithUsePAM no. PasswordAuthenticationis on, which is OpenSSH's default.- At least one account has
*in its password field. - At least one other account has a
$5$or$6$password hash.
Most Alpine hosts meet condition 3 by default: root ships as root:*, and so do key-only users. Root itself is reachable only if PermitRootLogin yes is set, since the default is prohibit-password, but a key-only admin user works as the target. So what decides your exposure is whether password login is on and whether any user has a $5$ or $6$ hash.
Alpine lists what's not affected: containers that don't run sshd, PasswordAuthentication no, openssh-server-pam with UsePAM yes, and cloud-init images that switch password login off. If none of your hosts run sshd on Alpine or another musl build without PAM, you're done with the bug. The ownership audit below is still worth a week.
Where does an Alpine sshd hide in a product company?
Alpine's advisory says what's affected, not where teams run it. These are the places we'd look first.
Bastions, jump boxes and VMs someone installed from the Alpine ISO
Alpine's installer scripts, run through setup-alpine, offer openssh, dropbear or none for the SSH server. Someone who picked openssh on a bastion years ago got the default package and the default password setting. Run sshd -T on the box to see what's actually on.
Containers
The official alpine image on Docker Hub is built around musl libc and BusyBox. A container is exposed only if someone added openssh-server, usually in a debug image or a CI runner image. If you find one, remove sshd rather than hardening it.
Cloud images
Alpine's official tiny-cloud images ship an alpine user with no password and passwordless doas. They're safe on first boot and become exploitable once any account gets a $6$ hash. Any image or host with PasswordAuthentication no is fine.
Servers an agency or contractor runs
These are the ones we'd worry about. You can't patch what you can't name. Ask the agency for the OS release, the sshd -T output and the patch date, in writing. Our piece on answering contractor access and security questions covers how to ask for evidence.
Device images
A device image counts only if its build ships OpenSSH's sshd on musl without PAM. Alpine's advisory doesn't mention embedded systems, so check the build config for the openssh package and the libc option.
How do we check this week?
For each surface, you want a yes or no on all four conditions and a named owner.
| Surface | Check | Done when |
|---|---|---|
| Bastions and VMs | sshd -T, then the account checks below | Four conditions answered, owner named |
| Container images | Does the image install openssh-server? | sshd removed or owner named |
| Cloud images | Image version and sshd -T after first boot | Password login confirmed off |
| Agency or contractor hosts | Written OS release, sshd -T output, patch date | Evidence received or host treated as exposed |
# run as root
sshd -T | grep -i passwordauthentication
sshd -T | grep -i usepam
apk info -e openssh-server
apk info -e openssh-server-pam
awk -F: '$2 == "*" {print $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadowThe first line shows the effective password setting. The usepam line prints only on PAM builds, so no output means sshd was built without PAM. The next two tell you which server package is installed, which answers the PAM half of condition 1. The last two list accounts with a * password field and accounts with $5$ or $6$ hashes.
Patch, or turn passwords off first?
Turn passwords off first, then patch. It needs no package change, and it's Alpine's own workaround.
- Confirm key login works for the accounts you need, and keep one session open.
- Set
PasswordAuthentication noand restart sshd. Confirm withsshd -T. - Run a full package upgrade on your Alpine release (fixed
opensshpackages exist back to 3.16), or build from Alpine 3.21.10, 3.22.8, 3.23.8, 3.24.4 or later. Where you build OpenSSH yourself, use 10.6p2, released on 5 November. - Restart sshd again. Alpine warns that upgrading the package doesn't restart a running sshd.
- Rebuild images from fixed bases.
Then triage, because CISA marks this one for forensic review. On Alpine hosts, search /var/log/messages for sshd "Accepted password" lines for passwordless accounts, and look for new users, doas use and changed authorized_keys. Alpine's advice is blunt: if you can't rule a login out, treat the machine as compromised.
Should password SSH exist at all?
No, not on anything reachable. Keys-only removes this bug and any other flaw that needs password login, and it's the default we'd set for every new host.
Break-glass access is a policy question. If you need a password route, put it on the console behind your cloud provider's access controls, with a named approver. Don't leave it on a network-reachable sshd.
Worked example: a 40-engineer company audits in two days
Say a 40-engineer company, call it Pagebase, runs its product on managed cloud. It also has a bastion host built from the Alpine installer by a former platform engineer, a CI runner image someone added openssh-server to for debugging, and a customer-facing staging VM an agency built (illustrative).
The bastion runs Alpine with openssh-server without PAM and password login on by default. It has a key-only admin user with * and one other user with a $6$ hash. All four conditions are true, so it's exposed, and the platform lead owns it.
The CI image has sshd but only inside the runner network, and no $5$ or $6$ hash exists, so condition four fails. Remove sshd anyway. The CI owner takes it.
The agency VM gave no answer after a day. Treat it as exposed until the sshd -T output arrives in writing. The agency account manager owns the request.
Three hosts, three named owners, one policy: keys only.
What this means for who owns host access
Name one person who owns host access across product, platform and agencies, and make them answer for every sshd engineering didn't consciously build. If that name doesn't come to mind in ten seconds, the audit above is your finding, not the CVE.
Get written answers from agencies and contractors by the 12th, and set the policy: keys only, no exceptions without an approver. Budget for repeat work. OpenSSH says it will make more frequent releases for now instead of batching fixes, so the patch calendar is weekly, not quarterly.
For more on exploited vulnerabilities and platform changes, the theme hub tracks what to fix next.
FAQ
Is CVE-2026-123158 exploited in the wild?
Yes. CISA added it to the KEV list on 9 November based on evidence of active exploitation, and NVD's record carries CISA's assessment of exploitation as active. CISA lists ransomware use as unknown, so don't assume a specific attacker.
Does CVE-2026-123158 affect Docker containers?
Only if the container runs sshd. Alpine lists containers that don't run sshd as not affected. Check any debug or CI image where someone installed openssh-server.
Which OpenSSH version fixes CVE-2026-123158?
OpenSSH 10.6p2, released on 5 November. On Alpine, run a full package upgrade on your release, or build from Alpine 3.21.10, 3.22.8, 3.23.8, 3.24.4 or later, and restart sshd, because upgrading doesn't restart a running one.
Is OpenSSH safe to use?
This flaw needs musl without PAM, password login on, and the right accounts. Hosts with password login off aren't exposed. We'd turn password login off on anything reachable anyway, since it removes this bug and any other flaw that needs password login.
Does the CISA due date apply to my company?
No. BOD 26-04 binds US federal civilian agencies. For everyone else, 12 November is a sensible benchmark, since exploitation is confirmed.