Your Passwordless SSH Account Takes Any 257-Character Password (2026)

The password was the letter A, typed 300 times, and the account it opened has no password. The prompt had just said Permission denied, please try again.

Quick answer: CVE-2026-123158 is a password authentication bypass in OpenSSH's sshd on Linux systems that use musl libc without PAM. Accounts with * as their shadow password field accept any password of 257 to 1,024 characters if another account has a real hash. OpenSSH 10.6p2 fixed it on November 5, 2026. Upgrade and restart sshd, or set PasswordAuthentication no.

Last updated: November 6, 2026. Every source below was opened that day. Exploitation status moves fast, so check the CVE record before you rely on it.

You're reading this on a directory's blog, not a security vendor's. SaaSCity is a gamified startup directory with a live city map and human editorial review, and we had nothing to do with finding or fixing this bug. I read the advisories, the CVE record, the fix commit and the proof-of-concept scripts. I did not fire the exploit at anything, so the reproduction details are the researcher's, with links so you can check them. We covered it because plenty of founders run one small Linux box and carry the pager for it.

Is Debian, Ubuntu or macOS affected?

No. A server on Debian, Ubuntu, Fedora, RHEL or any other glibc distribution can't be hit by this, and neither can macOS, OpenBSD or FreeBSD.

Damien Miller of OpenSSH said so on November 5, 2026: the flaw "does not exist on non-Linux systems, Linux/glibc systems and Linux systems that use PAM for password authentication." Wakefield, the company that reported it, adds FreeBSD, macOS and the Dropbear SSH server. Rich Felker, who maintains musl, confirmed the Dropbear part in a reply to that post.

The difference comes down to what crypt() hands back when hashing fails. glibc returns NULL, which sshd rejects, and the libxcrypt library Debian later moved to returns *0, according to the write-up. Neither can equal a stored *.

The systems that need a look are built on musl libc: Alpine Linux first, plus OpenWrt, postmarketOS, Void's musl build, Chimera, and Buildroot or Yocto images that use musl, per Wakefield's list. Miller's instruction to those operators was blunt: "stop reading and set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY."

That group sounds small until you remember how much runs on Alpine. Docker Hub's API showed 12.48 billion pulls of the official alpine image on November 6, 2026. A pull isn't a server, and most of those containers never start sshd, which clears them. On Hacker News, where the story ranked first for November 5 with about 2,800 points, ekidd guessed that "relatively few people are actually exposed." jbyers replied that "a small minority times the number of Alpine containers running in the world gets to a large absolute number." I think both of them are right.

What is the OpenSSH musl password bypass (CVE-2026-123158)?

CVE-2026-123158 is a login bypass in OpenSSH's server: on musl-based Linux without PAM (Pluggable Authentication Modules, the usual Linux login framework), an account whose /etc/shadow password field is exactly * accepts any password between 257 and 1,024 characters.

That * is supposed to mean the opposite. It marks an account with no password, and as Özgün Kültekin's write-up, which gave the bug its *sshole name, puts it, "a * isn't a hash, so no password can match it." Your key-only deploy user probably has one. On Alpine, so does root. An attacker needs the account's name and a network path to the SSH port. Alpine's advisory says the attack "takes one connection, works every time, and needs no retries," and the OpenSSH release notes call 10.6p2 "a critical security workaround."

One detail most headlines dropped: the public exploit uses two password prompts on that one connection. The repo's attack.sh sends wrong, then 300 A's, and the write-up confirms that "a * in shadow needs a wrong try first." Kültekin's Docker lab shows it on a stock Alpine 3.24 openssh-server bound to 127.0.0.1, so you can watch it on your own laptop. There, alice has * and bob has a real password.

Question	Answer as of November 6, 2026
Name	*sshole, CVE-2026-123158
What it is	Password authentication bypass in sshd, classed CWE-394 (unexpected return value)
Severity	CVSS 3.1 base score 8.1, High
Exploitable since	OpenSSH 7.3p1, released 2016, per Wakefield
Fixed in	OpenSSH 10.6p2 and patched Alpine packages, both November 5, 2026
Exploited?	None reported. Public proofs of concept exist. Not in CISA's Known Exploited Vulnerabilities (KEV) catalog
Reported by	Özgün Kültekin of Wakefield
Workaround	PasswordAuthentication no, then restart sshd

Two notes on that record. It says "between 256 and 1024 characters," which is off by one. musl's check is klen > KEY_MAX with KEY_MAX at 256, and the repo's README shows a 256-byte test rejected and a 257-byte test logged in. The ceiling is OpenSSH's own MAX_PASSWORD_LEN, 1024. The other note is that the score rests on AC:H, high attack complexity, which I read as the scorer pricing in the preconditions. Flip it to AC:L and the same vector calculates to 9.8.

On exploitation, Ostorlab said on November 6, 2026 that none had been reported publicly and that CISA's KEV catalog did not list the CVE. CISA's enrichment on the record marks exploitation as poc, automatable as no and technical impact as total. Kültekin's own summary of the ten years before disclosure: "so as far as anyone knows, nobody noticed. as far as anyone knows."

Am I affected? The five conditions that must all be true

You're affected only if all five of these are true on the same machine, and any single "no" clears it.

Condition	Exposed when	Clear when
C library	musl	glibc, or a non-Linux OS
PAM	Alpine's openssh-server, built without PAM, or openssh-server-pam with UsePAM no	openssh-server-pam with UsePAM yes
Password login	PasswordAuthentication yes, the OpenSSH default	PasswordAuthentication no
A target account	A password field of exactly *: root, key-only users, the alpine cloud user, directory users through musl-nscd	The account is locked with !
A salt donor	At least one other account has a $5$ or $6$ hash	No $-style hash on the machine

The fourth row should bother you. Those are the accounts you set up to be safe. You created deploy with no password because keys beat passwords, and you were right, and that is the account this bug opens. Accounts locked with ! stay locked, and BleepingComputer notes the flaw can't bypass accounts that have a valid hash.

The fifth row is the mundane trigger. Somebody ran passwd once, for one user, for a reason nobody remembers. Alpine: "One user with a password is enough: it makes every account without one reachable."

Back to that root shell at the top of this post. It needs PermitRootLogin yes, which isn't the default. OpenSSH's default of prohibit-password keeps root out of this attack, even with root:* in the shadow file. Alpine adds the catch: "That does not help if another account that can log in is able to become root, for example through doas." So on a default box the realistic chain runs through your deploy user and whatever privileges it holds.

How do I check my server in 60 seconds?

Run these four commands as root. If all four come back positive and your package is older than the fixed version in the next section, the box is exposed.

# 1. C library: "musl libc" means keep going
ldd --version 2>&1 | head -1

# 2. Password login and PAM, as sshd sees them
sshd -T | grep -iE '^(passwordauthentication|usepam)'

# 3. Targets: accounts whose password field is exactly *
grep -E '^[^:]+:\*:' /etc/shadow | cut -d: -f1

# 4. Salt donors: accounts with a real SHA-256 or SHA-512 hash
grep -E '^[^:]+:\$[56]\$' /etc/shadow | cut -d: -f1

Output from line 1 that mentions glibc ends the audit. On line 2, passwordauthentication no or usepam yes clears the box. Line 3 lists what an attacker can log in as. An empty result is good news unless you use directory accounts, because users arriving through musl-nscd have no shadow entry and grep can't see them. Line 4 lists the donors. If it's empty you're safe today and one passwd away from not being safe. I anchored both greps and cut the output to usernames so hashes stay out of your scrollback.

sshd -T prints the global config. If you use Match blocks, the man page's -C option evaluates them for a specific connection:

sshd -T -C user=deploy,host=localhost,addr=127.0.0.1 | grep -i passwordauthentication

If you're sure password login is off, that's the command that proves it. This bug only bites people who left a default alone, and most of us have never checked which defaults we left.

The repo's check.sh runs the same logic and also looks at PAM linkage, /etc/passwd and nsswitch.conf. As of November 6 it writes no files and makes no network calls, but it wants root, so read it first. OX Security warns against running "unverified exploit or scanner scripts" from public repos, and that's fair advice for any script going around this week.

There's one trap in it. check.sh trusts only the version banner, and Alpine backported the fix. A patched 3.24 box has package 10.3_p1-r2 and still reports OpenSSH_10.3p1, so from my reading of the script that box prints EXPOSED. Ethiack warns about the same thing: "scanners that only compare against 10.6p2 will flag patched Alpine hosts." Check the package revision instead:

apk info -v openssh-server

We wrote about the same trap with php -v during PHP2Shell. A banner tells you what the project called the release, and nothing about what your distro patched.

How do I fix it: upgrade, restart or turn password login off?

Upgrade to the fixed package and restart sshd. If you can't upgrade today, set PasswordAuthentication no and restart. Alpine says "Either one closes the hole," and I'd do both.

Alpine branch	Fixed openssh package	Point release that carries it
edge	10.6_p2-r0	Rolling
3.24	10.3_p1-r2	3.24.4
3.23	10.2_p1-r1	3.23.8
3.22	10.0_p1-r11	3.22.8
3.21	9.9_p2-r1	3.21.10
3.20	9.7_p1-r6	Package only
3.19	9.6_p1-r3	Package only
3.18	9.3_p2-r4	Package only
3.17	9.1_p1-r7	Package only
3.16	9.0_p1-r6	Package only

The order below is the safe one:

1. Confirm you are exposed. Run the four checks from the section above as root. A box on glibc, a box using PAM, or a box with PasswordAuthentication no is clear. A box missing only the password hash is safe today, so patch it anyway.
2. Test your key login. Open a new terminal and confirm your SSH key still logs you in. Keep your current session open until a new login works, so a bad restart cannot lock you out.
3. Upgrade OpenSSH. On Alpine, run apk upgrade -U -a, then compare apk info -v openssh-server against the table above. Everywhere else, install OpenSSH 10.6p2 or your vendor's patched package.
4. Restart sshd. On Alpine, run rc-service sshd restart. Upgrading the package does not restart the running daemon, so the job is not finished until you do this.
5. Turn password login off. Set PasswordAuthentication no unless something on the box needs passwords. If you cannot upgrade today, this step is your fix, and Alpine's exact commands are below. Confirm with sshd -T | grep -i passwordauthentication.
6. Rebuild images and redeploy. Rebuild every container image and cloud image that installs openssh-server, redeploy it, and update every running instance. A running container keeps the binary it started with.
7. Search the logs. Look for Accepted password lines on accounts that have no password, then review doas use, new users, changed files and authorized keys. If you cannot rule out a login, treat the machine as compromised.

Alpine's commands for step 5, run as root:

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

Don't skip the sed. Alpine's default sshd_config reads the drop-in directory only from 3.19 onward, so the one-line echo fix doing the rounds this week does nothing on older releases. The sed also rewrites yes inside Match blocks and inserts a line at the top, which matters because in sshd_config "the first obtained value will be used." To undo it, delete the drop-in file and copy /etc/ssh/sshd_config.bak back.

Alpine 3.21 reached end of support on November 1, 2026, four days before this shipped, and 3.16 to 3.20 no longer get regular updates. The project published fixed packages anyway. I wouldn't plan around that happening next time. If you compile OpenSSH yourself, Wakefield says the upstream patch applies to every release from 7.3p1 onward, and the repo carries it unchanged.

Did someone already log in?

Search for an Accepted password line naming an account that has no password. That line should never exist, so Wakefield says to investigate any server showing one as compromised.

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

Alpine logs to /var/log/messages. Other musl builds may write somewhere else, so confirm where your syslog goes. Compare the usernames against your list from check 3. bob logging in with a password is normal. alpine, root or deploy is not.

Keep your expectations of this grep modest. Ostorlab calls it "a lead, not proof," and Ethiack says no network indicators have been published. Since the attack needs a wrong try first on a shadow * account, I'd expect a Failed password line for the same user right before the accepted one, but that's my inference from the proof of concept and no source lists it. Anyone who reached root can also edit local logs, so a clean file only means much if the logs also leave the box.

Alpine's list for exposed machines covers doas use, recently created users, files and authorized keys. Its conclusion is the one to tape to your monitor: "If you cannot rule out a login, treat the machine as compromised."

What does one compromised box cost a small SaaS?

One compromised box costs a small SaaS a rebuild, a full credential rotation and possibly a legal clock, all landing on whoever holds the pager.

Assume anything that account could read has left the building: .env, database passwords, API keys, payment and email credentials, SSH keys in that home directory. A small VPS tends to hold all of it at once, which is the same reason an exposed Ollama port on a cheap box turned out to be more than a GPU bill. Rebuild from a known-good image, because you can't prove what an attacker left behind. If you moved off managed platforms to self-host on your own server, this is the trade you made: a smaller bill, and sshd is yours to patch.

If customer data was on that box and you serve people in the EU, GDPR Article 33 gives you "not later than 72 hours after having become aware of it" to notify your supervisory authority, unless the breach is "unlikely to result in a risk to the rights and freedoms of natural persons." Paragraph 5 says you document it either way. If you hold a SOC 2 report, the incident joins your evidence trail too.

People will quote IBM's 2026 figure at you: $4.99 million as the global average breach cost, up 12% and a record. Ignore it for planning, because IBM's page gives no number for organizations under 500 people. For a five-person SaaS the cost is a lost week and a customer email you never wanted to write, and the fix that would have prevented both is one config line.

Why did this happen? Three projects, four changes, ten years

Three projects made four reasonable changes between 2012 and 2022, and together those changes made a failed hash equal the * stored for an account with no password.

Jan Schaumann's oss-security post on November 5 said the history "is actually fun," which is a very mailing-list way of putting it. Here it is, from the commits and the repo's timeline:

Date	Project	Change	Why it was reasonable
Aug 9, 2012	musl	crypt() returns an unmatchable string, not NULL, on failure	Programs that compared the result blindly crashed on NULL
Aug 29, 2012	musl	Adds SHA-256 and SHA-512 crypt with a 256-byte key cap	The source comment says "added for DoS protection"
Jul 2016	OpenSSH	Hashes the password even for accounts with no usable hash, using another account's salt	Closes CVE-2016-6210, a timing leak that revealed valid usernames
2022	Alpine	Changes root's field from ! to * in 3.16	! blocked SSH key logins without PAM

Walk it through with alice, whose field is *, and bob, whose hash starts $6$abc$. sshd sees that alice's field is too short to hold a salt, so pick_salt() walks the user list and borrows bob's. It calls crypt() with the attacker's 300 characters and bob's salt. musl's SHA-512 code sees a key over 256 bytes, refuses it, and takes the error path, which returns *. sshd compares that * with alice's stored *, and they match.

The detail I like most is that musl saw this coming. The 2012 commit returns (setting[0]=='*') ? "x" : "*", so if the value being checked starts with *, the failure string is something else and can't match. That guard assumes the hash you pass to crypt() is the hash you compare against. OpenSSH's timing fix broke that assumption in 2016, with the salt from bob and the comparison against alice. HN commenter mpyne laid this out at the top of the thread, and it's the clearest short explanation I've read.

The 2022 change has its own back story. Alpine's ! came from fixing CVE-2019-5021, an empty root password in its Docker images, and that lock then broke key logins, so * was a fix for a fix. There's a near miss too. On October 30, 2026 an OpenSSH security review fixed pick_salt() for bcrypt hashes. The write-up's verdict: "the bug is four lines below it."

So whose bug is it? Nobody's claiming it. OpenSSH's notes say "We consider the root cause of this bug to be outside sshd." Felker's position is that "it is not a musl vulnerability." On HN, Palomides pointed out that "returning null on error is in the spec," amluto argued "If you're doing a fake password hash to obscure timing, remember that it's fake and don't let the user log in!", and tchebb countered that the check "is correct for a crypt() implementation that returns NULL on error." It's a fun argument and you can't do anything with it. You don't own the boundary between your libc and your daemon. You do own the list of what runs on which box.

The fix itself is small. auth-passwd.c now requires the stored field to be at least MIN_PASSWORD_HASH_LEN, four characters, before a comparison can succeed. A * is one character. The README adds that the patch also stops using a pointer into libc's static buffer.

What does this mean for containers and Alpine cloud images?

Most Alpine containers are fine, because Alpine's advisory clears any container that doesn't run sshd. An app image built on alpine with no SSH server inside has nothing to attack.

The containers worth finding are the ones someone turned into small VMs, such as a dev image or a debugging sshd that shipped to production. They run the same package with the same default. This tells you whether a running container has sshd at all:

docker exec <container> sh -c 'command -v sshd'

Upgrading the host does nothing for those, so rebuild from the fixed package and redeploy.

The sharper case is Alpine's own cloud images. Per the advisory, official qcow2, VHD and AMI images from 3.18.11 through 3.24.3 ship an alpine user with * as its field and passwordless doas. Wakefield and BleepingComputer both name the AWS and Azure images. They're safe on first boot. They become exploitable the moment any $6$ hash exists on the machine, and Alpine's two examples are ordinary: an admin sets a console password, or user-data adds a user with hashed_passwd. The attacker then gets a shell as alpine, and doas makes that root.

Of everything in this story, that's the path I'd worry about most, because nobody touched the SSH config. Images configured through cloud-init write PasswordAuthentication no, which clears them. Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later carry the fixed package. Earlier ones don't, and neither do AMIs you baked from them, so update openssh or disable password login on every running instance and refresh your launch templates.

OX Security also suggests restricting access to the port. A firewall rule or VPN in front of SSH doesn't fix the bug, but every source here describes an attacker who can reach the port, so it shrinks who can try.

AI agents found a ten-year-old bug. What does that say about your stack?

CVE-2026-123158 shows that bugs living between two components just got cheap to find, for whoever goes looking.

Wakefield's method is worth stealing. Its November 5, 2026 research page says it built OpenSSH every way it could set up, glibc and musl, with and without PAM, with and without shadow passwords. Then its agents ran about 17,600 unusual login attempts across those builds: malformed hashes, locked accounts, oversized passwords. "Every build gave the same answer for every attempt except one." Nobody had to spot the flaw by reading code, because the disagreement pointed straight at it.

The response was fast too. Wakefield reported on November 3, 2026 and says the OpenSSH team sent a patch in under an hour. Alpine and musl maintainers heard on November 4, and everything shipped on November 5. Miller's post says "we learned of the problem yesterday" and Ethiack dates that to November 4, so the clocks differ slightly, but report to release took about two days. Alpine credits Miller and Darren Tucker for the fix, Timo Teräs for analysis and Natanael Copa for packages, on every branch back to 3.16.

The reason for that speed is in the 10.6p2 release notes.

The team says it has seen bugs found by AI tools "subsequently independently discovered by a different researcher," which suggests adversaries "are likely to be able to discover these bugs too." So it will "for now, be making more frequent releases." Miller's post goes further: rediscovery by AI agents happens "sometimes within hours," and long embargoes are now "a dangerous practice that primarily benefits attackers."

For a founder that changes two things. Patch windows shrink, and this isn't a one-off: PHP2Shell, two weeks earlier, was also a decade-old bug surfaced with AI tooling. You should expect more mornings like this one, and a shorter gap between the advisory and the first scan. The second is that the same method works on your own code. Pick a flow where two components meet, such as your login handler and the library under it. Feed both configurations empty, over-long and malformed input, and read only the disagreements. Our pre-launch security checklist covers the boring half of this: secrets, server-side auth and rate limits.

What should you do before you close this tab?

Open a terminal and run sshd -T | grep -i passwordauthentication on every box you own, including the one you forgot about. If it prints yes on musl, you have a package revision to check and a five-minute job. This is a config bug with a known fix, and it doesn't deserve more drama than that.

Then get back to the product. If you want people to find it, SaaSCity reviews every listing by hand, and a paid listing ($24.99) goes live within 24 hours with a building on the city map. Premium ($49.99) adds a launch post we write for you. None of that patches sshd, so do the terminal part first.

Ten years is how long a good decision in one project sat next to a good decision in another before anyone tested them together. I'd bet the next pair is already sitting in something you run. When it surfaces, the part you control is whether you know what's on your boxes.

FAQ

What is the OpenSSH musl password authentication bypass (CVE-2026-123158)?

CVE-2026-123158, nicknamed sshole, is a flaw in OpenSSH's sshd on Linux systems that use musl libc without PAM. An account whose shadow password field is a single asterisk accepts any password of 257 to 1,024 characters, provided another account on the machine has a real SHA-256 or SHA-512 hash. OpenSSH fixed it in 10.6p2 on November 5, 2026. The CVE record scores it CVSS 3.1 8.1, High.

Is Debian, Ubuntu, Fedora or macOS affected by CVE-2026-123158?

No. Damien Miller of OpenSSH said on November 5, 2026 that the flaw does not exist on non-Linux systems, Linux systems using glibc, or Linux systems using PAM for password authentication. Wakefield, which reported it, lists Debian, Ubuntu, Fedora, OpenBSD, FreeBSD, macOS and the Dropbear SSH server as unaffected. Musl-based systems such as Alpine, OpenWrt, postmarketOS, Void and Chimera are the ones to check.

Is Alpine Linux affected by the OpenSSH password bypass?

Yes, on default settings, once two more things are true. Alpine's November 5, 2026 advisory says its standard openssh-server package is built without PAM and leaves password login on. A server is exposed when one account has a single asterisk as its password field and another local account has a real SHA-256 or SHA-512 hash. The openssh-server-pam package with UsePAM yes is safe, and so are cloud-init images.

How do I check if my server is vulnerable to CVE-2026-123158?

Run four checks as root. The command ldd --version shows whether you are on musl. The command sshd -T shows whether password authentication is on. Then list accounts in /etc/shadow whose field is a single asterisk, and accounts with a SHA-256 or SHA-512 hash. If all four are positive and your package predates the fix, you are exposed. The check.sh script in the oz9un/sshole GitHub repository automates this, but it reads only the version banner.

Which Alpine package versions fix the OpenSSH password bypass?

Alpine's November 5, 2026 advisory lists openssh 10.6_p2-r0 on edge, 10.3_p1-r2 on 3.24, 10.2_p1-r1 on 3.23, 10.0_p1-r11 on 3.22, 9.9_p2-r1 on 3.21, 9.7_p1-r6 on 3.20, 9.6_p1-r3 on 3.19, 9.3_p2-r4 on 3.18, 9.1_p1-r7 on 3.17 and 9.0_p1-r6 on 3.16. Point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include them. Restart sshd after upgrading.

Why does a long password bypass OpenSSH on musl?

Three projects' changes collided. Since August 2012, musl's crypt() rejects keys over 256 bytes and returns an asterisk on failure. Since OpenSSH 7.3p1 in 2016, sshd hashes the password for accounts with no usable hash using another account's salt. Since Alpine 3.16 in 2022, root's password field is an asterisk. So sshd hashes a 300-character password, musl fails and returns an asterisk, and that equals the stored field.

How do I mitigate CVE-2026-123158 if I cannot upgrade today?

Set PasswordAuthentication no and restart sshd. Alpine, Wakefield and OpenSSH's Damien Miller all gave this workaround on November 5, 2026, and Wakefield says it closes the flaw completely. Test a key login first and keep your session open. Alpine releases older than 3.19 do not read /etc/ssh/sshd_config.d by default, so a drop-in file does nothing there. Confirm the result with sshd -T and grep.

How can I tell if someone already used this bug on my server?

Search your SSH logs for an Accepted password line naming an account that has no password, such as alpine, root or a key-only deploy user. Alpine logs to /var/log/messages. Wakefield calls such an entry a strong sign the flaw was used. Alpine's November 5, 2026 advisory also says to review doas use, recently created users, files and authorized keys. If you cannot rule out a login, treat the machine as compromised.

Can an attacker get root through CVE-2026-123158?

Sometimes. Direct root login needs PermitRootLogin yes, because OpenSSH's default of prohibit-password blocks it even though root on Alpine has a single asterisk as its field. The wider path is another account that can become root. Alpine's advisory says official qcow2, VHD and AMI images from 3.18.11 through 3.24.3 ship an alpine user with passwordless doas, exploitable once any SHA-512 hash exists on the machine.

Is CVE-2026-123158 being exploited in the wild?

None had been reported as of November 6, 2026, according to Ostorlab, and Ethiack said the same a day earlier. The CVE was not in CISA's Known Exploited Vulnerabilities catalog on that date. CISA's enrichment on the CVE record marks exploitation as poc, meaning a public proof of concept exists. Reproduction labs are on GitHub and the attack is short, so check the record again before you rely on this answer.

Are Alpine Docker containers affected by the OpenSSH bug?

Only if the container runs sshd. Alpine's November 5, 2026 advisory says Docker and other container users that do not run sshd in the container are not affected, so an ordinary app image built on Alpine is fine. A container that installs openssh-server, leaves password login on, and has both a single-asterisk account and a real hash is exposed. Rebuild those images on the fixed package and redeploy them.

Who found the OpenSSH musl bug, and how?

Özgün Kültekin of Wakefield found it and reported it on November 3, 2026. Wakefield built OpenSSH with glibc and musl, with and without PAM and shadow passwords, then had AI agents run about 17,600 unusual login attempts. Every build agreed on every attempt except OpenSSH on musl without PAM. Wakefield says the OpenSSH team sent a patch in under an hour, and 10.6p2 shipped on November 5, 2026.

Sources

• OpenSSH release notes, 10.6p2 entry (OpenSSH, November 5, 2026)
• OpenSSH 10.6p2 announcement text (OpenSSH, November 5, 2026)
• Security advisory: openssh-server password authentication bypass (Alpine Linux, November 5, 2026)
• Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 released (Alpine Linux, November 5, 2026)
• The sshole write-up (Özgün Kültekin, November 2026)
• OpenSSH Password Authentication Bypass on musl Linux (Wakefield, November 5, 2026)
• oz9un/sshole repository: README, check.sh, poc, patch (GitHub, read November 6, 2026)
• sshole timeline (GitHub, read November 6, 2026)
• Commit 4353fdc, avoid password authn bypass (openssh-portable on GitHub, November 2026)
• musl commit b3c4cc12, make crypt return an unmatchable hash rather than NULL on failure (August 9, 2012)
• musl commit 88bf5a8a, add sha256/sha512 crypt (August 29, 2012)
• CVE-2026-123158 record (CVE.org, November 5, 2026)
• Damien Miller's OpenSSH 10.6p2 announcement (Hachyderm, November 5, 2026)
• Rich Felker's reply on Dropbear and musl (Hachyderm, November 5, 2026)
• "sshole": password authentication bypass, OpenSSH + musl libc (oss-security, November 5, 2026)
• Critical security vulnerability affects OpenSSH on Alpine Linux systems (LWN, November 5, 2026)
• OpenSSH flaw lets attackers log into password-disabled Linux accounts (BleepingComputer, November 5, 2026)
• CVE-2026-123158 (sshole): OpenSSH Password Bypass on Alpine Linux (Ethiack, November 5, 2026)
• OpenSSH musl Password Bypass, Fixed in 10.6p2 (Ostorlab, November 6, 2026)
• OpenSSH Password Authentication Bypass on Alpine Linux (OX Security, November 5, 2026)
• sshole thread (Hacker News, November 5, 2026)
• Official alpine repository data (Docker Hub API, read November 6, 2026)
• sshd(8) manual (OpenBSD, read November 6, 2026)
• sshd_config(5) manual (OpenBSD, read November 6, 2026)
• GDPR Article 33 (gdpr-info.eu, read November 6, 2026)
• Cost of a Data Breach Report 2026 (IBM, read November 6, 2026)

Sources checked on November 6, 2026. Package versions and exploitation status keep moving, so check your vendor's page before you trust a version string from this post.