OpenSSH on Alpine: critical password authentication bypass — what to check on VPS and containers

On 5 November 2026 Portable OpenSSH 10.6p2 was released with a critical mitigation: a password authentication bypass exploitable through sshd on Linux systems that use musl with PAM disabled. That is the typical profile of Alpine Linux, often used in containers and lean cloud images. The same day Alpine published a dedicated security advisory.

For a Ticino SME the practical question is not only “are we on Alpine or Ubuntu?”, but: where is an sshd reachable, on which OS, and with which login method? Many offices run Ubuntu VPS or Infomaniak hosting (glibc + PAM): those are outside the stated scope. Risk rises if you (or a supplier) run Alpine containers or VMs with SSH exposed and password login still enabled.

What OpenSSH and Alpine say

In the release notes the OpenSSH team states that the root cause is considered outside sshd, but it is exploitable via sshd and can be avoided there. The bug was reported by Özgün Kültekin (Wakefield). Alpine summarises the operational impact: under configuration conditions typical of Alpine installs without PAM, someone who can reach the SSH port may authenticate without knowing a valid password. At the time of Alpine’s advisory no CVE identifier had been assigned.

Damien Miller (OpenSSH), in his release note also covered by LWN, made three points useful for operators:

• the issue affects Linux with musl and without PAM (Alpine is the usual example);
• it does not affect non-Linux systems, Linux with glibc, or Linux that uses PAM for password authentication;
• the release was rushed because AI agents have been rediscovering known bugs within hours, so long embargoes mainly help attackers.

He also confirmed that a build with PAM available but UsePAM no remains in scope. Alpine notes that openssh-server-pam with UsePAM yes is not affected; openssh-server (without PAM) or PAM with UsePAM no is affected if PasswordAuthentication is yes.

Who is out and who is in, in practice

Typically out of scope (per OpenSSH and Alpine): Debian/Ubuntu-class servers with glibc and password auth via PAM; systems with PasswordAuthentication no; containers that do not run sshd at all; cloud images already set (often via cloud-init) to accept SSH keys only.

In scope and worth checking now: Alpine hosts (supported releases and older branches) with sshd listening, OpenSSH without PAM or with PAM off, and password login still enabled. That includes small VPS boxes, bastions, CI runners and Alpine-based appliances left reachable from the internet “just for emergency access”.

What to check in the office

1. SSH inventory. List every machine, VM and container running sshd and where it is reachable from (internal network only, VPN, internet). If port 22 (or another SSH port) is open to the internet, treat it as top priority. The same inventory mindset applies when reviewing exposed services: we covered NAS and port forwarding in our 4 November article.
2. Operating system and libc. On typical Ubuntu/Debian/Infomaniak hosts you are outside the musl+no-PAM case. On Alpine, “slim” images or musl-based appliances, treat the host as potentially affected until package and configuration are verified.
3. Login method. Prefer SSH keys and disable password login where it is not needed. Access security levels (password, SMS, passkey) are explained in our article on the FOCS five levels.
4. OpenSSH version and daemon restart. Alpine stresses that upgrading the package alone does not replace a running daemon: restart sshd after the upgrade. Alpine branches listed in the advisory (from edge through 3.16 and later) have fixed packages; upstream OpenSSH points to 10.6p2 for the mitigation.
5. Suppliers and containers. Ask whoever runs hosting, Kubernetes or CI whether any Alpine nodes or images expose SSH. A container without sshd is out of scope; one with SSH and passwords is not.

Defensive mitigations

Two paths close the hole, as Alpine states:

1. Update the OpenSSH/Alpine package to the fixed version for your branch and restart sshd.
2. If you cannot update yet: set PasswordAuthentication no (keys only), first confirm that key login works and keep the current session open until you have tested a new login; then restart sshd.

We do not publish exploitation steps or payloads: the goal is to close exposure, not reproduce it. For other recent server and web stack flaws, see our end-of-October overview.

Frequently asked questions

Our VPS is Ubuntu on Infomaniak: do we need to act today?

According to OpenSSH, Linux with glibc and password authentication through PAM is not affected by this issue. Keeping OpenSSH updated and preferring SSH keys remains good practice, but it is not the same Alpine/musl-without-PAM scenario.

We only use Alpine-based Docker containers without SSH inside: are we at risk?

Alpine states that systems that do not run sshd in the container are not affected. The risk is environments where SSH is listening and reachable.

We upgraded the package but did not restart sshd: is that enough?

No. Alpine explicitly warns that upgrading the package does not replace a running daemon: sshd must be restarted.

Is there a CVE yet?

As of Alpine’s advisory (5 November 2026) no CVE identifier had been assigned. Follow the OpenSSH 10.6p2 notes and the Alpine advisory rather than an invented CVE number.

Our approach

ElaraTeq Sagl helps SMEs and practices in Ticino inventory SSH access, choose between keys and passwords, and plan updates on VPS, containers and hosting in Switzerland (hosting, consulting). To review your exposure you can contact us.

Sources

• OpenSSH, Portable OpenSSH 10.6p2 release notes, 5 November 2026
• Alpine Linux, Security advisory: openssh-server password authentication bypass, 5 November 2026
• Damien Miller, OpenSSH 10.6p2 announcement, 5 November 2026
• LWN.net, Critical security vulnerability affects OpenSSH on Alpine Linux systems, 5 November 2026