Quick Answer: The OpenSSH 10.6p2 update, released 2026-11-05, patches a password authentication bypass in sshd on some Linux systems built with musl libc and PAM disabled, a setup common on Alpine Linux. The root cause sits outside sshd, but sshd can block the exploit path, and that workaround ships in 10.6p2. If you run Alpine without PAM, upgrade and verify your build today.
This OpenSSH 10.6p2 update matters more than a routine version bump if you run sshd on Alpine without PAM. The OpenSSH team published the release on 2026-11-05, and the security note is short but serious. Most of the risk comes down to how your sshd was built, so you can check your exposure in a few minutes. Here's what the release notes say, what they leave open, and how to act on it.
What the OpenSSH 10.6p2 Update Actually Fixes
The security entry in the OpenSSH release notes is brief. It says sshd could be exploited for a password authentication bypass on some Linux systems built and run with PAM support disabled. The reporter, Özgün Kültekin of Wakefield, found the issue, and the notes credit that work directly.
The detail that matters most is the root cause. The OpenSSH team says the root cause lies outside sshd, yet the bug is reachable through sshd and can be avoided there. That's an unusual split. You can't fix the underlying defect in sshd alone, but you can close the path an attacker uses to reach it.
So why would a bug living outside sshd still count as sshd's problem? Because the attacker doesn't care whose code is wrong. They only care that a login request reaches the vulnerable code path. That's why the workaround lives in sshd, and why the update matters to you even if the defect isn't in OpenSSH's own source.
The release notes don't include a CVE identifier in the text I reviewed. Check your distribution's advisory feed for a mapped identifier before you write up an incident report.
Here's where it gets practical. The notes describe the bypass in terms of build configuration, not just version, and that changes how you triage it.
Why the musl and No-PAM Combination Is the Risk Window
The affected combination has two parts: musl libc and a build with PAM disabled. Alpine Linux uses musl by default, and minimal images and container builds often compile OpenSSH without PAM to keep dependencies small. That's the setup this bug targets.
Here's the counter-intuitive part. Most hardening guides tell you that dropping PAM shrinks the attack surface. Fewer modules, fewer moving parts, fewer things to break. That advice is usually sound, but it's incomplete. This release shows that a smaller build still has an authentication path, and that path needs the same scrutiny as the rest of sshd. Removing PAM doesn't remove the need to verify how password authentication behaves on your specific build.
Consider a typical case. A team builds a hardened sshd image on Alpine with --without-pam to match its security baseline. Six months later, the image is still running the earlier version because nobody rebuilds unless something breaks. The image passes its compliance scan, since the scanner checks configuration files rather than the auth behaviour of the binary. That gap between "configured safely" and "behaves safely" is the failure mode this release exposes.
If you're on a PAM-enabled build, the notes don't say you're affected by this specific bypass. Upgrade anyway, because the release carries other fixes you'll want, and you don't want to guess which build flags your fleet uses.
How to Check Whether Your sshd Is Exposed
Work through these steps on each Alpine host. Each one takes a minute or less.
- Check your installed version. Run
ssh -Vandapk info openssh. Anything older than 10.6p2 needs attention. - Check for PAM linkage. Run
ldd $(command -v sshd) | grep -i pam. If the command prints a libpam line, your binary links PAM. If it prints nothing, the binary doesn't link PAM, which fits the affected profile. - Check the runtime setting. Run
sshd -T | grep -i usepam. This shows the effective configuration, which matters even on PAM-linked builds. Treat thelddcheck as a strong signal, not proof, because a binary can link a library and still have PAM turned off at runtime. - Confirm the libc. On Alpine,
/lib/ld-musl-*.so.1should exist. If you're on musl and your sshd lacks PAM, you're in the window.
Once you know you're exposed, move to the fix. The simplest path is apk upgrade openssh followed by rc-service sshd restart, since Alpine uses OpenRC. Then re-run ssh -V to confirm the version changed.
Be careful, though. Package repositories often lag upstream by days or weeks, so the mirror may not carry 10.6p2 when you read this. If apk still shows an older version, don't assume the update is available. Build from source instead, and verify the tarball first.
Building 10.6p2 From Source: Verify Before You Trust
If you compile your own sshd, which many Alpine users do to control build flags, verify the tarball before you compile anything. The release notes list the checksums:
- SHA1:
c91a0b7860c80f29db874044af4d1a6f906231d9 - SHA256 (base64):
muRIcgkM8vBrPPn/FH5/FvMJZxNAdj7S+ZJIOYrinVs=
The SHA256 value is base64-encoded, not hexadecimal. This trips up people constantly. A hex comparison will fail even on a good file, and that failure can push a rushed admin to skip verification altogether. Compare the base64 output directly with openssl dgst -sha256 -binary openssh-10.6p2.tar.gz | openssl base64 -A.
Verify the PGP signature too. The release key is available from the OpenBSD mirror at https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASE_KEY.asc.
Here's the trade-off. Building from source gives you control over PAM and other flags, but it also makes you responsible for rebuilding on every release. Given how fast this project is moving now, that's a real operational cost. If you go this route, automate the rebuild so a future release doesn't leave you exposed for weeks.
The Other 10.6 Changes You Can't Ignore
The 10.6 line brought several changes beyond the Alpine fix. Some of them can break scripts or change behaviour, so review them before you roll out the update.
| Change | Release | Who's affected | Action |
|---|---|---|---|
| Password auth bypass workaround (musl, no PAM) | 10.6p2 | Alpine and musl builds without PAM | Upgrade and confirm PAM linkage |
$ and \ refused in command-line usernames | 10.6 | Scripts passing untrusted input to ssh | Validate usernames; User in config files is exempt |
| LZ77 dictionary coder disabled | 10.6 | Anyone using the Compression option | Move to application-level compression |
scp -R flag deprecation warning | 10.6 | Scripts using remote-to-remote scp -R | Plan a migration; warning appears on stderr |
| Platform deprecation (FD passing and root PTY) | 10.6 | SCO OpenServer 5, QNX 6, similar old systems | No action for most; affected platforms should plan |
The username restriction deserves the most attention. The release tightens ssh(1) so command-line usernames containing $ or \ are refused. The stated motivation is to block shell injection through ProxyCommand and Match exec. Usernames set in configuration files are exempt, which means your config-driven setups keep working. Still, the OpenSSH team says plainly that this mitigation can't be absolute, and they continue to recommend against passing untrusted input directly to ssh.
The compression change surprises people more. OpenSSH disabled the LZ77 dictionary coder to mitigate side-channel leaks in multiplexed channels. The attack, described in a preprint by Fabian Bäumer and Marcus Brinkmann in the arXiv paper 2609.07709, works by recovering secrets across channels that share one compression dictionary. The practical consequence is that the Compression option gets less effective. If you relied on it for bandwidth, switch to application-level compression. It's usually better anyway, and it's immune to this class of attack.
Why OpenSSH Is Shipping Faster Releases
The release notes contain a notable policy shift. The OpenSSH team says it has received many security reports that come from AI models or AI-assisted research. Many of these reports don't show security impact under a realistic threat model, but the team still welcomes them, especially when they include human triage, test cases, or proposed fixes.
The part that should change your patch cadence is this: the team has seen cases where a bug found by AI tools was later found independently by a different researcher. The team's inference is that adversaries who don't report bugs can likely find them too. The 10.6 release came out on 2026-10-06, and 10.6p2 followed on 2026-11-05, roughly a month later. That's the new rhythm.
Here's the honest trade-off. Frequent releases get fixes to you faster, but they also mean more churn. A monthly cadence can overwhelm a team that patches by hand. If your current process relies on quarterly maintenance windows, it won't keep up. Automate package updates for OpenSSH, subscribe to the release notes feed, and test on a staging host before fleet-wide rollout.
Frequently Asked Questions
What is the OpenSSH 10.6p2 update?
OpenSSH 10.6p2 is a portable release published on 2026-11-05. Its main security change is a workaround for a password authentication bypass in sshd on some Linux systems built with musl libc and PAM disabled. It also includes bugfixes already committed to the V_10_6 stable branch, such as a fix for a sub-second CPU spin when ChannelTimeout is set.
How do I fix the OpenSSH password bypass on Alpine?
Run apk upgrade openssh, then rc-service sshd restart, and confirm with ssh -V that you're on 10.6p2 or later. If your repository doesn't carry the new version yet, build from the verified 10.6p2 tarball. Check your PAM setup with ldd $(command -v sshd) | grep -i pam so you know whether your build was affected.
Does the OpenSSH 10.6p2 update affect me if I use PAM?
The release notes describe the bypass for builds with PAM disabled on musl-based Linux systems. They don't say PAM-enabled builds are affected by this specific issue. You should still upgrade, because the release contains other fixes, and it's safer than assuming your build flags match the advisory's scope.
Why does disabling PAM not automatically make sshd safer?
Disabling PAM removes one authentication layer, but it doesn't remove the authentication path itself. This bug shows that a smaller build still needs its password handling verified. Treat a no-PAM build as a configuration you have to test, not one you can assume is safe because it's smaller.
Use the OpenSSH 10.6p2 update as a prompt to audit your Alpine hosts today. The fix is simple once you know your build profile, but you can only confirm your exposure by checking. Run ssh -V and ldd $(command -v sshd) | grep -i pam on one Alpine host this week, and note the version and PAM status you find. Then pass this to whoever runs your Alpine images, especially if they've been building sshd without PAM "for security."