El proyecto OpenSSH publicó el 5 de noviembre de 2026 la versión 10.6p2 para cerrar CVE-2026-123158, un fallo que permite iniciar sesión por SSH sin conocer la contraseña en sistemas Linux que usan la biblioteca musl sin PAM, como Alpine Linux. Su descubridor, Özgün Kültekin, lo ha bautizado como *sshole y lo explica en sshhole.com. Alpine publicó ese mismo día su aviso de seguridad y paquetes corregidos para todas sus ramas desde la 3.16.
Las claves de SSHHole en OpenSSH para Alpine en 30 segundos
- OpenSSH lanzó el 05/11/2026 la versión 10.6p2 para corregir CVE-2026-123158, un fallo de autenticación en el servidor sshd.
- Afecta a Linux con musl y sin PAM, como Alpine, cuando el acceso con contraseña está activado.
- Una cuenta sin contraseña puede aceptar cualquier clave de entre 257 y 1.024 bytes si otra cuenta local tiene un hash.
- MITRE le asigna un CVSS 3.1 de 8,1 y CISA registra pruebas de concepto públicas.
- Alpine ya ofrece paquetes corregidos desde la rama 3.16 hasta edge.
El problema no está en la criptografía de SSH, sino en la forma en que sshd comprueba las contraseñas cuando no pasa por PAM (Pluggable Authentication Modules, el sistema modular de autenticación de Linux). El paquete openssh-server de Alpine se compila precisamente sin PAM, así que la configuración por defecto de la distribución entra en el grupo de riesgo si se cumplen el resto de condiciones. Según el aviso de Alpine, al atacante le basta con llegar al puerto SSH y una sola conexión, sin reintentos.
En LinuxGratis han publicado un análisis del fallo en el que su autor reproduce el comportamiento de la función crypt() en contenedores de Alpine y Debian, sin lanzar ataques contra sshd. Los datos que aporta coinciden con los avisos oficiales.
Un asterisco que musl y sshd interpretan de forma distinta
Cuando sshd funciona sin PAM, calcula el hash de la contraseña que escribe el usuario con crypt() y lo compara con el campo guardado en /etc/shadow. En las cuentas que no tienen contraseña ese campo contiene un asterisco (*), la convención de Unix para indicar que no se puede entrar con contraseña. Es lo habitual en usuarios que solo acceden con clave pública. Como ese campo es demasiado corto para contener una sal, sshd toma prestada la de otra cuenta del sistema, una medida que OpenSSH introdujo en 2016 para que el tiempo de respuesta no delate qué usuarios existen.
La pieza que falla es musl, la biblioteca estándar de C ligera que usa Alpine en lugar de glibc (la biblioteca de GNU que emplean Debian, Ubuntu o Fedora). Según el aviso de Alpine, el crypt() de musl devuelve la cadena * como indicador de error cuando la contraseña supera los 256 bytes. Ese asterisco es justo lo que guarda /etc/shadow en las cuentas sin contraseña, así que la comparación da por buena una clave que no lo es.
Con glibc y libxcrypt la función devuelve *0 en caso de error, que no coincide con *. El investigador también señala que las distribuciones que pasan por PAM nunca llegan a llamar a crypt() para una cuenta con asterisco. OpenSSH, en sus notas de la versión, sitúa la causa de fondo fuera de sshd, pero ha añadido la protección en su código porque el fallo se explota a través de él. Kültekin cuenta en su web que lo encontró compilando sshd con distintas combinaciones de biblioteca, PAM y shadow y lanzando unos 17.600 inicios de sesión anómalos; solo la combinación de musl sin PAM aceptaba lo que no debía.
Qué tiene que darse para que un sistema sea vulnerable
Alpine enumera cuatro condiciones que deben cumplirse a la vez: usar openssh-server sin PAM (o openssh-server-pam con UsePAM no), tener PasswordAuthentication yes, que es el valor por defecto de OpenSSH, contar con al menos una cuenta con * en el campo de contraseña y tener otra cuenta local con un hash de tipo $5$ o $6$. Con una sola cuenta con contraseña real basta para que todas las que no la tienen queden expuestas.
Entre las cuentas con asterisco está root, que se distribuye así desde Alpine 3.16, aunque la opción por defecto PermitRootLogin prohibit-password la protege salvo que se haya cambiado a yes. También cuentan los usuarios creados solo para acceso con clave, los que llegan de un directorio LDAP a través de musl-nscd y el usuario alpine de las imágenes oficiales tiny-cloud (qcow2, VHD y AMI) entre las versiones 3.18.11 y 3.24.3. Ese usuario tiene doas sin contraseña, de modo que, según Alpine, un atacante que entre con él puede convertirse en root en cuanto exista en la máquina algún hash $6$, por ejemplo si un administrador fija una contraseña de consola.
Quedan fuera los contenedores Docker que no ejecutan sshd, los sistemas con PasswordAuthentication no, los que usan openssh-server-pam con UsePAM yes, las cuentas bloqueadas con ! y las imágenes en la nube configuradas con cloud-init, que desactiva el acceso por contraseña. Las distribuciones con glibc tampoco están afectadas.
Gravedad, pruebas de concepto y alcance fuera de Alpine
El registro CVE (Common Vulnerabilities and Exposures, el catálogo público de vulnerabilidades) lo dio de alta MITRE el 5 de noviembre como entidad emisora, con una puntuación CVSS (Common Vulnerability Scoring System) 3.1 de 8,1, gravedad alta, y el vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. La complejidad figura como alta porque deben coincidir varias condiciones de configuración. El NIST todavía no ha publicado su propia valoración en la base de datos NVD. La debilidad se clasifica como CWE-394, un valor de retorno inesperado.
En cuanto a la explotación, la evaluación de CISA incorporada al registro marca la vulnerabilidad con el estado «poc», es decir, con prueba de concepto (PoC) pública, impacto técnico total y no automatizable. Entre las referencias del CVE figuran dos repositorios de reproducción en GitHub. Ninguna de las fuentes consultadas habla, por ahora, de ataques reales. La web del investigador muestra una demostración con un primer intento con una contraseña incorrecta, rechazado, y un segundo con una cadena muy larga de letras que abre una sesión de root. Kültekin indica que una cuenta con asterisco necesita antes un intento fallido, un matiz que no aparece en el aviso de Alpine, donde se habla de un único intento.
Fuera de Alpine, el investigador cita otros entornos con musl como OpenWrt, Buildroot o Yocto, además de muchas imágenes Docker. La exposición depende de cómo se haya compilado OpenSSH y de la configuración. Si se usa Dropbear en lugar de OpenSSH, Kültekin indica que no hay problema. Las fuentes no mencionan de forma expresa Void Linux en su variante musl, así que en esa y otras distribuciones similares conviene revisar las mismas tres cosas: sshd sobre musl, sin PAM y con contraseñas habilitadas.
El nombre recuerda a regreSSHion (CVE-2024-6387), pero el tipo de fallo es distinto. Aquel permitía la ejecución remota de código (RCE) por una condición de carrera en glibc, mientras que este es una omisión de la autenticación que solo se da con musl y sin PAM.
Cómo comprobar la versión y actualizar OpenSSH en Alpine
Quien compile OpenSSH por su cuenta necesita la versión 10.6p2 o posterior. En Alpine, los paquetes de las ramas estables llevan un parche con la misma corrección y estas son las versiones mínimas, según el aviso de la distribución:
| Rama de Alpine | Paquete openssh corregido | Versión puntual con el parche |
|---|---|---|
| edge | 10.6_p2-r0 | No aplica |
| 3.24 | 10.3_p1-r2 | 3.24.4 |
| 3.23 | 10.2_p1-r1 | 3.23.8 |
| 3.22 | 10.0_p1-r11 | 3.22.8 |
| 3.21 | 9.9_p2-r1 | 3.21.10 |
| 3.20 | 9.7_p1-r6 | Sin soporte regular |
| 3.19 | 9.6_p1-r3 | Sin soporte regular |
| 3.18 | 9.3_p2-r4 | Sin soporte regular |
| 3.17 | 9.1_p1-r7 | Sin soporte regular |
| 3.16 | 9.0_p1-r6 | Sin soporte regular |
Para ver qué hay instalado, apk info -v openssh muestra la versión exacta del paquete y ssh -V la del cliente. Lo que hay que comparar con la tabla es la revisión del paquete, porque en las ramas estables el número de OpenSSH no cambia (la 3.24, por ejemplo, sigue en 10.3_p1). La actualización se hace con apk, y Alpine insiste en reiniciar el servicio después, ya que actualizar el paquete no sustituye al demonio que ya está en marcha:
apk info -v openssh
apk update && apk upgrade openssh
# o actualizar todo el sistema, como recomienda Alpine:
apk upgrade -U -a
rc-service sshd restartSi no se puede actualizar todavía, la mitigación que propone Alpine es desactivar el acceso con contraseña. Antes conviene comprobar que el acceso con clave funciona y mantener abierta la sesión actual hasta probar una nueva. El aviso no menciona LoginGraceTime, el ajuste que se recomendaba contra regreSSHion, porque aquí no sirve de nada:
mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthenticationEl directorio sshd_config.d solo se lee por defecto desde Alpine 3.19. En versiones anteriores hay que cambiar la directiva en /etc/ssh/sshd_config, incluidos los bloques Match, y el aviso de Alpine incluye un comando sed que lo hace y guarda una copia del fichero original.
En contenedores, la actualización dentro de una instancia en marcha no basta: hay que reconstruir las imágenes que instalan openssh-server partiendo de una base actualizada (por ejemplo, con docker build --pull --no-cache) y volver a desplegarlas. Las instancias creadas a partir de imágenes tiny-cloud anteriores a las versiones puntuales corregidas también necesitan actualizar el paquete o desactivar las contraseñas.
Para saber si alguien ha aprovechado el fallo, Alpine aconseja buscar en /var/log/messages líneas de sshd con Accepted password en cuentas que no tienen contraseña, como alpine, root o usuarios que solo usan clave, y revisar el uso de doas, los usuarios y ficheros creados recientemente y los authorized_keys. Si no se puede descartar un acceso, la distribución pide tratar la máquina como comprometida.
Preguntas frecuentes
¿Qué versión de OpenSSH corrige CVE-2026-123158?
OpenSSH 10.6p2, publicada el 05/11/2026. En Alpine, las ramas estables reciben un paquete parcheado con su propia versión, como 10.3_p1-r2 en la 3.24 o 9.9_p2-r1 en la 3.21.
¿Afecta SSHHole a Debian, Ubuntu u otras distribuciones con glibc?
No. El fallo depende de que crypt() de musl devuelva un asterisco como error; glibc con libxcrypt devuelve *0 y los sistemas que usan PAM no llegan a esa comprobación.
¿Están en riesgo los contenedores Docker basados en Alpine?
Solo si ejecutan sshd dentro del contenedor con acceso por contraseña y se cumplen el resto de condiciones. En ese caso hay que reconstruir la imagen con el paquete corregido y volver a desplegarla.
¿Qué hago si no puedo actualizar todavía?
Desactivar el acceso por contraseña con PasswordAuthentication no y reiniciar sshd, después de comprobar que el acceso con clave funciona. Alpine indica que esta medida cierra el fallo por sí sola.
Fuentes:
- LinuxGratis: análisis de *sshole (CVE-2026-123158) en OpenSSH sobre Alpine
- Alpine Linux: Security advisory: openssh-server password authentication bypass
- OpenSSH: notas de la versión 10.6p2
- NVD: CVE-2026-123158
- CVE.org: registro CVE-2026-123158
- openssh-portable: commit de la corrección
- sshhole.com: explicación del investigador Özgün Kültekin
