Si usas sshd en Alpine Linux, actualiza openssh y reinicia sshd: en los sistemas afectados, cualquiera que llegue al puerto SSH puede entrar sin la contraseña, en un solo intento. Alpine publicó paquetes corregidos para edge y nueve ramas estables el 5 de noviembre de 2026, el mismo día en que OpenSSH lanzó la versión 10.6p2.
Al momento de publicar esta nota no se había asignado ningún identificador CVE, y ni Alpine ni OpenSSH habían indicado una versión corregida de musl. Los escáneres que se guían por CVE pueden no detectarlo todavía.
¿Estoy afectado por la vulnerabilidad de OpenSSH en Alpine?
Solo estás afectado si se cumplen las cuatro condiciones a la vez:
sshdviene del paqueteopenssh-server(compilado sin PAM), o deopenssh-server-pamconUsePAM no.PasswordAuthenticationestá activado, que es el valor por defecto de OpenSSH.- Al menos una cuenta tiene
*en el campo de contraseña. Es más común de lo que parece: Alpine distribuyerootcomoroot:*desde aproximadamente la 3.16, y también cuentan los usuarios que solo entran con clave, los usuarios de servicios de directorio sin entrada en shadow y el usuarioalpinede las imágenes tiny-cloud. - Al menos otra cuenta tiene un hash de contraseña
$5$o$6$.
Las versiones afectadas son edge y de la 3.16 a la 3.24.
| Situación | ¿Afectado? |
|---|---|
Contenedor que no ejecuta sshd |
No |
PasswordAuthentication no |
No |
openssh-server-pam con UsePAM yes |
No |
Cuentas bloqueadas (! en el campo de contraseña) |
No |
Ningún hash con formato $ en todo el sistema |
No |
Imágenes con cloud-init que fijan PasswordAuthentication no |
No |
Para revisar las dos últimas condiciones, abre /etc/shadow: el segundo campo de cada línea es la contraseña. * significa sin contraseña, ! significa cuenta bloqueada (no afectada) y un valor que empieza por $5$ o $6$ es un hash. Como root:* viene por defecto, en la práctica la pregunta es si algún usuario del servidor tiene una contraseña real configurada.
¿Cómo se arregla el bypass de contraseña de OpenSSH en Alpine?
Con dos comandos:
apk upgrade -U -a
rc-service sshd restart
El reinicio no es opcional. Actualizar el paquete no reemplaza el daemon que ya está en ejecución.
Estas son las versiones corregidas de openssh por rama:
| Rama | Versión corregida de openssh |
|---|---|
| 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 |
La 3.21 dejó de tener soporte el 1 de noviembre de 2026, pero Alpine igualmente publicó paquetes corregidos para todas las versiones hasta la 3.16.
¿Afecta a las imágenes cloud de Alpine Linux?
Sí, y son el caso más riesgoso. Las imágenes tiny-cloud oficiales de la 3.18.11 a la 3.24.3 traen un usuario alpine con contraseña * y doas sin contraseña. Son seguras en el primer arranque, pero en cuanto existe cualquier hash $6$ en la instancia, el bypass funciona, y el doas sin contraseña convierte ese acceso en root.
Las imágenes generadas a partir de las versiones corregidas (3.21.10, 3.22.8, 3.23.8 y 3.24.4) y posteriores ya incluyen la corrección. Las instancias lanzadas desde imágenes anteriores necesitan la actualización o la mitigación de la siguiente sección, una por una.
¿Y si no puedo actualizar? Cómo desactivar la autenticación por contraseña en SSH
Desactiva la autenticación por contraseña y deja SSH solo con clave. Antes de empezar, confirma que el acceso con clave funciona y mantén abierta tu sesión actual, para que un error no te deje fuera.
Este es el bloque del aviso de Alpine:
mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
-e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
/etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication
El último comando debería mostrar passwordauthentication no.
El archivo drop-in solo tiene efecto desde la 3.19, que es cuando la configuración por defecto de Alpine empieza a leer /etc/ssh/sshd_config.d/. Por eso el bloque también edita directamente /etc/ssh/sshd_config: inserta el ajuste al principio y cambia a no cualquier línea PasswordAuthentication yes existente, incluidas las que están dentro de bloques Match. El original queda guardado como sshd_config.bak.
¿Cómo sé si alguien ya entró?
Busca en /var/log/messages líneas de sshd con Accepted password for en cuentas que no tienen contraseña: alpine, root o tus usuarios que solo entran con clave. Un acceso con contraseña a una cuenta sin contraseña es la firma de este ataque.
En las máquinas expuestas, revisa también el uso de doas, los usuarios y archivos creados recientemente y todos los authorized_keys. Si no puedes descartar un acceso, trata la máquina como comprometida.
¿Qué es Alpine Linux y qué tiene que ver musl?
Alpine Linux es una distribución ligera muy usada como imagen base de contenedores y en instancias cloud, que gestiona sus paquetes con apk. A diferencia de la mayoría de las distribuciones, usa musl como biblioteca C en lugar de glibc, y eso es lo que importa aquí: OpenSSH describe los sistemas afectados como algunos Linux compilados sin soporte de PAM, en particular los que usan musl libc. Por eso este fallo, que en inglés circula como “Alpine openssh password authentication bypass”, es un problema de Alpine y no de cualquier servidor con OpenSSH.
¿Por qué una contraseña larga entra sin la real?
El fallo está en musl, no en la lógica propia de sshd. Sin PAM, sshd verifica una contraseña pasando el intento por crypt() y comparando el resultado con el campo guardado. Para una cuenta cuyo campo es demasiado corto para contener un salt, como *, sshd toma prestado el salt de otra cuenta, y por eso tiene que existir un hash $5$ o $6$ en algún lugar del sistema.
El crypt() de musl devuelve * como indicador de error cuando la clave supera los 256 bytes. * es también exactamente lo que se guarda para una cuenta sin contraseña, así que la comparación coincide y el acceso se concede. Al atacante le basta con enviar una contraseña de entre 257 y 1024 bytes.
Los mantenedores de OpenSSH consideran que la causa de fondo está fuera de sshd, pero que se puede evitar desde dentro, y eso es lo que hace la 10.6p2. Los paquetes de las ramas estables de Alpine incluyen un parche con el mismo efecto. El fallo lo reportó Özgün Kültekin, de Wakefield. Las notas de la 10.6p2 también indican que OpenSSH publicará versiones con más frecuencia por ahora, porque los reportes asistidos por IA están sacando a la luz fallos que otros encuentran de forma independiente.
¿Y tú? ¿Qué es lo primero que revisas cuando sale un aviso de seguridad sin CVE?
- Solo con clave (
PasswordAuthentication no) - Todavía con contraseña
- No uso sshd en Alpine
- Prefiero otra opción (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.
Relacionado: axios Comprometido en npm: Lo Que Todo Dev JS Necesita Verificar Ahora