Security: OpenSSH 10.3p1 vulnerable to password authentication bypass / SSHHole (CVE-2026-123158

NethSecurity
1

Hi,

NethSecurity 8.8.0 currently ships with openssh-server-10.3_p1-r1 pre-installed and linked against musl libc without PAM support, which is affected by CVE-2026-123158 (CVSS 8.1, dubbed SSHHole / *sshole) — a password authentication bypass in sshd(8) when interacting with musl’s crypt() implementation:

root@nethsec:~# apk list -I | grep openssh
openssh-keygen-10.3_p1-r1 x86_64 {feeds/packages/feeds/packages/net/openssh} (BSD ISC) [installed]
openssh-server-10.3_p1-r1 x86_64 {feeds/packages/feeds/packages/net/openssh} (BSD ISC) [installed]
openssh-sftp-server-10.3_p1-r1 x86_64 {feeds/packages/feeds/packages/net/openssh} (BSD ISC) [installed]
root@nethsec:~# ldd /usr/sbin/sshd
        /lib/ld-musl-x86_64.so.1 (0x7f19c6733000)
        libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x7f19c6145000)
        libz.so.1 => /usr/lib/libz.so.1 (0x7f19c6131000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7f19c6113000)
        libc.so => /lib/ld-musl-x86_64.so.1 (0x7f19c6733000)
root@nethsec:~# netstat -tlpn | grep 22
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      2256/dropbear
tcp        0      0 :::22                   :::*                    LISTEN      2256/dropbear

On musl-based systems with PAM disabled and password authentication enabled (PasswordAuthentication yes), submitting a password between 257 and 1024 bytes causes musl’s SHA-512 crypt() to fail and return the literal string "*". Because sshd borrows a salt from an existing password-protected account (such as root) to prevent username timing enumeration, it compares the "*" error return value against the stored password field in /etc/shadow. Any account whose password field is set to "*" (such as key-only or passwordless accounts) matches "*" == "*" and grants remote login without a valid password.

By default, NethSecurity 8.8.0 uses dropbear on port 22 (which is not affected by CVE-2026-123158) and sshd is not running out of the box (no hostkeys available). However, because openssh-server is pre-installed in the base image alongside openssh-sftp-server, any administrator who enables sshd (either to replace dropbear or on a secondary port) with password authentication active is exposed.

In upstream Portable OpenSSH, this vulnerability is fixed in OpenSSH 10.6p2 (released on 2026-11-05) by rejecting stored password hashes that are too short to represent a valid hash.

References:

2

Thanks for the report, Antonin.

You’re right that the OpenSSH package in NethSecurity has the vulnerable code: OpenSSH built against musl, without PAM. But default installs can’t be exploited this way.

  • The main SSH server is Dropbear, not OpenSSH. Dropbear runs on port 22 and isn’t affected by SSHHole.
  • The OpenSSH service is disabled at first boot. /etc/uci-defaults/99-nethsec-sshd runs /etc/init.d/sshd disable, so sshd never starts on its own.
  • OpenSSH is used only for Nethesis remote support (don). It’s in the image only because the ns-don package needs it. sshd runs only while a support session is active, with its own config:
    • It listens only on the remote support VPN address (tunDON, port 981). It’s never reachable from LAN or WAN.
    • PasswordAuthentication no and ChallengeResponseAuthentication no are set, so the faulty password check is never reached.
    • Only root can log in (AllowUsers root), and only with the Nethesis public key.
    • It stops when the session ends.

The attack needs password login turned on, so it doesn’t work against this setup. Only an admin who manually enables the system sshd with password login could be exposed. If you’ve done that, set PasswordAuthentication no or switch back to Dropbear.

We’ll update OpenSSH to 10.6p2 in a future release, once it reaches the OpenWrt package feed.

3

As I mentioned earlier, I have actually replaced Dropbear with OpenSSH on several OpenWrt (and even NethSecurity) systems myself: Replace Dropbear to OpenSSH + SFTP

4

I’m curious: why you did the change?

5

Mainly for tunneling and advanced features — Dropbear handles basic local (-L) and remote (-R) port forwarding fine, but it lacks support for dynamic SOCKS proxy (ssh -D on the server side sometimes hits limits with more complex chaining), UNIX socket forwarding, X11 forwarding, or the granular Match User/Address directives available in sshd_config.