A server can encrypt a connection correctly and still let the wrong person in. That is the central problem with SSHole, also written *sshole: a password authentication bypass involving OpenSSH and the musl system library. Disclosed on November 5, 2026 by Özgün Kültekin of Wakefield, it prompted the release of Portable OpenSSH 10.6p2. OpenSSH release announcement.
The issue is tracked as CVE-2026-123158. It concerns specific Linux server configurations, not every SSH installation. Updating the SSH application on your laptop does not establish that a remote server is fixed. CVE record.
Status as of November 6, 2026. The technical explanation below draws on the disclosure and upstream code. The response plan is Nuagerie’s practical guidance, not a report of a compromise observed on a customer’s infrastructure.
What SSHole actually bypasses
SSH is commonly used to administer servers and transfer files. OpenSSH implements that protocol; its server process, sshd, decides whether to accept a connection. musl is a C library used by some Linux environments. PAM is a separate authentication framework that can handle account and password checks.
In the affected path, a failed password-hashing operation returns a special string. The server compares that string with the account’s stored password field and can incorrectly treat equality as successful authentication. This is a failure in the authentication decision, not a recovered password or a broken SSH encryption algorithm. The upstream correction adds a minimum stored-hash length check before accepting the comparison. OpenSSH fix.
For a business, the distinction matters: a visitor to the SSH service may obtain the capabilities of an account without possessing its intended credentials. A web application firewall protecting your website does not, by itself, inspect or repair this separate SSH authentication path.
Which systems need attention?
Alpine’s advisory identifies this combination:
- An unpatched OpenSSH server using musl, without active PAM authentication.
- Password authentication enabled.
- An otherwise eligible target account whose password field is exactly
*. - Another local account with a
$5$or$6$password hash. - Network access to the SSH service.
A container without sshd is not exposed through this path. Alpine’s PAM-enabled server with UsePAM yes is excluded. The exact * marker matters; it must not be confused with a ! account lock. Alpine security advisory.
Do not classify a fleet from distribution names alone. Inventory the running daemon, library, authentication backend, account configuration and reachable network interfaces. An application image based on Alpine is not equivalent to an Alpine virtual machine offering remote administration. Likewise, a private address changes who can reach the service; it does not repair the password check.
Using a key for your own daily connections does not necessarily disable the server’s password method. Also distinguish the default acceptance of one successful method from a policy that explicitly requires several methods. A password bypass alone does not satisfy a separately enforced public-key requirement. OpenSSH authentication-method configuration.
How an error becomes a successful login
A marker is not a password
A password database normally stores a derived hash rather than the plaintext secret. A salt is an input to that derivation, allowing identical passwords to produce different stored results. A field containing only * is not a usable password hash. It is also not an empty password: an empty field and a one-character marker are different values.
The research disclosure explains why accounts intended for key-based access can have this marker. The danger comes from treating every matching string as proof of a valid password, even when neither string represents a successful hash computation. Researcher’s explanation.
A defensive limit rejects the input
musl’s SHA-512 password-hashing implementation limits the input to 256 bytes to control the cost of processing excessively long passwords. Bytes are not always the same as displayed characters. The limit itself rejects oversized input rather than copying it beyond a memory boundary. musl hashing implementation.
Historically, musl changed its error handling to return an impossible hash string instead of a null pointer, helping callers avoid a crash when they failed to check for null. That error string was *. Returning a string does not mean hashing succeeded. musl error-handling change.
A timing defence connects the pieces
OpenSSH introduced fallback salt selection to make unsuccessful authentication do comparable hashing work, reducing differences that could reveal whether a username exists. It can select parameters from another account when there is no suitable hash for the requested one. That explains why another account’s password configuration matters even though the attacker is not trying to log in as that account. OpenSSH’s 2016 salt-selection change.
The resulting sequence is conceptually simple: select hashing parameters, reject an oversized password, receive *, then compare it with the target’s stored *. The comparison matches although no valid password hash was produced. The documented triggering range is 257 to 1024 bytes. No secret has been guessed and no cryptographic hash collision has been found. Disclosure.
Why this is not a buffer overflow
In a classic buffer overflow, software writes beyond the memory allocated to hold data. That can corrupt neighbouring data, crash the process or, in an exploitable case, alter execution. A long input is one possible trigger, but its length alone does not establish a buffer overflow. MITRE’s buffer-overflow definition.
| Question | Classic buffer overflow | SSHole |
|---|---|---|
| What goes wrong? | A write exceeds a memory boundary. | An error result is accepted as authentication evidence. |
| What does the long input do? | It may exceed the capacity of a destination buffer. | It triggers the hashing function’s rejection path. |
| Must memory be overwritten? | Yes, for the overflow itself. | No. |
| What needs correcting? | Memory bounds and unsafe operations. | The interpretation and validation of authentication results. |
This comparison explains why memory exploit protections are not a remedy for this particular login decision. The program can remain stable, return an ordinary success response and still violate the security policy. Conversely, buffer overflows are not merely an old, solved category: a new logic flaw does not make memory safety irrelevant.
Is it the same as regreSSHion?
No. The 2024 OpenSSH issue commonly called regreSSHion, CVE-2024-6387, involved a signal-handler race and potential arbitrary code execution. OpenSSH’s 9.8 announcement described exploitation demonstrated on 32-bit Linux/glibc with repeated attempts and demanding conditions. SSHole concerns password acceptance in a different authentication path. The risk assessment and the corrective releases must therefore be matched to the right vulnerability. OpenSSH 9.8 security notes.
What an attacker could do
The first question is which account’s authority becomes available. Our impact assessment separates several possibilities:
- A deployment account may be able to replace application files or read deployment credentials.
- An account with access to backups or shared storage may expose data beyond the server’s main application.
- A restricted transfer account may expose only its permitted files, depending on its actual confinement.
- An administrative account may allow changes to services, users, security settings or logs.
These are possible consequences to investigate, not a claim that every exposed server grants complete control. Root access depends on the account and applicable policy. PermitRootLogin prohibit-password blocks root password authentication, but it does not restrict a different account’s subsequent administrative privileges. Root-login policy.
Similarly, access inside a container does not automatically mean control of its host. Mounted secrets, shared volumes, privileged settings and access to management sockets determine the possible reach. The business assessment should cover confidentiality, unauthorized changes, interruption and recovery, rather than stopping at whether a shell appeared.
What to do now
Identify and reduce exposure
Have the responsible administrator identify affected systems, including cloud images, appliances and containers that actually run SSH. Prioritize reachable administrative services and accounts with sensitive access. Restrict unnecessary network access while the fix is prepared.
Where appropriate, disable password authentication with an effective PasswordAuthentication no policy. Verify a separate working administrative access path first. Include conditional configuration in the review; seeing a directive in one file does not prove which policy applies to every user. OpenSSH configuration semantics.
Apply the vendor fix and activate it
Portable OpenSSH 10.6p2 contains the upstream workaround. Distribution packages can carry a backported fix without adopting that upstream version number. OpenSSH announcement.
For Alpine, consult the advisory’s branch-specific package table. Updating the package must be followed by restarting sshd; an old running daemon is not replaced merely because new files were installed. Alpine update instructions and fixed packages.
Our recommended completion evidence is the installed server package and revision, the vendor’s matching fix, confirmation that the new daemon is running, and a successful new authorized connection. Preserve a recovery access path during this work. For immutable systems, also rebuild the source image and replace affected instances so the next deployment does not restore the vulnerable package.
Do not replace this verification with the version of the local ssh client or a banner-only scanner result. Record exceptions and their owners. Avoid improvised changes to password database markers: account locks can affect legitimate access as well as password authentication.
Investigate separately from patching
A fix closes the vulnerable path; it does not revoke access that an intruder may already have established. Review successful password authentications that contradict the intended account policy, unusual source addresses, newly added keys, account changes and unexpected administrative activity.
Correlate events with configuration history and authorized maintenance. An unexplained success deserves investigation, but a log line alone does not establish the exact exploit. Do not enable plaintext password logging to look for long inputs. Missing or rotated logs also limit what can be concluded.
If unauthorized access is confirmed or strongly suspected, preserve evidence, contain the system, assess exposed credentials and plan recovery from trusted sources. Changing passwords on a host still controlled by an attacker is not a complete recovery plan.
What this means for your business
Ask the party responsible for the operating system for a clear answer: which systems were checked, which were affected, which fixes are active and whether suspicious activity requires follow-up. The owner of an application and the administrator of its host may be different organizations; the maintenance scope should identify who performs each task.
SSHole illustrates why security checks must cover the interaction between components. A hashing limit, an error marker and a timing defence can each have a sensible purpose while their combination produces an unsafe decision. For an organization, the useful outcome is a verified inventory, an active fix and an evidence-based assessment of any prior access.