OpenSSH CVE-2026-123158: Alpine Login Bypass and What to Do

On 5 November 2026, OpenSSH 10.6p2 was released. OpenSSH is the software most Linux servers use for remote login. This release fixes a flaw that lets someone log in to some Linux systems without knowing the password (CVE-2026-123158). On 9 November, the US agency CISA added it to its list of vulnerabilities known to be exploited (KEV).

The flaw affects systems that build OpenSSH in a particular way, such as Alpine Linux. Red Hat Enterprise Linux and Ubuntu say they are not affected. This article explains how to tell whether your servers are affected, how to update, what to do if you cannot update yet, and how to check the logs.

What is the flaw, and why is it dangerous?

When sshd runs without PAM, it checks passwords itself. According to Alpine Linux, the musl function it uses to hash passwords returns "*" when the password is too long. But "*" is also what the system stores for accounts that have no password. So the two match, and the login succeeds.

Alpine says the attack takes one connection, works every time and needs no retries. The OpenSSH developers say the root cause lies outside OpenSSH, but because it can be exploited through sshd, they added a check in sshd to block it.

Are your servers affected?

According to Alpine Linux, a system is affected only when all four of these are true:

• sshd runs without PAM (Alpine's openssh-server package, or openssh-server-pam with UsePAM no)
• Password login is on (PasswordAuthentication yes, the default)
• An account has "*" as its password field (root on Alpine since about 3.16, key-only users and others)
• At least one account on the same machine has a normal password hash (starting with $5$ or $6$)

Note: other systems and devices that build OpenSSH with musl and without PAM may also be affected. For appliances, check the vendor's information.

You can check a server like this (administrator rights needed):

cat /etc/os-release
sshd -T | grep -i -E 'usepam|passwordauthentication'
awk -F: '$2 == "*" {print $1}' /etc/shadow

The first line shows the OS, the second shows the PAM and password login settings, and the third lists accounts whose password field is "*".

Fixed packages for Alpine Linux

These are the fixed openssh packages Alpine Linux published. This version or newer is fixed.

Note: packages were also published for the unsupported 3.16 to 3.20, but other problems there stay unfixed, so we recommend moving to a supported release. If you build OpenSSH yourself, use 10.6p2 or later.

Five steps to respond

1. List your Alpine servers and containers

   Check virtual machines, Docker containers and cloud images. Only those running sshd are affected. Containers without sshd are not.

2. Update the package

   Run apk upgrade -U -a and confirm the version matches the table above. For containers, rebuild the image and replace them.

3. Restart sshd

   Updating the package does not replace the sshd that is already running. Run rc-service sshd restart.

4. Turn off password login

   After confirming that key login works, set PasswordAuthentication no. This protects you against problems like this one.

5. Check the logs

   Use the checks in "How to look for signs of an attack" below.

If you cannot update yet

Alpine Linux and OpenSSH give the same workaround: turn off password login. Add this line to the sshd configuration and restart sshd:

PasswordAuthentication no

Limiting which IP addresses can reach SSH with a firewall is another common way to reduce the risk.

How to look for signs of an attack

Alpine Linux recommends checking:

• sshd logs for "Accepted password for" an account that has no password
• Use of doas (the tool for running commands as administrator) that you don't recognise
• New users, files or SSH keys (authorized_keys) that you didn't add

Alpine Linux advises that if the machine was reachable from the internet and you cannot rule out a login, you should treat it as compromised. In that case, consider rebuilding it. Our article "Linux kernel vulnerability" also covers how to check Linux servers.

Easy-to-miss points in containers and the cloud

Because Alpine is so light, it is common in Docker containers and small cloud machines. Sometimes an sshd added for development is still running in production.

• Are old container images of unknown origin running in production?
• Is sshd running inside a container? (Usually it isn't needed.)
• Is an SSH port (such as 22) open to the internet?

If the person in charge has left, or you can't reach the company that built the system, see "taking over system maintenance".

Doing nothing vs. acting now

Let Digi Dinos help

Digi Dinos supports companies with DX, security, and system operations and maintenance. We are ISO 27001 certified and offer server and cloud operations and 24/7 monitoring (NOC). Our team works with you in Japanese.

• Server and container inventory: we list which OS and software run, and at which versions.
• Updates and configuration review: we review SSH settings and move you to key login, with a clear plan even for systems that can't stop.
• Monitoring and takeover: we can take over servers that another company used to manage.

Frequently asked questions