OpenSSH fixes SSHole, an exploited flaw that lets very long passwords into Alpine Linux servers

OpenSSH has released version 10.6p2 to fix SSHole (CVE-2026-123158), a flaw already being exploited that lets attackers into Alpine Linux servers with a very long password. It affects Linux systems with musl libc and PAM disabled. If you run Alpine with SSH exposed, update today or turn off password authentication.

Key facts

• The flaw is CVE-2026-123158 (CVSS 8.1), nicknamed SSHole. It affects Linux running OpenSSH on musl libc with PAM disabled, including Alpine Linux's default OpenSSH server configuration (The Hacker News).
• On those systems, some accounts accept any password between 257 and 1024 characters long, according to SecurityWeek.
• OpenSSH 10.6p2 fixes the flaw and the project rated it critical. Alpine has released fixed packages for all its versions up to 3.16.
• Previdian spotted the first exploitation attempt less than nine hours after the CVE was published and confirmed root access on an Alpine honeypot (The Hacker News).
• INCIBE-CERT, Spain's national CERT, published its advisory on 6 November 2026 with high severity (INCIBE-CERT).

Am I affected if my servers run Ubuntu, Debian or Windows?

No. According to Damien Miller of OpenSSH, non-Linux systems, Linux with glibc and systems that validate passwords through PAM are not affected. Ubuntu, Debian and RHEL use glibc. Windows is out of scope. Dropbear, OpenWrt's default SSH server, is not affected either.

The real risk sits with anyone running servers, virtual machines or containers on Alpine Linux with an OpenSSH server reachable from the internet. That's common in startups and SMEs with their own or cloud infrastructure, and among development and hosting providers. If someone else manages your infrastructure, this question goes to them.

How can a long password open the door?

When the password is too long, the hash calculation fails and returns '*'. That same value marks an account whose password is disabled. The code treats the match as a successful login.

The result is awkward: the exposed accounts are the ones without a password, such as those that only use an SSH key. Exactly the ones many teams consider the safest. The root cause is a 2016 patch for CVE-2016-6210, so the bug has been in production for years.

Is it really being exploited?

Yes. On the day the patch came out, no attacks had been reported. On 6 November it emerged that Previdian had logged eight attempts from an IP address geolocated in Japan. The attackers used oversized passwords, gained root on the honeypot and ran reconnaissance commands such as id, uname and hostname. That's the step before deciding what to do with the machine.

What to do today

1. Ask your IT team or provider for an inventory of Alpine systems with sshd running, including containers and virtual machines.
2. Update to OpenSSH 10.6p2 or install Alpine's fixed packages.
3. If you can't update today, set PasswordAuthentication=no in the sshd configuration or disable SSH on those systems, as Damien Miller recommends.
4. Restrict SSH access by IP, VPN or bastion host so it isn't open to the whole internet.
5. Review sshd logs from 5 November onwards: look for logins with abnormally long passwords or unexpected access.
6. If you have no Alpine systems with SSH, there's nothing else to do.

What it means for an SME

Less than nine hours between the CVE going public and the first exploitation attempt. If your patch cycle is measured in weeks, this flaw catches you with the door open. No need to panic, but you do need the ability to react the same day.

The hard part here isn't patching, it's knowing whether you run Alpine at all. It usually arrives inside container images or servers a provider set up, not through a deliberate choice. If nobody in your company can say within an hour which systems expose SSH and on which distribution, that's the gap SSHole exploits.

The second lesson is about configuration. Many teams think using SSH keys only protects them, yet the server still accepted passwords. Disabling password authentication server-wide, not account by account, and not exposing SSH directly to the internet would have neutralised this flaw before a patch existed. If you want to review how your infrastructure is exposed, our cybersecurity work covers exactly that inventory.

FAQ

I only use SSH keys. Am I safe?

Not necessarily. Accounts without a password, such as key-only ones, are precisely the affected ones if the server still accepts passwords. Set PasswordAuthentication=no or update.

Does it affect my OpenWrt router?

Not with the default setup. OpenWrt uses Dropbear, which is not affected.

I've already updated. Am I done?

Not quite. The flaw has been exploited for days, so check sshd logs from 5 November onwards for unexpected access.

Sources

• The Hacker News – Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot
• The Hacker News – OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux
• INCIBE-CERT – Avisos (Omisión de autenticación por contraseña en OpenSSH de Alpine Linux, 06/11/2026)