CVE-2026-123158 (SSHole): una contraseña larga entra por SSH en algunos servidores Alpine Linux

Qué hace el fallo

Alpine y algunas otras distribuciones Linux pequeñas usan musluna biblioteca C compacta que ofrece las funciones básicas que necesitan los programas; la mayoría de las grandes distribuciones usan glibc y compilan OpenSSH sin PAMun sistema de Linux que gestiona los inicios de sesión; con él, sshd delega la comprobación de la contraseña en un módulo aparte. Con esa configuración, sshd comprueba la contraseña por su cuenta: calcula el hash de lo que escribió el usuario y lo compara con el hash guardado para la cuenta.

Las cuentas sin contraseña, como root en las imágenes recientes de Alpine o los usuarios que solo entran con clave SSH, guardan un único * en ese campo. Según un análisis técnico de la empresa de seguridad Ostorlab, musl se rinde con contraseñas de más de 256 bytes y devuelve el texto * como señal de error. sshd compara entonces ese * con el * guardado, ve que coinciden y deja entrar. El registro CVE describe el mismo problema de forma más breve, como una mala interpretación de "si una cadena debe ser un hash de contraseña".

OpenSSH dice que considera que la causa de fondo está "fuera del propio OpenSSH", pero que puede bloquear el atajo en sshd. La corrección hace que sshd rechace los hashes guardados de menos de cuatro caracteres, así que un * solo ya nunca coincide.

A quién afecta

El aviso de Alpine enumera cuatro condiciones que deben cumplirse a la vez:

1. sshd funciona sin PAM: el paquete openssh-server, o openssh-server-pam con UsePAM no.
2. PasswordAuthentication está en yes, el valor por defecto de OpenSSH.
3. La máquina tiene una cuenta cuyo campo de contraseña es *. En Alpine eso incluye root (en la imagen base desde más o menos la versión 3.16), los usuarios que solo entran con clave, los usuarios de servicios de directorio como sssd o winbind y el usuario alpine de las imágenes tiny-cloud.
4. Al menos una cuenta local tiene un hash de contraseña real del tipo $5$ o $6$.

Entrar directamente como root requiere además PermitRootLogin yes, pero Alpine advierte de que doas puede abrir otro camino hasta root. Las cuentas bloqueadas (! en el campo de contraseña) no están afectadas, ni los contenedores Docker que no ejecutan sshd.

Qué gravedad tiene

El registro CVE, redactado por MITRE como CNACVE Numbering Authority, organización autorizada para asignar identificadores CVE y redactar la descripción oficial, le da un 8,1 (Alta) en CVSS 3.1, con el vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. OpenSSH lo califica de crítico. Alpine es más directo: a un atacante que llegue al puerto SSH le basta una conexión y una contraseña larga, y "funciona siempre" cuando se dan las condiciones.

Los ataques hasta ahora

Poco después del lanzamiento aparecieron códigos de demostración en GitHub, y la evaluación de la CISA en el registro CVE indica una prueba de concepto pública. A 8 de noviembre, el fallo no figura en el catálogo de vulnerabilidades explotadas de la CISA.

Dos empresas que mantienen sensores en internet han publicado lo que ven. GreyNoise registró el primer intento el 5 de noviembre a las 18:34 UTC y dice haber confirmado la explotación con éxito de sus propios señuelos, vulnerables a propósito, desde el 7 de noviembre, con 14 acciones tras el acceso desde cuatro direcciones. Previdian contó 19 intentos desde 12 direcciones de 8 países hasta el 8 de noviembre, pero advierte de que sus datos no muestran si alguno tuvo éxito. Ninguna de las dos ha informado de una organización real afectada.

El desarrollador de OpenSSH Damien Miller escribió que el equipo conoció el problema solo la víspera del lanzamiento y se dio prisa porque los agentes de IA ya redescubren fallos publicados "en cuestión de horas".

Qué hacer ahora

1. En Alpine, ejecuta apk upgrade -U -a y después rc-service sshd restart. Alpine insiste en que actualizar no sustituye el sshd que ya está en marcha. Las versiones 3.21.10, 3.22.8, 3.23.8 y 3.24.4 ya incluyen la corrección.
2. En otros sistemas Linux con musl y sin PAM, pasa a OpenSSH 10.6p2 o al paquete corregido de tu distribución.
3. Si todavía no puedes actualizar, configura PasswordAuthentication no. Antes comprueba que el acceso con clave SSH funciona, mantén una sesión abierta durante el cambio y verifícalo con sshd -T | grep -i passwordauthentication. Nuestra guía paso a paso para pasar el acceso SSH a claves explica cómo hacerlo sin quedarte fuera.
4. Busca señales de intrusión. Alpine recomienda buscar en /var/log/messages "Accepted password for" en cuentas sin contraseña, como root, alpine o los usuarios que solo usan clave, y revisar el uso de doas, los usuarios nuevos y los archivos authorized_keys. Si no puedes descartar un acceso, trata la máquina como comprometida.
5. Si generas imágenes de contenedor que ejecutan sshd, vuelve a crearlas desde una base de Alpine actualizada y recrea los contenedores.

Es el segundo atajo de acceso de la semana: en los cortafuegos de SonicWall, un fallo en la VPN permite a los atacantes saltarse SAML y la autenticación multifactor.