SSHole (CVE-2026-123158): OpenSSH Authentication Bypass on musl-Based Linux Is Under Active Exploitation

Attackers are exploiting SSHole, an authentication bypass in the OpenSSH server tracked as CVE-2026-123158. On Linux systems where OpenSSH is built against the musl C library and does not use PAM, an attacker who can reach the SSH port can log in to an account that has no password by submitting a very long one. Alpine Linux is the most widely deployed platform that fits this description.

OpenSSH released a fix in version 10.6p2 on November 5, 2026. Security firms recorded exploitation attempts the same day, and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities catalog on November 9. The vulnerability does not affect mainstream glibc-based distributions such as Debian, Ubuntu or Red Hat Enterprise Linux, so the first job for administrators is to find out whether they run the affected combination at all.

Key Facts About SSHole

  • Identifier: CVE-2026-123158, assigned by MITRE on November 5, 2026
  • Names in use: SSHole, *sshole, sshhole (all refer to the same flaw)
  • Type: Password authentication bypass in sshd; CWE-394 (Unexpected Status Code or Return Value)
  • Severity: CVSS 3.1 base score 8.1 (High), vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. The OpenSSH project describes the issue as critical.
  • Affected: OpenSSH server before 10.6p2 on Linux, linked against musl libc, with PAM not used for password checks and password authentication enabled
  • Not affected: glibc-based Linux, systems that check passwords through PAM, non-Linux systems, Dropbear
  • Fixed in: OpenSSH 10.6p2 and backported Alpine Linux packages for branches 3.16 to 3.24 and edge
  • Discovered by: Özgün Kültekin of Wakefield
  • Exploitation: Confirmed on research honeypots by GreyNoise and Previdian; listed in CISA KEV on November 9, 2026

What Is the SSHole OpenSSH Vulnerability?

OpenSSH is the software most Linux and Unix systems use for remote login. Its server component, sshd, decides whether a connecting user is allowed in. SSHole is a flaw in how that decision is made for one kind of account on one kind of system.

Linux stores each account’s password hash in the file /etc/shadow. A hash is a scrambled, one-way form of the password. When an account is not meant to have a password at all, for example an account that should be reachable only with an SSH key, administrators and distributions commonly put a single asterisk (*) in that field. No password can ever produce a hash equal to *, so password logins to that account are expected to fail every time.

SSHole breaks that expectation. On affected systems, a submitted password between 257 and 1,024 bytes long causes the password check to produce the value *, which matches the stored *, and sshd accepts the login. The content of the password is irrelevant. The Alpine Linux security team stated in its advisory that an attacker who can reach the SSH port can log in “without knowing any password”.

The flaw does not let anyone bypass an account that has a real password hash. Only accounts whose stored field is exactly * can be targeted.

Understanding CVE-2026-123158

The CVE record was published by MITRE on November 5, 2026, several hours after the fix was already public. It attributes the bypass to a “misinterpretation of whether a string is intended to be a password hash” and lists every OpenSSH version before 10.6p2 on Linux as affected when musl libc is used without PAM.

Three points about the record deserve attention:

  • Severity labels differ. The record carries a CVSS 3.1 score of 8.1, which is High. The attack complexity is rated High because several conditions outside the attacker’s control must be present. The OpenSSH 10.6p2 release notes call the change “a critical security workaround”. Both descriptions are accurate from their own viewpoint: where the conditions are met, exploitation is trivial.
  • The length range is stated slightly differently. The CVE record says passwords between 256 and 1,024 characters succeed. Alpine’s advisory and independent lab analyses give 257 to 1,024 bytes, which is consistent with musl rejecting inputs longer than 256 bytes.
  • Responsibility for the root cause is disputed. OpenSSH says the root cause lies outside sshd but can be exploited through it. musl maintainer Rich Felker wrote on the musl mailing list that it is “not a bug in musl just an erroneous use by the caller”, while confirming that musl intends to change the behaviour involved.

Disclosure Timeline

Times below are UTC and come from the public timeline maintained by GreyNoise, cross-checked against the OpenSSH, musl and CISA publications.

Background: 2012 to 2016

  • August 2012: musl changes crypt() to return * on failure and, weeks later, caps SHA-crypt password input at 256 bytes.
  • 2016: OpenSSH adds salt borrowing for accounts without a usable hash while fixing user enumeration flaw CVE-2016-6210.

Discovery and Disclosure: November 4 to 5, 2026

  • November 4: OpenSSH developers learn of the bug and commit a fix privately.
  • November 5, 09:00: Fix published; OpenSSH 10.6p2 announced. Alpine Linux ships patched packages the same day.
  • November 5, 12:19: Researcher’s technical write-up published.
  • November 5, 13:16: First public exploit code appears on GitHub.
  • November 5, 15:46: CVE-2026-123158 reserved and published.

Exploitation and Response: November 5 to 9, 2026

  • November 5 to 6: Previdian reports the first exploitation attempt, less than nine hours after CVE publication.
  • November 7, 00:46: GreyNoise records the first successful exploitation of one of its sensors.
  • November 9: CISA adds the flaw to the Known Exploited Vulnerabilities catalog with a November 12 due date for U.S. federal agencies.

OpenSSH developer Damien Miller said the project shipped the release within about a day of learning of the problem. He explained that the team has recently seen bugs rediscovered by AI agents within hours and now regards long embargo periods as a practice that mainly helps attackers. According to Help Net Security, Kültekin said he used agent swarms in his own research and tested roughly 17,600 unusual login attempts across many builds before isolating the musl, non-PAM case.

How the Vulnerability Works

The bypass results from three independent design decisions that are each defensible in isolation. The explanation below follows the analysis Rich Felker posted to the musl mailing list and the OpenSSH fix commit.

Normal SSH Password Authentication

When a client connects, the two sides first negotiate encryption keys so that everything that follows is encrypted. The client then asks to authenticate as a named user with a chosen method, such as a public key or a password.

For password authentication there are two possible paths inside sshd on Linux:

  • PAM path. PAM (Pluggable Authentication Modules) is the framework most Linux distributions use to check credentials. When sshd is built with PAM and UsePAM yes is set, the password is handed to PAM. For an account whose field is *, PAM does not reach the hashing step described below.
  • Built-in path. When PAM is not used, sshd checks the password itself. It reads the stored hash from /etc/shadow, calls the C library function crypt() with the submitted password and the stored hash as the “setting” (which carries the algorithm identifier and the salt), and compares the output with the stored hash. Access is granted only if the two strings are identical.

A salt is a random value mixed into the hash so that two users with the same password end up with different hashes. The prefix of a stored hash identifies the algorithm: $5$ means SHA-256 crypt and $6$ means SHA-512 crypt.

Decision 1: OpenSSH Borrows a Salt for Accounts Without a Hash (2016)

In 2016, OpenSSH fixed CVE-2016-6210, a flaw that let attackers work out which usernames existed by measuring how long the server took to reject a password. Hashing takes measurable time, so skipping it for accounts without a real hash leaked information. The fix made sshd perform a hash computation regardless. When the target account’s stored field is too short to contain a salt, sshd looks through the user database for the first account that has a password hash and borrows the salt from it.

The result of that computation is still compared with the target’s stored field. For a * account the developers expected that comparison could never succeed.

Decision 2: musl Returns an Asterisk When crypt() Fails (2012)

The crypt() function can fail. Different C libraries signal failure differently. According to Felker’s analysis, some return a null pointer, glibc-based distributions that use libxcrypt return tokens such as *0 or *1, and musl returns a single *. musl adopted a failure string in 2012 because many programs crashed when given a null pointer.

Decision 3: musl Limits SHA-crypt Input to 256 Bytes (2012)

SHA-256 and SHA-512 crypt become very slow as the password gets longer, which an attacker can abuse to exhaust CPU time. musl therefore treats any password longer than 256 bytes as an error for these two algorithms.

The Collision

Put together, the sequence on an affected server is:

  1. The attacker requests password authentication for an account whose stored field is *.
  2. sshd finds no salt in that field and borrows one from the first account that has a hash. That hash must be a $5$ or $6$ type.
  3. sshd calls crypt() with the attacker’s password and the borrowed salt.
  4. The password is longer than 256 bytes, so musl’s crypt() fails and returns *.
  5. sshd compares the returned * with the stored *. They are identical, so the login is accepted.

The upper bound of 1,024 bytes exists because sshd itself discards longer passwords before they reach this code.

 

sshole authentication flow

 

Felker’s argument is that a failure token is only guaranteed not to match when a program passes the account’s own hash as the setting. OpenSSH passes a different account’s hash, a use the guarantee never covered. OpenSSH’s position is that its code received a valid salt and an unexpected return value. Readers do not need to take a side to act on the result.

What the Fix Changes

OpenSSH 10.6p2 makes sshd refuse any match when the stored password field is shorter than four characters. Values such as *, ! and *0 can therefore never be treated as a matching hash, whatever crypt() returns. The commit also changes how the shadow entry is held in memory. Felker has said musl will separately move to the *0/*1 convention in an upcoming release.

How Attackers Exploit the Vulnerability

Conditions That Must All Be Present

The bypass works only when every one of the following is true on the target:

  1. The OpenSSH server is older than 10.6p2 and does not carry a distribution backport of the fix.
  2. sshd is linked against musl libc.
  3. Passwords are not checked through PAM, either because the binary was built without PAM or because UsePAM no is set.
  4. PasswordAuthentication is enabled. This is the OpenSSH default.
  5. The target account’s password field in /etc/shadow is exactly *. Accounts locked with ! and accounts with a real hash are not exposed.
  6. At least one other local account has a $5$ or $6$ hash. Felker’s analysis narrows this further: it must be the first account with a password in the order the user database is enumerated.
  7. SSH policy allows the target account to log in. For root, the default PermitRootLogin prohibit-password setting blocks password logins, so direct root access through SSHole requires PermitRootLogin yes.

No valid credentials, no user interaction and no second vulnerability are required. The attacker needs only network access to the SSH port and the name of a suitable account.

Attack Scenario and Technical Walkthrough

The following describes the attack at the level documented in the advisories. It is a description of the mechanism, not a record of a specific incident.

  1. Locating SSH services. Attackers scan the internet for hosts that answer on TCP port 22. This scanning is continuous and long predates SSHole. The SSH banner discloses the OpenSSH version but not the C library, PAM status or account configuration, so an attacker cannot confirm a host is vulnerable by scanning alone. Alpine’s patched packages also keep their original version numbers, so the banner does not reveal patch status either.
  2. Choosing an account name. The attacker picks usernames likely to have a * field. Alpine’s advisory lists the kinds of account concerned: root (which has shipped with * since about Alpine 3.16), key-only users created without a password, the alpine user in the official cloud images, and directory-service users without a local shadow entry.
  3. Sending the over-long password. The attacker’s SSH client requests password authentication and submits any string in the 257 to 1,024 byte range.
  4. The server accepts the login. The comparison described above succeeds and sshd opens a session.
  5. Using the session. The attacker has the privileges of the bypassed account. If that account can run commands as root without a password, through doas or sudo, full control of the host follows without any further flaw. On Alpine’s cloud images the alpine user is configured with passwordless doas.

 

sshole exploitation process

 

Details That Remain Disputed or Unconfirmed

  • One attempt or two. Alpine’s advisory says the attack takes one connection and needs no retries. Lab write-ups from StepSecurity and IONIX report that the first over-long password in a connection is rejected and a second attempt in the same connection succeeds, which they attribute to how the shadow entry was held in memory. These accounts are compatible if “one connection” includes two password attempts, but we could not verify the behaviour independently. Defenders should not assume a failed attempt always precedes a successful one.
  • Other hash types. Primary sources specify $5$ and $6$ hashes. Vendor lab reports disagree about what happens when the borrowed hash is bcrypt. We treat any behaviour beyond the $5$/$6$ case as unconfirmed.

Real-World Exploitation: What Security Researchers Have Observed

All publicly documented successful exploitation so far has been recorded on honeypots and research sensors, which are systems operated by security companies to attract and observe attackers. As of November 12, 2026, we found no public report naming an organization that was breached through SSHole. That is not evidence that none has been.

Confirmed Exploitation on Research Sensors

  • Previdian. Founder Ryan Dewhurst told The Hacker News that the company saw its first attempt less than nine hours after the CVE was published and confirmed root access on a honeypot running Alpine Linux. The first source address, 89.116.89[.]18, ran id, uname and hostname through non-interactive SSH sessions. By November 8 Previdian had counted 20 attempts from 13 addresses in nine countries.
  • GreyNoise. The company’s event tracker dates the first successful exploitation of one of its sensors to November 7 at 00:46 UTC, about 40 hours after the fix. BleepingComputer reported 16 successful exploitation chains from six source addresses on November 9. When we reviewed the tracker, it had last been updated on November 11 and listed 38 chains and nine attacker addresses with confirmed post-exploitation activity. These figures describe GreyNoise’s own sensors only.
  • watchTowr and Defused. watchTowr said on November 6 that it had seen exploitation associated with botnets and cryptomining. Defused reported a small number of actors and no widespread activity. Neither published technical detail that we could review.

Observed Post-Exploitation Behaviour

GreyNoise documented the following on its sensors after successful logins:

  • System and container reconnaissance.
  • Queries to cloud instance metadata services for AWS, Azure and Alibaba Cloud. These services can hand out temporary cloud credentials to software running on a virtual machine.
  • Attempts to read /etc/shadow and root’s SSH keys, often through doas.
  • SSH keys written to authorized_keys files for root and alpine, one carrying the comment SSHHOLE-HIT.
  • Creation of an account named server_manager with a rule in /etc/doas.d/server_manager.conf granting passwordless root.

The GT10 Cluster and TAC Agent

GreyNoise groups part of the activity under the label GT10, a cluster defined by shared infrastructure, tools and on-host behaviour. It is a tracking label, not an attribution to a named group or country, and the tracker notes that “Not all SSHole activity is attributable to GT10”.

In one GT10 intrusion the operator obtained root, installed a Python runtime and deployed an implant GreyNoise calls TAC Agent. According to the tracker, it is a single-file Python 3 program that can run shell commands, collect system information, transfer files and update itself. Its command-and-control server was tac.vpnla[.]org. The operator also started a second SSH daemon on port 2222 and attempted to register the agent as a startup service. On the sensor, the agent never enrolled with its server and never received a task.

The implant’s comments, log messages and errors are in Chinese. Ars Technica reported that the code appears to have been generated with AI. GreyNoise interprets one of the agent’s messages as feedback intended for an automated planner. Language in source code and signs of AI assistance are weak evidence of who an operator is, and no public source attributes the activity to a specific actor.

Scanning Volume Is Not Exploitation Volume

GreyNoise recorded tens of millions of SSH connection attempts in the days after disclosure. The company and BleepingComputer both state that these are not confirmed SSHole attacks. SSH traffic is encrypted, which makes an SSHole attempt hard to distinguish from ordinary password guessing on the network.

Affected OpenSSH Versions and Systems

Upstream OpenSSH

Portable OpenSSH before 10.6p2 is affected when built for Linux against musl libc and run without PAM. Version 10.6p1 is vulnerable. Anyone compiling OpenSSH themselves for a musl-based system should move to 10.6p2.

Alpine Linux

Alpine’s default openssh-server package is built without PAM and leaves password authentication enabled. Alpine says every release it checked is affected, from 3.16 through 3.24 and edge. The separate openssh-server-pam package is safe only when UsePAM yes is set.

Fixed Packages for Current Branches

Each entry shows the Alpine branch followed by the fixed openssh package.

  • edge: 10.6_p2-r0
  • 3.24: 10.3_p1-r2 (included in point release 3.24.4)
  • 3.23: 10.2_p1-r1 (included in point release 3.23.8)
  • 3.22: 10.0_p1-r11 (included in point release 3.22.8)
  • 3.21: 9.9_p2-r1 (included in point release 3.21.10)

Fixed Packages for Branches That No Longer Receive Regular Updates

  • 3.20: 9.7_p1-r6
  • 3.19: 9.6_p1-r3
  • 3.18: 9.3_p2-r4
  • 3.17: 9.1_p1-r7
  • 3.16: 9.0_p1-r6

These package versions are taken from Alpine’s advisory as reproduced consistently by several vendors, including runZero. Because the fix is backported, a patched Alpine 3.24 host still reports OpenSSH 10.3. Check the package revision, not the OpenSSH version string.

Configurations That Change the Risk

  • Alpine cloud images. Secondary analyses citing Alpine’s advisory report that the official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with a * field and passwordless doas. Such a host becomes exploitable once any local account is given a $5$ or $6$ password.
  • Containers. Alpine is a very common container base image, but a container is exposed only if it actually runs sshd with password authentication enabled and meets the account conditions. Most containers do not run an SSH server.
  • A freshly installed system may not be exploitable yet. If no account has a $5$ or $6$ hash, there is no salt to borrow and the bypass fails. The exposure appears when someone later sets a password on any account.
  • Embedded and network devices. The researcher names OpenWrt, Buildroot and Yocto as musl-capable platforms worth checking. OpenWrt uses Dropbear for SSH by default, and Dropbear is not affected, so only OpenWrt systems where the OpenSSH server was installed are in scope. Buildroot and Yocto default to glibc according to IONIX, so only builds that selected musl are relevant. We found no vendor advisory confirming a specific affected appliance.

Systems That Are Not Affected

  • glibc-based distributions, including Debian, Ubuntu, Fedora and Red Hat Enterprise Linux. Red Hat states that none of its products are affected.
  • Any system where sshd checks passwords through PAM.
  • Non-Linux systems, including OpenBSD.
  • Dropbear and other SSH servers that are not OpenSSH.
  • Hosts with PasswordAuthentication no.

Potential Security Impact

A successful SSHole login gives the attacker whatever the bypassed account can already do. The outcome therefore ranges from a restricted service account to full root control.

The diagram below separates behaviour recorded on research sensors from consequences that are plausible but not publicly confirmed.

 

sshole post exploitation flow

 

Potential consequences on a production system include:

  • Privilege escalation without another exploit where the account has passwordless doas or sudo.
  • Credential theft, including password hashes, private SSH keys, application secrets and cloud credentials obtained from metadata services.
  • Lateral movement to other hosts using those credentials. IONIX also notes that an account with a non-interactive shell can still be used for SSH port forwarding when AllowTcpForwarding is enabled.
  • Persistence through added SSH keys, new accounts, startup services or implants.
  • Data theft or service disruption, depending on what the host stores and controls.

Lateral movement and data theft from real organizations have not been publicly documented for SSHole at the time of writing. Reading credentials, adding keys and installing an implant have been observed on honeypots.

How to Check Your OpenSSH Version and Exposure

Run the following as root on each Linux host that runs an SSH server. The commands are read-only.

Step 1: Identify the C Library

ldd "$(command -v sshd)"

ldd lists the shared libraries a program loads. If the output mentions musl, for example libc.musl-x86_64.so.1, continue with the remaining steps. If it shows libc.so.6 from glibc, the host is not affected by this flaw.

Step 2: Check the Installed OpenSSH Package

cat /etc/alpine-release
apk list --installed | grep '^openssh'

On Alpine, the first command prints the release number and the second lists installed OpenSSH packages with their revisions. Compare the revision with the fixed package list above. A revision lower than the fixed one means the host needs the update. On other musl-based systems, ssh -V prints the OpenSSH version; anything below 10.6p2 without a vendor backport is affected.

Step 3: Check the Effective sshd Configuration

sshd -T | grep -Ei '^(usepam|passwordauthentication|permitrootlogin) '

sshd -T prints the configuration the server actually uses after all files are merged. The host is exposed if passwordauthentication yes appears and usepam is either no or missing from the output. A missing usepam line normally means the binary was compiled without PAM support.

Step 4: List Accounts That Could Be Targeted

awk -F: '$2=="*"{print $1}' /etc/shadow

This prints every account whose password field is exactly *. These are the accounts an attacker could log in to.

Step 5: Check Whether a Salt Is Available to Borrow

awk -F: '$2 ~ /^\$/ {print $1 ": " substr($2,1,3)}' /etc/shadow

This prints each account that has a password hash together with only the three-character algorithm prefix, so no hash is displayed. If any line shows $5$ or $6$, treat the host as exploitable until patched. The exact account that matters is the first one with a hash in /etc/passwd order, but relying on that ordering as a safeguard is unwise.

Indicators of Compromise and Detection Opportunities

The Main Host Signal

A successful bypass is logged as a normal password login. sshd does not record password length. Alpine’s advice is to search for accepted password logins to accounts that have no password:

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

On Alpine, sshd logs to /var/log/messages by default. From OpenSSH 9.8 the process name in these lines is sshd-session. Compare each username in the results with the output of Step 4. An Accepted password for line naming root, alpine or any key-only account should not exist on a correctly functioning system and should be treated as a probable compromise. Alpine’s guidance is to treat the machine as compromised if such a login cannot be ruled out.

Logs on a compromised host can be altered by an attacker with root access. Where logs are forwarded to a central system, search there as well.

Indicators Published by GreyNoise

The following come from GreyNoise’s sensor observations. Network indicators change quickly and several of the addresses belong to cloud providers or may be compromised third-party hosts, so use them for hunting and not as a complete block list.

TAC Agent Implant

  • Command-and-control domain: tac.vpnla[.]org. Block the domain, not its shared Cloudflare address.
  • Implant files:
    • /opt/py3/tac_agent.py
    • /usr/local/bin/tac_agent.py
  • Sample SHA-256: 55e6384f6d1648be9b48fb899e46623e9c05eb0df2cbf95f6701680d4e7cbc2a
  • Startup service file: /etc/init.d/tac-agent
  • Agent configuration file: ~/.config/tac/agent.json
  • HTTP User-Agent in beacon traffic: TAC-Agent/1.0

Persistence Artifacts

  • Attacker-created account with passwordless root: user server_manager, with the rule file /etc/doas.d/server_manager.conf
  • SSH key comment: SSHHOLE-HIT, on a key added to authorized_keys
  • Extra listener: a second sshd on TCP 2222, started by the GT10 operator

Source Addresses

Post-exploitation activity on GreyNoise sensors:

  • 183.220.91[.]15
  • 20.255.63[.]133
  • 20.2.81[.]241
  • 209.248.50[.]17
  • 79.116.138[.]30
  • 47.80.65[.]43
  • 196.128.138[.]201
  • 157.15.77[.]139
  • 103.140.130[.]248

First attempts reported by Previdian:

  • 89.116.89[.]18

How Organizations Can Detect Potential Exploitation

The commands below check a host for the specific artifacts listed above and for generic persistence. They use BusyBox-compatible syntax and do not change the system.

ls -la /opt/py3/tac_agent.py /usr/local/bin/tac_agent.py /etc/init.d/tac-agent /etc/doas.d/ 2>/dev/null
grep -r 'SSHHOLE-HIT' /root/.ssh /home/*/.ssh 2>/dev/null
grep -n 'vpnla' /etc/hosts
grep -n 'server_manager' /etc/passwd
netstat -tlnp 2>/dev/null | grep ':2222 '

No output from any of these is the expected result on a clean host. Absence of these specific artifacts does not prove a host is clean, because other attackers will use different tools.

Security operations teams can add the following detections:

  • Alert on any accepted password login to an account that is known to be key-only or that has never used a password before.
  • Correlate a password login with doas or sudo use, account creation or changes to authorized_keys shortly afterwards.
  • Flag a single source address that logs in with a password to several hosts without any failed attempts.
  • Review recently modified authorized_keys files, /etc/passwd, /etc/shadow, doas and sudo rules, OpenRC services under /etc/init.d/, scripts in /etc/local.d/ and cron entries.
  • Look for outbound requests from servers to cloud metadata addresses made by interactive shells, and for unexpected Python installations on minimal hosts.

If compromise is confirmed or cannot be excluded, preserve logs, isolate the host, rotate every credential that was stored on or reachable from it, and rebuild from a patched image.

Mitigation and Remediation Recommendations

1. Update OpenSSH and Restart sshd

On Alpine Linux:

apk upgrade -U -a
rc-service sshd restart

The first command refreshes the package index and upgrades installed packages, including openssh. The second restarts the SSH daemon. The restart is essential. Installing the package replaces the file on disk, but the running daemon keeps using the old code until it is restarted.

To confirm that no old binary is still running:

for p in $(pgrep -x sshd); do readlink /proc/$p/exe; done

Each line should show the path to sshd. A path ending in (deleted) means that process is still running the pre-update binary. On older OpenSSH versions, sessions opened before the restart can show this until they end.

On other musl-based systems, install your vendor’s patched package or build OpenSSH 10.6p2, then restart sshd.

2. If You Cannot Update Immediately, Disable Password Authentication

OpenSSH, Alpine and musl’s maintainer all recommend the same interim measure. First confirm that key-based login works and keep an existing session open. Then set the following in /etc/ssh/sshd_config, including inside any Match blocks that override it:

PasswordAuthentication no

Validate and apply the change:

sshd -t && rc-service sshd restart
sshd -T | grep -i '^passwordauthentication '

sshd -t checks the configuration for errors and the restart runs only if the check passes. The final command should print passwordauthentication no.

3. Reduce Exposure

  • Restrict access to the SSH port to known networks, a VPN or a bastion host.
  • Keep PermitRootLogin at prohibit-password or no.
  • Remove sshd from container images that do not need it.
  • Rebuild and redeploy container images and virtual machine templates from patched base images. Pulling a new base image does not change containers that are already running.

4. Investigate Before Declaring the Host Clean

Patching closes the bypass. It does not tell you whether someone used it earlier. Run the detection steps above on every host that was exposed between November 5 and the time it was patched or had password authentication disabled.

Why This Vulnerability Matters for Enterprise Security

The population of affected systems is much smaller than “all Linux servers”, and claims that every OpenSSH installation is at risk are wrong. Most enterprise fleets run glibc-based distributions with PAM and are untouched.

The risk concentrates in places that are easy to overlook. Alpine Linux is widely used for small virtual machines, cloud instances, containers and appliances because of its size. These systems are often built once from an image and seldom inventoried with the same care as primary servers. Key-only accounts, the very configuration that security guidance recommends, are the ones exposed.

Three lessons apply beyond this flaw:

  • The time between fix and exploit is now measured in hours. Public exploit code appeared about four hours after the patch, the first attempts arrived the same day, and the OpenSSH project itself has shortened its embargo practice in response to rapid rediscovery.
  • A version scan is not an exposure assessment. Vulnerability here depends on the C library, the PAM setting, the SSH configuration and the contents of two account files. Patched Alpine packages also report unchanged version numbers. Organizations need host-level checks and an accurate software inventory, not only banner scanning.
  • Error values and sentinel values must never share a representation. The flaw exists because a string meaning “the computation failed” and a string meaning “this account has no password” happened to be the same single character.

Frequently Asked Questions

Is Ubuntu, Debian or RHEL affected by SSHole?

No. These distributions use glibc and check SSH passwords through PAM. Red Hat has stated that its products are not affected.

Which OpenSSH version fixes CVE-2026-123158?

OpenSSH 10.6p2, released on November 5, 2026. Alpine Linux has backported the fix to its packages for branches 3.16 through 3.24 and edge.

Can SSHole be used to log in as root?

Directly, only if root’s password field is * and PermitRootLogin yes is set. Indirectly, yes: logging in as an unprivileged account that has passwordless doas or sudo yields root.

Does the attacker need a password or SSH key?

No. The attacker needs network access to the SSH port and an account name that meets the conditions.

Is disabling password authentication enough?

It blocks this bypass and is the recommended interim measure. Installing the patched package is still the permanent fix.

Conclusion

SSHole is a narrow but severe flaw. It affects OpenSSH only where musl libc, the absence of PAM, enabled password authentication and a particular account layout coincide, and where they do, an attacker can log in with nothing more than a long string. Exploitation on research sensors is confirmed, CISA has listed the flaw as known exploited, and at least one intrusion set has tried to install a remote-control implant after gaining root.

Administrators should identify musl-based hosts running sshd, apply OpenSSH 10.6p2 or the distribution’s patched package, restart the daemon, and review logs for accepted password logins to accounts that have no password. Systems that cannot be patched today should have password authentication disabled now.

Sources and References

Official Advisories and Primary Technical Sources

Threat Intelligence and Vendor Research

News Reporting