Is your Alpine OpenSSH server exposed to the password login bypass?
Yes, if all four hold: PAM off (Alpine default), PasswordAuthentication yes, an account with password field *, and another with a $5$ or $6$ hash. Rate High, CVSS 3.1 8.1 (CVE-2026-123158). Fix with OpenSSH 10.6p2 or Alpine's backport, then restart sshd. Tiny Cloud is safe until a $6$ hash appears on the host.
CVE-2026-123158, CVSS 3.1 8.1 High, not in CISA KEV
MITRE rates CVE-2026-123158 CVSS 3.1 8.1 High. OpenSSH's 10.6p2 release notes say the release contains a critical security workaround for musl with PAM disabled; OpenSSH only called the workaround critical, and we rate the issue High (8.1). It is not in CISA's Known Exploited Vulnerabilities catalogue (catalog 2026.11.04 predates the CVE). No primary source reports exploitation. Upgrade and restart sshd, or disable password authentication now.
By Simon Phillips, CTO. Reviewed by Oliver Legg, Head of SOC and IR. Last updated 5 November 2026, 18:50 GMT.
At a Glance
Based on the Alpine advisory, OpenSSH 10.6p2 release notes and CVE-2026-123158 as of 5 November 2026. Last updated 5 November 2026, 18:50 GMT.
High, CVSS 3.1 8.1
MITRE CVE-2026-123158. OpenSSH calls 10.6p2 a critical security workaround.
Not in KEV
Catalog 2026.11.04 predates the CVE. No primary exploitation reports.
musl, PAM off
Alpine by default. OpenWrt, Buildroot and Yocto are unverified.
Upgrade + restart
OpenSSH 10.6p2 or Alpine backport, then restart sshd.
OpenSSH releases 10.6p2; notes describe a critical security workaround for musl without PAM.
Alpine publishes its openssh-server advisory and fixed packages back to 3.16.
MITRE publishes CVE-2026-123158 at 15:46 GMT (CVSS 3.1 8.1 High).
Not in CISA KEV (catalog 2026.11.04). No primary source reports exploitation.
Affected and fixed
| Scope | Status | Action |
|---|---|---|
| Alpine openssh-server (PAM off), PasswordAuthentication yes | Affected when * and $5$/$6$ accounts exist | apk upgrade -U -a, then restart sshd |
| Alpine 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later point releases | Fixed package included | Confirm the package version, then restart sshd |
| edge and 3.16 to 3.24 fixed openssh packages | Fixed in-branch (backports) | edge ships 10.6_p2-r0; stable branches carry a backport, not always 10.6p2 itself |
| OpenSSH 10.6p2 and later | Fixed upstream | OpenSSH describes 10.6p2 as containing a critical security workaround for musl without PAM |
| glibc distros (Debian, Ubuntu, Fedora) and sshd with UsePAM yes | Not affected | Still prefer PasswordAuthentication no where you can |
| OpenWrt, Buildroot, Yocto shipping OpenSSH without PAM | Unverified | Not named in Alpine or OpenSSH primary sources; treat as possible until you confirm libc and PAM |
Are you exposed? All four must be true
- PAM off: Alpine's default
openssh-server(no PAM), oropenssh-server-pamwithUsePAM no. - PasswordAuthentication yes: the OpenSSH default unless you changed it. cloud-init images that set
noare not exposed. - An account with
*: no password set. Includes defaultrootsince about Alpine 3.16 (still protected byPermitRootLogin prohibit-passwordunless set toyes), key-only users, directory users without a shadow entry, and the Tiny Cloudalpineuser. - A
$5$or$6$hash somewhere: one local password hash is enough to make every*account reachable with a 257 to 1,024 byte password.
Official Tiny Cloud images (3.18.11 to 3.24.3) are safe until a $6$ hash appears on the host (safe on first boot). Once any $6$ hash exists, the alpine user with passwordless doas can reach root. apk upgrade alone is not enough; you must restart sshd.
What to Do in the Next 24 Hours
Proactive on the left. Reactive on the right. Tick both tracks.
Inventory, key-only, upgrade
- Inventory every Alpine host and image that runs sshd, especially Tiny Cloud VMs and bastions; treat OpenWrt, Buildroot and Yocto as unverified until you confirm libc and PAM.
- Move those hosts to key-only login (
PasswordAuthentication no) and confirm withsshd -T | grep -i passwordauthentication(edit the main sshd_config on Alpine before 3.19). - Upgrade (OpenSSH 10.6p2 or Alpine's backported package), then restart sshd; apk upgrade alone is not enough.
- Confirm the package version, and remember Tiny Cloud is safe on first boot until any
$6$hash exists;alpineplus passwordlessdoascan then reach root.
Hunt and contain
- Search sshd logs for
Accepted password foron accounts that should not have a password (alpine,root, key-only users). - Treat any such login as compromise: rotate credentials and keys, review doas/sudo, new users, authorized_keys and persistence.
- Rebuild from a known good image if you cannot clear the host.
- Keep monitoring for further password logins and privilege escalation.
Proactive: Check Exposure and Fix
Find every Alpine sshd first. Go key-only, then upgrade and restart.
Inventory Alpine and musl sshd hosts
List every Alpine host and image that runs sshd, especially cloud VMs, bastions and Tiny Cloud artifacts. OpenWrt, Buildroot and Yocto are not named in the primary sources; confirm libc and PAM before you treat them as clear. For each host, record whether PAM is in use, PasswordAuthentication, and whether any account has a * password field.
# Is password auth still on?
sshd -T | grep -i passwordauthentication
# Alpine openssh package version
apk info -v openssh openssh-server 2>/dev/null || true
# Accounts with no password (*) and any $5$/$6$ hashes
awk -F: '$2=="*" {print "star:",$1}' /etc/shadow
awk -F: '$2 ~ /^\$5\$|^\$6\$/ {print "hash:",$1}' /etc/shadowGo key-only where you can
Confirm SSH key login works and keep your current session open. Set PasswordAuthentication no, test the config, restart sshd and confirm with sshd -T. Alpine's drop-in under /etc/ssh/sshd_config.d/ is only read from Alpine 3.19 onward; older releases need the main sshd_config edited. See the Alpine advisory.
mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
-e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
/etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication
# Note: the drop-in is only read from Alpine 3.19 onward.Upgrade, then restart sshd
On Alpine run apk upgrade -U -a, then restart sshd with rc-service sshd restart. apk upgrade alone is not enough: it does not replace the running daemon. Stable branches often carry a backported package rather than 10.6p2 itself. Upstream, install OpenSSH 10.6p2. Point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fixed package. See the OpenSSH 10.6p2 release notes.
apk upgrade -U -a
rc-service sshd restart
# Confirm package version matches your branch's fixed release
apk info -v opensshConfirm the effective setting
After the change, run sshd -T | grep -i passwordauthentication and confirm it prints passwordauthentication no, or confirm the installed openssh package matches the fixed version for your Alpine branch.
Review Tiny Cloud alpine and passwordless doas
Official Tiny Cloud images (3.18.11 to 3.24.3) ship an alpine user with a * password field and passwordless doas. They are safe until a $6$ hash appears on the host. After you close the hole, review who can use doas/sudo.
Free Detection Pack
Built by the CybaVerse threat hunt team for businesses, internal IT teams and MSPs. Check each host's exposure offline and hunt for signs of abuse. Everything is read-only.
check-openssh-musl-bypass.sh
Offline exposure checker. Reads package metadata, sshd settings, shadow and doas rules under a root you point it at, and reports whether the four conditions hold. Optional auth log scan for Accepted password for on key-only accounts.
bash check-openssh-musl-bypass.sh --root /
# Whole estate (CSV inventory)
bash check-openssh-musl-bypass.sh --csv inventory.csvCheck-OpenSSHMuslBypass.ps1
The same checks in PowerShell 7, with the same output and exit codes. It also runs under PowerShell on Linux.
pwsh -File Check-OpenSSHMuslBypass.ps1 -Root /KQL and Sigma
8 KQL queries for Microsoft Sentinel and Defender XDR: Accepted password for key-only accounts, first-try password success, DeviceLogonEvents, CommonSecurityLog, authorized_keys/doas/sudoers changes, doas execution, OpenSSH inventory versus fixed versions, and Alpine/embedded scope. 3 Linux Sigma rules cover the same ground for other SIEM platforms, with Kusto conversions included.
Verdicts
- PATCHEDFixed package or OpenSSH 10.6p2 or later. Reminds you to restart sshd if it was running before the upgrade.
- LIKELY VULNERABLEUnfixed version with all four conditions holding.
- UNKNOWNMissing inputs so exposure cannot be ruled out.
- NOT EXPOSEDPasswordAuthentication no, PAM on, no
*account, or no$5$/$6$hash. Still upgrade.
Exit codes
| Code | Meaning |
|---|---|
| 0 | PATCHED |
| 1 | LIKELY VULNERABLE |
| 2 | UNKNOWN |
| 3 | NOT EXPOSED |
| 4 | SUSPICIOUS LOGIN in auth log |
| 5 | Error, such as bad usage or an unreadable file |
MSPs can use the exit code in RMM or scheduled jobs to flag hosts at scale. With a CSV, the exit code is the worst row. Exit 4 overrides when the auth log has a hit.
Know the limits
- Both checkers are read-only and offline. They only read the files you point them at, send no network traffic, write nothing and contain no exploit payloads.
- No indicators of compromise have been published, and the pack contains none. The hunts look for behaviour.
- OpenWrt, Buildroot and Yocto are unverified: they are not named in the Alpine or OpenSSH primary sources.
- None of the KQL has been run against a live tenant. Fields and paths marked UNVERIFIED depend on your connectors. Prefer the hand-written KQL over Sigma conversions where they disagree.
- sshd does not log password length, so there is no log query for the 257 to 1,024 byte attempt itself.
What is in the pack
| File | What it does |
|---|---|
| check-openssh-musl-bypass.sh | Offline exposure checker for Linux and macOS (bash) |
| Check-OpenSSHMuslBypass.ps1 | The same checker in PowerShell 7 |
| KQL (8 queries) | Microsoft Sentinel and Defender XDR hunts Q1 to Q8 |
| Sigma (3 rules) | Linux sshd, file and doas rules, plus Kusto conversions |
| tests/ | Fixtures, bash and Pester tests and a sandboxed no-network run |
| README.md | Verified facts, corrections, limits and usage |
Reactive: How to Hunt
No indicators of compromise have been published. Hunt for password logins on accounts that should not accept them. CybaOps can run these hunts across your estate or your clients'.
Accepted password for key-only accounts
Search sshd logs for Accepted password for against accounts that should have no password: alpine, root, and any key-only user (KQL Q1 to Q4 and the Sigma sshd rule). On Alpine, start with /var/log/messages. Cross-check the password field in /etc/shadow; a * field with a password accept is a strong signal.
Privilege escalation after login
Review doas and sudo use, especially passwordless rules for the alpine user on Tiny Cloud images (KQL Q6). Look for new local users, changes to group membership and unexpected root shells around the same time.
Persistence and keys
Inspect authorized_keys, new SSH host or user keys, cron jobs, startup services and recently modified binaries or configs under /etc and home directories (KQL Q5 and the Sigma file rules).
Inventory and lateral movement
Use the OpenSSH inventory hunt (KQL Q7) against fixed versions for your Alpine branch. From any host with a suspicious password accept, check outbound SSH and access to secrets that account could reach.
If you suspect compromise
- Isolate the host and keep its logs and disk for investigation.
- Rotate credentials, SSH keys and any secrets that account could reach. Do not keep an exposed key as a fallback.
- Review
doas/sudo, new users,authorized_keysand persistence. - Rebuild from a known good image where you cannot clear the host with confidence.
- Upgrade openssh (or disable password authentication), restart sshd, and keep monitoring.
Upgraded does not mean clean
Restarting a fixed sshd stops new password bypasses. It does not undo a login that already happened. Every exposed host should be hunted, not just upgraded.
OpenSSH Alpine Password Bypass FAQ
Short answers based on the Alpine advisory, OpenSSH release notes and CVE-2026-123158 as of 5 November 2026.
What is the OpenSSH Alpine password login bypass?
When sshd is built and run without PAM on musl Linux, a password between 257 and 1,024 bytes can succeed against an account whose stored password field is * (no password set). musl's crypt() returns * as an error for oversized keys, which matches the stored field. One other account with a $5$ or $6$ hash is enough to make every * account reachable.
Does it have a CVE?
Yes. MITRE published CVE-2026-123158 on 5 November 2026 at 15:46 GMT (CVSS 3.1 8.1 High). Alpine's advisory, posted earlier the same day, said no CVE had been assigned at the time of writing. OpenSSH's 10.6p2 release notes describe the release as containing a critical security workaround for Linux systems that use musl libc with PAM disabled; that is OpenSSH's wording, not a separate score.
Is it being exploited?
No primary source reports exploitation. CVE-2026-123158 was not in CISA's Known Exploited Vulnerabilities catalogue when we checked on 5 November 2026 (catalog 2026.11.04, which predates the CVE). Do not wait for KEV: upgrade and restart sshd, or disable password authentication now.
Are Debian and Ubuntu affected?
No. Debian, Ubuntu and other glibc distributions are not in scope of the musl-without-PAM path OpenSSH describes, and neither is sshd with UsePAM yes. OpenWrt, Buildroot and Yocto are not named in the Alpine or OpenSSH primary sources; builds that ship OpenSSH without PAM on musl are unverified and should be checked.
Do I need to restart sshd after upgrading?
Yes. On Alpine, apk upgrade -U -a alone is not enough: the upgrade does not replace the running daemon. You must run rc-service sshd restart (or equivalent) after the package update. Alpine stable branches often carry a backported package rather than 10.6p2 itself; still restart after the upgrade.
Who is affected on Alpine?
All four must be true: PAM is off (Alpine's default openssh-server, or openssh-server-pam with UsePAM no); PasswordAuthentication is yes; at least one account has * as its password field; and at least one other local account has a $5$ or $6$ hash. Official Tiny Cloud images from 3.18.11 to 3.24.3 ship an alpine user with passwordless doas. They are safe until a $6$ hash appears on the host (safe on first boot).
Can root be reached with a password login?
Default root is protected by PermitRootLogin prohibit-password, even when root's password field is *. Root is only reachable with password login if PermitRootLogin is set to yes. Tiny Cloud still reaches root through the alpine user plus passwordless doas once the four conditions hold and a $6$ hash exists.
How do we fix it on Alpine?
Run apk upgrade -U -a, then restart sshd with rc-service sshd restart. apk upgrade alone is not enough. Fixed packages are on edge and 3.16 to 3.24; point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fix. Upstream, install OpenSSH 10.6p2 or later.
We cannot upgrade today. What is the workaround?
Confirm key-based login works and keep your current session open. Set PasswordAuthentication no and restart sshd. Alpine's drop-in under /etc/ssh/sshd_config.d/ is only read from Alpine 3.19 onward; older releases need the main sshd_config edited (Alpine's advisory includes a sed that also covers Match blocks). Confirm with sshd -T | grep -i passwordauthentication.
How do we know if we were attacked?
Search logs for Accepted password for on accounts that should not have a password (alpine, root, or any key-only user). On Alpine, check /var/log/messages. If you cannot rule a login out, treat the host as compromised: rotate credentials and keys, review doas/sudo, new users, authorized_keys and persistence, and rebuild if you are unsure.
Protect Your Linux Estate, and Your Clients'
CybaOps monitors your servers, endpoints and cloud workloads, whether that's your own business or your clients'. UK-based analysts monitor alerts 24/7, run these threat hunts and act on pre-approved response actions, and CybaOps drives remediation through to a verified fix, so proactive checks and reactive response happen in one place.
Sources
- Alpine Linux: Security advisory, openssh-server password authentication bypass (5 November 2026)
- OpenSSH: Portable OpenSSH 10.6p2 release notes
- CVE.org: CVE-2026-123158
- NVD: CVE-2026-123158
- BleepingComputer: OpenSSH flaw lets attackers log into password-disabled Linux accounts
Related threat guides: Rails Active Storage and Linux KSMBD. All threat guides.