OpenSSH flaw exploited within hours: patch out, servers at risk

The OpenSSH project shipped version 10.6p2 on 5 November 2026, closing a critical authentication flaw nicknamed "SSHole". Tracked as CVE-2026-123158, it lets a remote attacker log into accounts that are supposed to have no password at all, including root, key-only deployment users and some LDAP accounts, without knowing any credential. The Hacker News reports a CVSS score of 8.1.

The root cause is surprisingly old. A 2016 fix for a username-enumeration issue (CVE-2016-6210) introduced a path where, under specific conditions, the password-hashing call fails and returns "*". Because "*" is also the marker for accounts with password login disabled, sshd sees a match and grants access. All an attacker has to send is a password longer than 257 bytes.

Who is affected and who is not

Only Linux systems built against the musl C library that do not verify passwords through PAM are vulnerable. Alpine Linux ships its default openssh-server package exactly that way, and the same applies to OpenWrt, Buildroot and Yocto based systems as well as a large number of Docker images. Glibc-based distributions such as Debian, Ubuntu and Fedora, installations that use PAM, Dropbear and OpenBSD are not affected.

Why this one cannot wait

Help Net Security reports that the first exploitation attempt was observed less than nine hours after the CVE was published, and security firm Previdian confirmed an attacker gaining root on an Alpine Linux honeypot. According to The Hacker News, attempts had grown to 20 from 13 distinct IP addresses across nine countries by 8 November. CISA added the flaw to its Known Exploited Vulnerabilities catalogue on 9 November 2026 and set 12 November 2026 as the patch deadline for US federal agencies.

What this means for Turkish SMEs

Plenty of smaller companies will assume they are safe because they "do not use Alpine". In practice Alpine is one of the most common base layers for container images. The Docker host in the office, the image behind an in-house application, a backup agent or a plug-in running on a NAS can quietly be Alpine based. The same is true of OpenWrt routers and embedded devices sitting in branch offices and on site, and because those devices usually fall outside the normal patch calendar the exposure tends to stay open far longer.

There is a legal dimension as well. If a server that processes personal data is reached with root privileges, that is a data breach, and Turkish Law No. 6698 obliges the controller to notify the Personal Data Protection Board. That is why the backward-looking review matters as much as the patch: installing the update does not answer the question of whether someone already logged in.

What Kamer Bilişim recommends

• Inventory by libc, then upgrade. Determine the OpenSSH version running inside your container images and on your embedded devices, and install your distribution's patched package anywhere it predates 10.6p2. Installing the package does not touch the running sshd process, so do not skip the service restart or the hole stays open.
• Turn password-based SSH login off entirely. As the OpenSSH maintainers themselves advise, disable PasswordAuthentication and allow key-based access only. Most organisations have no real need to expose SSH and management interfaces to the internet; move them behind a VPN or a firewall rule.
• Prove whether you were breached. Search your logs for "Accepted password for" entries naming accounts that should never accept a password, and review newly created users, authorized_keys files and doas or sudo activity. If you cannot rule a login out on a given machine, the safe assumption is that it is compromised and should be rebuilt.

If you would like us to run these checks across your server and container estate with you, reach us through our contact page. We provide on-site support across the Anatolian side of Istanbul and remote support elsewhere.

Source: The Hacker News, Help Net Security, CISA Known Exploited Vulnerabilities Catalog