Si tienes un Alpine Linux con sshd accesible desde fuera, deja esto para luego y actualiza primero: apk upgrade -U -a y rc-service sshd restart. Lo segundo no es opcional, porque actualizar el paquete no sustituye al demonio que ya está en marcha.
OpenSSH publicó el 5 de noviembre de 2026 la versión 10.6p2 con un arreglo urgente, y Alpine sacó el mismo día su aviso y paquetes corregidos para todas sus ramas desde la 3.16. El fallo se ha bautizado como *sshole, tiene el identificador CVE-2026-123158 y permite iniciar sesión sin conocer la contraseña en ciertas cuentas. Lo descubrió Özgün Kültekin, de Wakefield.
Qué falla
No hay una sola línea culpable, sino tres decisiones razonables que llevan años encajando mal:
- La biblioteca musl limita a 256 bytes la clave que aceptan sus funciones SHA-crypt y, cuando algo falla,
crypt()devuelve la cadena*en lugar de un puntero nulo. Viene de 2012. - En Unix, un
*en el campo de contraseña significa desde hace décadas «esta cuenta no entra con contraseña». Se asumía que nunca podría coincidir con un hash real. - Desde 2016, para no delatar qué usuarios existen (CVE-2016-6210),
sshdcalcula un hash también en esos casos usando la sal de otra cuenta del sistema.
Juntas, esas piezas hacen que en un sistema con musl y sin PAM el resultado de error de crypt() pueda compararse con el * almacenado y darse por bueno. De ahí salen los diez años del titular: la pieza de OpenSSH es de 2016. El aviso de Alpine sitúa la longitud problemática entre 257 y 1024 bytes, y el registro del CVE habla de 256 a 1024.
OpenSSH considera que la causa raíz está fuera de su código, pero lo ha resuelto en su lado: el parche exige que el hash guardado tenga una longitud mínima antes de aceptar la comparación, de modo que un * ya no puede coincidir.
A quién afecta de verdad
Alpine considera vulnerable una máquina solo si se cumple todo esto a la vez:
- Usa el paquete
openssh-server, compilado sin PAM, oopenssh-server-pamconUsePAM no. - Tiene
PasswordAuthentication yes, que es el valor por defecto. - Hay una cuenta con
*en el campo de contraseña: usuarios solo con clave, usuarios de directorio vía musl-nscd o el usuarioalpinede las imágenes tiny-cloud. - Otra cuenta local tiene un hash
$5$o$6$.
Fuera de Alpine, las fuentes mencionan otros sistemas con musl como OpenWrt, Buildroot o Yocto, siempre según cómo estén compilados y configurados. Si mantienes un firmware propio, compruébalo en lugar de suponer.
No están afectados los sistemas con glibc (Debian, Ubuntu, Fedora y compañía), los que usan PAM, los que tienen PasswordAuthentication no, los contenedores que no ejecutan sshd, las cuentas bloqueadas con ! y las imágenes cloud configuradas con cloud-init, que desactiva las contraseñas.
¿De verdad da root?
Eso se ha repetido mucho en redes y conviene matizarlo. En Alpine, root tiene * desde la 3.16, pero el PermitRootLogin prohibit-password por defecto lo protege salvo que hayas puesto PermitRootLogin yes.
El problema real está en las cuentas que pueden llegar a root. Las imágenes tiny-cloud oficiales de 3.18.11 a 3.24.3 traen un usuario alpine con * y doas sin contraseña. Son seguras en el primer arranque, pero dejan de serlo en cuanto aparece cualquier hash $6$ en la máquina, por ejemplo al poner una contraseña de consola.
Tampoco es cierto que baste con cualquier Alpine: una instalación sin ningún hash $5$ o $6$ queda fuera, y el vector CVSS 3.1 lo puntúa con 8,1 (alto) y complejidad alta. Dicho esto, Alpine advierte de que el ataque no necesita reintentos y que basta con alcanzar el puerto, así que no conviene relajarse. CISA registra que ya hay pruebas de concepto públicas.
Versiones corregidas
| Rama de Alpine | Paquete openssh corregido |
|---|---|
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
Alpine 3.21.10, 3.22.8, 3.23.8 y 3.24.4 ya incluyen el paquete corregido. Si compilas OpenSSH por tu cuenta, necesitas 10.6p2 o posterior.
Qué hacer ahora
Actualiza y reinicia el servicio:
apk upgrade -U -a
rc-service sshd restartSi no puedes actualizar todavía, desactiva las contraseñas. Antes, comprueba que tu clave funciona y deja una sesión abierta hasta probar un acceso nuevo:
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 passwordauthenticationEse directorio solo se lee por defecto desde Alpine 3.19. En versiones anteriores cambia la directiva en /etc/ssh/sshd_config, y revisa también los bloques Match. La última orden debe devolver passwordauthentication no.
Cómo saber si te han entrado
Las cuentas sin contraseña no deberían aparecer jamás con un acceso por contraseña, así que empieza por ahí:
grep 'Accepted password' /var/log/messagesSi salen cuentas solo con clave, o alpine, revisa el uso de doas, los usuarios creados, los ficheros recientes y los authorized_keys. Si no puedes descartar el acceso, Alpine recomienda tratar la máquina como comprometida, y la vía segura es reinstalarla y rotar sus credenciales.
Cómo lo hemos probado
Hemos comprobado el comportamiento de la biblioteca, no el ataque: no hemos lanzado ningún intento de acceso contra sshd. Con un pequeño programa en C que llama a crypt() con una sal $6$, en alpine:3.24 (musl 1.2.6-r3) una clave de 256 bytes da un hash normal y una de 257 devuelve *. En debian:13 (glibc), la de 257 bytes sigue dando un hash normal y la de 1024 devuelve *0, un error que no coincide con el * de la cuenta. Eso encaja con lo que dicen los avisos sobre glibc.
Lo que dice este artículo sobre versiones y condiciones sale del aviso de Alpine, de las notas de OpenSSH y del código del parche.
Más sobre la distribución en la ficha de Alpine Linux, y si quieres repasar tu servidor, en nuestra guía de claves SSH y endurecimiento de sshd.