SSHole – CVE-2026-123158

On 5 November 2026, the OpenSSH project released version 10.6p2 of its portable edition, presented as a critical security workaround. It blocks a password authentication bypass in the sshd server, named sshole by its discoverer, Özgün Kültekin, of the company Wakefield. CVE (1) CVE-2026-123158 was published the same day at 15:46 UTC (2) by MITRE, acting as CNA (3).

The flaw affects Linux systems whose C library is musl and whose SSH (4) server checks passwords without going through PAM (5). Alpine Linux is the main example: its openssh-server package is built without PAM, and password authentication remains enabled by default. On these systems, an account with no password, that is an account whose password field is * in /etc/shadow, accepts any password between 257 and 1,024 bytes long as soon as another local account holds a SHA (6) hash of type $5$ or $6$. The accounts at risk are those reserved for key-based authentication, users coming from a directory service and, on Alpine’s official cloud images, the alpine user, which can become root through doas without a password.

Alpine Linux’s advisory describes an attack in a single connection, successful every time, with no retries. The CVE record gives a CVSS (7) 3.1 score of 8.1, high severity, with high attack complexity; OpenSSH uses the qualifier “critical” without publishing a score. The project places the root cause outside sshd, in the behaviour of musl’s crypt() function, but ships the fix in sshd, where the flaw is exploitable.

Not affected, according to OpenSSH, Alpine and the researcher: non-Linux systems, glibc-based Linux distributions such as Debian, Ubuntu or Fedora, systems that check passwords through PAM, and the Dropbear SSH server.

The flaw arises from the meeting of independent technical choices, made by two projects four years apart, followed by an Alpine configuration change in 2022. The researcher reconstructs its history on sshhole.com and in the GitHub repository that accompanies the publication.

Fig. 1. Timeline reconstructed from the OpenSSH release notes, Damien Miller’s announcement, the Alpine Linux advisory, the CVE record, sshhole.com and the TIMELINE.md file of the oz9un/sshole repository, The Hacker News and Help Net Security.

A one-day gap remains on the date of the report. The researcher dates it to 3 November; in his message of 5 November, Damien Miller states that the team learned of the problem “yesterday”. The Alpine advisory and The Hacker News article of 5 November state that no CVE identifier had been assigned at the time of writing; the record was published the same day.

Discovery method

The researcher states that he built sshd in every combination he could think of (glibc or musl, with or without PAM, with or without a shadow file) and submitted around 17,600 unusual login attempts to these builds: malformed hashes, inconsistent accounts, very long passwords. Every build returned the same decision for every attempt, except the musl build without PAM. He adds that he worked with swarms of AI (11) agents. His repository mentions a test bench of 17 environments, including a cloud image under QEMU, OpenWrt, Buildroot and directory users, whose detail has not been published.

The OpenSSH 10.6p1 and 10.6p2 release notes observe that flaws identified by AI tools are subsequently rediscovered independently by other researchers, and announce more frequent releases. Damien Miller adds that the team now considers long embargo periods a dangerous practice that mainly benefits attackers, after several cases of rapid rediscovery by AI agents, sometimes within hours.

Credits

The report is credited to Özgün Kültekin, of Wakefield. Alpine thanks Damien Miller and Darren Tucker, of OpenSSH, for the fix and the 10.6p2 release, Timo Teräs for help with the analysis and Natanael Copa for building and uploading the packages.

When built without PAM, sshd checks a password itself in the sys_auth_passwd() function: it computes the hash of the submitted password with crypt(), reusing the salt of the stored hash, then compares the result with the stored field using strcmp(). Equality means authentication. An account with no password carries * in this field; since no hash can equal *, this account in principle refuses any password authentication.

The * field is too short to contain a salt. Since the fix for CVE-2016-6210 in 2016, sshd then borrows, through the pick_salt() function, the salt of another account on the system whose hash starts with $, so that the response time does not reveal the absence of a usable hash. The submitted password is therefore hashed with a third-party account’s salt, then compared with *.

For the $5$ (SHA-256) and $6$ (SHA-512) types, musl’s crypt() function refuses any key longer than 256 bytes and returns the string * as an error indicator. This string is identical to the stored field of the account with no password: strcmp() reports equality and sshd accepts the connection. The upper bound of 1,024 bytes is the maximum password length accepted by sshd, set by the MAX_PASSWORD_LEN constant.

Fig. 2. Sequence described by the Alpine Linux advisory and the oz9un/sshole repository, cross-checked against the code changed by commit 4353fdc.

Why other configurations escape the flaw

• with PAM, the check goes through the PAM module, which, according to the researcher, does not call crypt() for a * field
• with glibc, distributions go through PAM; the researcher also notes that libxcrypt, adopted by Debian, returns *0 on failure, a value that does not match *
• an account locked with ! does not match * and stays closed, according to the Alpine advisory
• with no $-type hash on the machine, no $5$ or $6$ salt can be borrowed, and the computation does not go through musl’s SHA functions that carry the 256-byte limit; the Alpine advisory excludes these systems, and the researcher specifies that a fresh system with no password set is not exposed

The Alpine advisory sets four cumulative conditions on the machine, to which the attacker’s side adds network access to the SSH port and the name of an account with no password. A single account with a password is enough to make every account without one reachable.

Fig. 3. Exposure conditions according to the Alpine Linux advisory of 5 November 2026, supplemented by the oz9un/sshole repository for locking with !.

Accounts at risk

• root, shipped as root:* in the base image since about Alpine 3.16; the default value PermitRootLogin prohibit-password protects it, unless PermitRootLogin yes is set. This protection does not hold if another exposed account can become root, for example through doas
• accounts reserved for key-based authentication, created with adduser without a password or with usermod -p '*'
• users coming from a directory service through musl-nscd (nslcd, winbind, sssd), which have no entry in the shadow file
• the alpine user of the official tiny-cloud cloud images, which has passwordless doas

tiny-cloud cloud images

The official tiny-cloud images from versions 3.18.11 to 3.24.3 ship an alpine user with a * field, allowed to use doas without a password. They are not exposed at first boot. They become exposed as soon as a $6$ hash exists on the machine, for example when an administrator sets a console password or when user data creates an account with hashed_passwd. The attacker then gets a shell as alpine, then root privileges through doas. The researcher and Cyber Press cite the official images for Amazon Web Services and Azure. Images built from versions 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package; instances launched from an earlier image must be updated individually.

Beyond Alpine

The researcher cites other musl-based systems to examine: OpenWrt, Buildroot, Yocto, postmarketOS, Void in its musl variant and Chimera. OpenWrt uses Dropbear by default; the flaw only concerns installations where an administrator has added the OpenSSH server, as The Hacker News points out. TheCyberThrone extends the inventory to cloud instances, containers, network appliances and embedded Linux environments.

For containers, the Alpine advisory specifies that those that do not run sshd are not affected. The researcher points out that many Docker images rely on musl; exposure depends on the presence of a listening sshd. Cyber Press likewise stresses that running a musl distribution or an Alpine container is not enough to establish exposure.

The researcher’s repository states that the PoC (12) works at least as far back as Alpine 3.18, and that the oldest combination tested, OpenSSH 7.5p1 on musl 1.1.16 in 2017, is also vulnerable. The flaw has existed since salt borrowing was introduced in OpenSSH 7.3p1, in 2016.

Impact

The attacker obtains a session with the privileges of the targeted account, within the limits of the access controls specific to sshd. The bypass affects neither the protocol’s encryption nor existing passwords. On vulnerable tiny-cloud images, the alpine account gives access to root privileges; on a machine where PermitRootLogin yes is set, the root account is directly reachable.

The CVE record declares OpenSSH before version 10.6p2 on the Linux platform as affected, with a default status of “unaffected” for other versions. Its description restricts the flaw to systems using musl without PAM. The weakness listed is CWE (13) 394, unexpected status code or return value. The record carries the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, score 8.1.

Alpine Linux fixed packages

Fig. 4. Fixed versions of the openssh package by branch, according to the Alpine Linux advisory of 5 November 2026. Point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 contain the fixed package.

The update is done with apk upgrade -U -a, followed by a service restart with rc-service sshd restart. For a build from source, OpenSSH version 10.6p2 carries the change; the researcher provides the upstream patch unchanged in his repository and states that it applies to every version since 7.3p1.

Commit 4353fdc, titled “avoid password authn bypass”, changes three files: auth-passwd.c, openbsd-compat/port-uw.c and openbsd-compat/xcrypt.c, with 34 lines added and 17 removed. Its message restates the project’s position: the root cause is not considered internal to OpenSSH, but the project is in a position to avoid it.

• a MIN_PASSWORD_HASH_LEN constant, set to 4, is introduced in auth-passwd.c: the comparison only succeeds if the stored field is at least four characters long, which excludes *
• shadow_pw() now returns a copy of the password field, obtained with xstrdup(), instead of a pointer into the C library’s static buffer; the copy is wiped with freezero() after use
• pick_salt() frees and wipes each intermediate copy while iterating over the accounts

The researcher sums up the effect: sshd no longer performs the comparison when the stored field is too short to be a real hash, and stops using a pointer into the C library’s static buffer. The packages of Alpine’s stable branches carry a patch addressing the same problem.

Version 10.6p2 also includes functional fixes already present on the V_10_6 stable branch, among them acceptance of the post-quantum hybrid signature algorithm ssh-mldsa44-ed25519 as a certificate authority signature algorithm and a fix for CPU consumption related to ChannelTimeout.

OpenSSH, Alpine and the researcher converge: disabling password authentication fully closes the attack path. Damien Miller asks to set PasswordAuthentication=no or to disable SSH immediately on the systems concerned. The Alpine advisory details the procedure, to be run as root after checking that key-based authentication works, keeping the current session open until a new login succeeds:

• 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, which should print passwordauthentication no

The drop-in configuration file is only read by Alpine’s default configuration from version 3.19 onwards; earlier versions ignore it, hence the sed command. It replaces yes with no on every PasswordAuthentication line of /etc/ssh/sshd_config, including inside a Match block, adds the directive at the top of the file and keeps the original as /etc/ssh/sshd_config.bak. To roll back, delete /etc/ssh/sshd_config.d/00-no-passwords.conf and restore /etc/ssh/sshd_config.bak.

TheCyberThrone adds restricting SSH access to trusted network sources and reviewing accounts intended for key-only authentication. Locking these accounts with ! is not an alternative on a system without PAM: it also blocks key-based authentication, which is why Alpine abandoned this value for root in 2022.

Disclosure took place without a long embargo. According to the researcher, the flaw was reported on 3 November, Alpine and musl were notified on the 4th, and the fixed release came out on 5 November, together with Alpine’s packages and the explanatory page sshhole.com. The researcher’s repository published the same day a verification script, a PoC reproducible in a Docker container and the patch. The PoC sends a first arbitrary password, then a 300-character string; the attack.py script shows rejection at 256 characters and success at 257.

Findings on exploitation differ by date and source, and should be kept apart:

• on 5 November, The Hacker News stated that no attacks exploiting the flaw had been reported
• on 6 November, Help Net Security reported Previdian’s observations: a first attempt less than nine hours after the CVE was published, then root access confirmed on a honeypot running a real Alpine and OpenSSH installation; eight attempts in total, all from a single IP (15) address located in Japan and caught by a single sensor
• according to Previdian, the attacker used oversized passwords, then ran the reconnaissance commands id, uname and hostname in non-interactive SSH sessions
• Previdian added the vulnerability to its own catalogue of exploited vulnerabilities; CISA had not added it to its KEV (16) catalogue according to Help Net Security
• CISA’s SSVC assessment in the CVE record, updated on 6 November at 04:56 UTC, gives exploitation at PoC stage, exploitation not automatable and total technical impact
• PoCs are published on GitHub; the CVE record references two reproduction repositories in addition to the researcher’s. Previdian warns that PoCs published on GitHub are unverified and may contain malware
• no attribution to an actor has been made public

Checking a machine’s exposure

The check.sh script in the oz9un/sshole repository checks the five conditions: C library, sshd build with or without PAM, value of PasswordAuthentication, accounts with a * field and presence of a $5$ or $6$ hash. It reports the missing condition when the machine is not exposed. The same checks can be run by hand on Alpine, as root:

• installed package version, to compare with figure 4: apk info -v openssh
• server variant installed: apk info -e openssh-server openssh-server-pam
• effective value of password authentication: sshd -T | grep -i passwordauthentication
• accounts with a * field: awk -F: '$2=="*"{print $1}' /etc/shadow
• accounts with a $5$ or $6$ hash: awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow

Users coming from a directory service through musl-nscd have no entry in /etc/shadow and therefore do not appear in these lists, although they are exposed according to the Alpine advisory.

Looking for a compromise

The Alpine advisory recommends searching /var/log/messages for sshd lines of the form Accepted password for naming an account with no password, such as alpine, root or an account reserved for key-based authentication, for example with grep 'Accepted password for' /var/log/messages. On exposed machines, it also recommends reviewing doas use and recently created accounts, files and authorised keys. If a login cannot be ruled out, the machine should be treated as compromised. The oversized password travels inside the encrypted SSH channel: its length cannot be observed on the network, and the search relies on the machine’s logs.

Published indicators

Fig. 5. Indicators made public as of 6 November 2026. The address is defanged with brackets.

The OpenSSH release notes and commit, Damien Miller’s announcement, the Alpine Linux advisory, the CVE record, sshhole.com and the researcher’s repository are primary sources, read in full. The Hacker News, Help Net Security, Cyber Press and TheCyberThrone are specialist press sources; the Reddit discussion is a community source.

1. CVE (1): Common Vulnerabilities and Exposures, the public identifier assigned to a vulnerability.
2. UTC (2): Coordinated Universal Time.
3. CNA (3): CVE Numbering Authority, an organisation authorised to assign CVEs and publish their records; here, MITRE.
4. SSH (4): Secure Shell, an encrypted protocol for remote administration and file transfer.
5. PAM (5): Pluggable Authentication Modules, the modular authentication interface of Unix and Linux systems.
6. SHA (6): Secure Hash Algorithm, a family of hash functions; the $5$ and $6$ types of crypt() rely on SHA-256 and SHA-512.
7. CVSS (7): Common Vulnerability Scoring System, the system used to rate the severity of vulnerabilities.
8. ADP (8): Authorized Data Publisher, an organisation authorised to enrich a CVE record with additional data.
9. CISA (9): Cybersecurity and Infrastructure Security Agency, the United States cybersecurity and infrastructure security agency.
10. SSVC (10): Stakeholder-Specific Vulnerability Categorization, a vulnerability prioritisation method based on decision points.
11. AI (11): Artificial Intelligence.
12. PoC (12): Proof of Concept, code demonstrating that exploitation is feasible.
13. CWE (13): Common Weakness Enumeration, a classification of software weaknesses.
14. CPE (14): Common Platform Enumeration, a standardised naming scheme for products and versions, used by vulnerability management tools.
15. IP (15): Internet Protocol, the addressing protocol of the Internet.
16. KEV (16): Known Exploited Vulnerabilities, CISA’s catalogue of vulnerabilities whose exploitation has been observed.

1. OpenSSH, OpenSSH 10.6p2 Release Notes, 5 November 2026. openssh.org/releasenotes
2. Damien Miller, urgent security release: 10.6p2, openssh-unix-dev list, 5 November 2026. marc.info
3. OpenSSH Portable, commit avoid password authn bypass, 4353fdc, 5 November 2026. github.com/openssh/openssh-portable
4. Alpine Linux, Security advisory: openssh-server password authentication bypass, 5 November 2026. alpinelinux.org
5. CVE Program, record CVE-2026-123158, CNA MITRE, published 5 November 2026, updated 6 November 2026, JSON record from the cvelistV5 repository. github.com/CVEProject/cvelistV5
6. Özgün Kültekin, *sshole, 5 November 2026. sshhole.com
7. Özgün Kültekin, oz9un/sshole repository: README, TIMELINE.md, check.sh, PoC and patch, November 2026. github.com/oz9un/sshole
8. The Hacker News, Swati Khandelwal, OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux, 5 November 2026. thehackernews.com
9. Help Net Security, Sinisa Markovic, OpenSSH flaw exploited in the wild just hours after disclosure (CVE-2026-123158), 6 November 2026. helpnetsecurity.com
10. Cyber Press, Tamilselvan, Critical OpenSSH Authentication Bypass Lets Hackers Log In Without Knowing Passwords, 6 November 2026. cyberpress.org
11. TheCyberThrone, PravinKarthik, SSHole: OpenSSH Authentication Bypass, CVE-2026-123158, 6 November 2026. thecyberthrone.in
12. Reddit, r/cybersecurity, discussion relaying a BleepingComputer article, 6 November 2026. reddit.com/r/cybersecurity