OpenSSH “SSHole” Bug: An Overlong Password Opens Some Linux Servers, and Attackers Already Use It

By Thorsten Meyer | November 11, 2026 | ThorstenMeyerAI.com

Buying for a business?Offer from Amazon

Get business pricing on tech for your team

• Business-only prices and quantity discounts
• Tax-exempt purchasing
• Multiple users, one account, clear invoices

Create a free Business account →Free to register

As an affiliate, we earn on qualifying purchases.Hide

Key takeaways

• What happened: A flaw in OpenSSH, the widely used program for remote logins to Linux and Unix servers, lets an attacker log in to certain accounts with no valid password, just a very long one. It is tracked as CVE-2026-123158, rated 8.1 (“High”), and its finder calls it “*sshole”.
• Who is affected: Only Linux systems where OpenSSH runs on the musl C library without PAM, with password logins switched on. Alpine Linux’s standard openssh-server package is the best-known case. Debian, Ubuntu and Red Hat say their OpenSSH builds are not affected.
• Attackers moved fast: OpenSSH released the fix, version 10.6p2, on November 5. Exploit code was public about four hours later, according to GreyNoise and BleepingComputer. GreyNoise saw the first successful break-in on one of its sensors about 40 hours after the release. CISA added the flaw to its list of exploited vulnerabilities on November 9.
• What to do: Update OpenSSH and restart sshd. If you cannot update, set PasswordAuthentication no. Then check your logs for password logins to accounts that have no password.
• The AI angle: The researcher who found the bug credits “agent swarms”. OpenSSH says it shipped the fix within a day because AI agents now rediscover bugs “sometimes within hours”.

Products Worth Considering

DJI Mini 3 Drone with DJI RC and 3-Axis Gimbal

AmazonView Latest Price

Anker SOLIX C1000 Gen 2 Portable Power Station with 200W Solar Panel

AmazonView Latest Price

Samsung Odyssey G9 QD-OLED 49 Dual QHD Curved Gaming Monitor

AmazonView Latest Price

As an affiliate, we earn on qualifying purchases.

A password that is too long to fail

The security writer Bruce Schneier summed it up on the blog Schneier on Security on November 10: “It’s a bad one, and it’s been in the code for a decade.”

Here is the short version. On Linux, an account that should never log in with a password often has a single asterisk, *, where its password hash would normally be. No password can match a *, so the door stays shut.

Except on some systems, it does not. When OpenSSH’s server, sshd, checks a password without PAM (the standard Linux login framework), it hashes what you typed with the C library function crypt() and compares the result with the stored field. Alpine’s advisory explains what goes wrong next: “musl’s crypt() returns the string * as an error indicator when the key is over 256 bytes long. * is also exactly what the stored field contains for every account with no password, so the ‘hash’ matches and the login succeeds.”

So an attacker sends a password of 257 to 1024 bytes, crypt() fails, the failure looks exactly like the stored value, and sshd lets them in. Alpine puts it bluntly: “An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries.”

There is one more condition. According to Alpine, the machine needs at least one other account with a real $5$ or $6$ password hash, because sshd borrows that account’s salt for the check. “One user with a password is enough: it makes every account without one reachable.”

Where does the bug live? Nobody wants to own it fully. OpenSSH says: “We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.” musl maintainer Rich Felker wrote on the musl mailing list: “It is my position that this is not a bug in musl just an erroneous use by the caller.” Felker added that musl very likely will change the mechanism “in the upcoming release cycle.”

Are you affected? Five conditions

Alpine’s advisory lists the conditions. You are affected only if all of them are true:

1. sshd runs on Linux with musl libc. Alpine is the best-known example; the researcher also names OpenWrt, Buildroot and Yocto.
2. sshd checks passwords without PAM. On Alpine that is the default openssh-server package, or openssh-server-pam with UsePAM no.
3. PasswordAuthentication is yes, which is OpenSSH’s default.
4. There is an account whose password field is *: a key-only user, users from a directory service via musl-nscd, root on Alpine since about version 3.16, or the alpine user in Alpine’s official cloud images.
5. At least one local account has a $5$ or $6$ password hash.

Root is usually protected by OpenSSH’s default PermitRootLogin prohibit-password setting. Alpine warns that this “does not help if another account that can log in is able to become root, for example through doas.” That is exactly the case in Alpine’s official tiny-cloud images from 3.18.11 through 3.24.3: they ship an alpine user with a * password field and passwordless doas. They are safe on first boot, but, Alpine writes, they “become exploitable as soon as any $6$ hash exists on the machine.”

Not affected, according to the OpenSSH, Alpine and musl advisories: non-Linux systems, Linux systems with glibc, systems that check passwords through PAM, systems with PasswordAuthentication no, Dropbear, and Docker or other containers that do not run sshd inside. Locked accounts with ! instead of * cannot log in either.

The big Linux distributions confirm this for themselves. Ubuntu writes that its OpenSSH “is linked against glibc, and uses PAM, so it is not vulnerable to this issue.” Red Hat says its products “are not affected by this vulnerability.” Debian’s security tracker rates the issue “unimportant” for its packages and lists the fixed upstream version 1:10.6p2-1 in its unstable branch.

The embedded world is less clear. On the oss-security mailing list, the medical-device security firm Medcrypt reported on November 9 that it “reproduced this independently”, “including on a stock Yocto image, no unusual configuration.”

What admins should do now

1. Update and restart. The fix is in OpenSSH 10.6p2. Alpine published fixed packages for every branch from edge back to 3.16, including releases that no longer get regular updates. Run apk upgrade -U -a, then restart sshd. Alpine stresses: “Upgrading the package alone does not replace the running daemon.”

Alpine’s point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already contain the fixed package.

2. If you cannot update today, switch off password logins. Set PasswordAuthentication no and restart sshd. OpenSSH’s Damien Miller told Linux users with musl and no PAM to do this, or to disable SSH, “IMMEDIATELY”. First make sure your SSH key login works, and keep your current session open until a new login succeeds.

3. Check whether someone got in. Alpine’s advice: “Look in /var/log/messages for sshd lines reading Accepted password for an account that has no password (alpine, root, or any key-only user).” Review doas use, new users, changed files and authorized_keys on exposed machines. “If you cannot rule out a login, treat the machine as compromised.”

From fix to break-in in about 40 hours

The timeline shows how little time defenders get now. According to GreyNoise’s public tracking page:

• November 4, 21:18 UTC: the OpenSSH fix is committed, not yet public. Miller later wrote that the team “learned of the problem yesterday”.
• November 5, 09:01 UTC: OpenSSH 10.6p2 is released. Alpine publishes its advisory and fixed packages the same day.
• November 5, 12:19 UTC: the researcher’s write-up goes online.
• November 5, 13:16 UTC: the first public exploit code appears on GitHub.
• November 5, 15:46 UTC: the CVE number is published; NVD follows with a score of 8.1.
• November 7, 00:46 UTC: GreyNoise observes the first successful exploitation of one of its sensors.
• November 9: CISA adds CVE-2026-123158 to its Known Exploited Vulnerabilities (KEV) catalog. US federal civilian agencies must act by November 12.

What did the attackers do? GreyNoise counts 28 successful exploitation chains on its own sensors, from 8 attacker IP addresses, as of its update on November 11. In one case, it writes, an attacker “checked whether the system ran in a container, queried AWS, Azure and Alibaba Cloud metadata services, and tried to read root’s SSH keys and the password hashes in /etc/shadow through doas.” BleepingComputer reports, citing GreyNoise, that one attacker gained root and installed a Python remote-control agent that never reached its server. SecurityWeek reports that the security firm Previdian saw 20 exploitation attempts from 13 attacker IPs in 9 countries between November 6 and 8, and that watchTowr attributes the first attacks to botnets and crypto miners.

These are sensor and honeypot numbers. They show that attackers are actively trying. They do not show how many real servers were hit.

Where AI comes in

The researcher, Özgün Kültekin of the security firm Wakefield, describes on the bug’s website how the flaw turned up: sshd was built in many configurations and the researcher “threw like 17,600 weird logins at it.” Then: “oh did i say “i”? sorry. i had agent swarms. a lot of them.” Every build agreed on every login, the write-up says, “except musl without pam.”

OpenSSH draws a broader conclusion. Its 10.6p2 release notes say the team has “received a large number of security bug reports, many of which are findings from AI models or made with AI assistance.” And: “We have seen a number of cases where a security bug identified by AI tools is subsequently independently discovered by a different researcher.” That, OpenSSH writes, “suggests that adversaries who do not report bugs to OSS projects are likely to be able to discover these bugs too.”

That is why there was no long secret window this time. Miller wrote that the team released “as fast as possible” because it has “recently observed multiple cases of rapid bug rediscovery by AI agents, sometimes within hours, and so now consider long embargo periods to be a dangerous practice that primarily benefits attackers.” OpenSSH says it will, for now, make “more frequent releases” instead of batching fixes.

The trade-off is real. A short embargo gave Alpine’s maintainers almost no time, and attack code still followed within hours. But a long embargo only helps if nobody else finds the same bug, and OpenSSH says that assumption no longer holds.

What this means for businesses

Find your musl systems. Alpine is widely used in container images and embedded devices, as Ars Technica notes. Containers that do not run sshd are not affected, according to Alpine. The risk sits in Alpine virtual machines and servers that accept SSH from outside, and in appliances built on musl.

Ask your device vendors. Routers, gateways, industrial controllers and medical devices often run small Linux builds. Medcrypt’s reproduction on a stock Yocto image shows that the problem is not limited to Alpine. If a vendor’s device runs OpenSSH with password logins, ask whether it uses musl without PAM and when a fix ships.

Treat it as an incident, not just a patch. Exploit code was public within hours of the fix. CISA’s listing explicitly asks for forensic triage. Where an Alpine machine with password logins was reachable from the internet since November 5, check the logs before you call it done.

Prefer keys over passwords for SSH. Systems with PasswordAuthentication no were never exposed. Key-only access is old advice; this bug is a good reason to enforce it.

What this means for users

Most people have nothing to do. Macs and Windows PCs are not Linux systems, and standard Debian, Ubuntu or Fedora installations use glibc, so none of them is affected.

If you run your own small server or a home lab on Alpine Linux, update today and restart sshd, or switch password logins off. If you use a router or network box with SSH enabled, check the maker’s site for an update. According to Ars Technica, OpenWrt uses Dropbear rather than OpenSSH by default, which is not affected.

What we don’t know

• How many systems are exposed. There is no reliable count of internet-facing servers that meet all five conditions.
• Which commercial devices are affected. I found no public list of affected products. Medcrypt reports reproducing the bug on Yocto; for Buildroot and OpenWrt builds with OpenSSH I found no independent confirmation.
• Whether anyone used the bug before November. The researcher traces the flaw back to a 2016 change in OpenSSH and writes that “as far as anyone knows, nobody noticed.”
• Who is behind the attacks. CISA lists ransomware use as “Unknown”.
• The exact cut-off. The CVE text says “any password between 256 and 1024 characters succeeds”; Alpine and the researcher say 257 to 1024 bytes.
• How much the AI agents did. The researcher credits “agent swarms” but has not published which tools were used or how much of the work the agents did on their own.

The bottom line

A login check that has worked for years failed because two programs disagreed about what one character means. The fix is simple: update, restart, and keep password logins off where keys will do. The bigger lesson is the clock. From release to first break-in took about 40 hours, and OpenSSH now plans its releases around the idea that AI tools will find the same bugs again within hours.

For more context, read who finds the bugs in the 2026 CVE wave, why the patch gap is shrinking as AI speeds up exploit writing, and what GPT-6 Cyber and METR’s report mean for the patch window.

I’m Thorsten Meyer. The full sources are below, and more reality checks are at thorstenmeyerai.com.

Sources

• OpenSSH: Release notes for Portable OpenSSH 10.6p2, released 2026-11-05, openssh.com/releasenotes.html
• Damien Miller (OpenSSH): “urgent security release: 10.6p2”, openssh-unix-dev mailing list, November 5, 2026
• CVE.org and NVD: CVE-2026-123158, published November 5, 2026 (CVSS 3.1 score 8.1 from MITRE)
• CISA: Known Exploited Vulnerabilities catalog, version 2026.11.10 (CVE-2026-123158 added November 9, 2026, due November 12, 2026)
• Alpine Linux: “Security advisory: openssh-server password authentication bypass”, November 5, 2026, alpinelinux.org
• Rich Felker (musl): “Advisory for OpenSSH+musl users”, musl mailing list, November 5, 2026
• Özgün Kültekin (Wakefield): “*sshole”, sshhole.com
• oss-security mailing list: thread on the OpenSSH and musl password authentication bypass, opened November 5, 2026, with a reply from Medcrypt on November 9, 2026
• Ubuntu: CVE-2026-123158, ubuntu.com/security; Red Hat: CVE-2026-123158, access.redhat.com; Debian security tracker: CVE-2026-123158
• GreyNoise: “SSHole (CVE-2026-123158) Activity 2026”, sshole.events.greynoise.io, last updated November 11, 2026
• Bruce Schneier: “New OpenSSH Vulnerability”, Schneier on Security, November 10, 2026
• BleepingComputer: “Hackers exploit SSHole OpenSSH flaw to breach Linux systems”, November 9, 2026
• SecurityWeek: “Hackers Exploiting ‘SSHole’ Authentication Bypass in OpenSSH”, November 9, 2026
• Ars Technica, Dan Goodin: “Meet *sshole, the vulnerability that lets hackers SSH into Linux devices”, November 5, 2026

Researched and drafted with AI assistance, including Anthropic’s Claude. No company, project or agency named here reviewed or sponsored this article. This article is for information only. It is not legal or security-consulting advice. Statements and package versions as published by the sources above as of November 11, 2026; check your vendor for later updates. Images: AI-generated illustration (Runware) and graphics by Thorsten Meyer AI; no real people or logos are shown.