OpenSSH ha publicado una corrección de emergencia, la versión 10.6p2, para un fallo que permite entrar por SSH en servidores Alpine Linux sin saber ninguna contraseña. Basta una contraseña inventada de más de 256 caracteres y una sola conexión. No hay ataques confirmados todavía, pero el responsable de OpenSSH pide desactivar el acceso por contraseña de inmediato.
Qué ha pasado
El 5 de noviembre de 2026, OpenSSH publicó la versión 10.6p2 con una corrección de seguridad crítica. El fallo afecta a los sistemas Linux construidos con la biblioteca C musl y con el servidor SSH configurado sin PAM. En la práctica, eso significa sobre todo Alpine Linux, base habitual de contenedores e imágenes en la nube.
Lo descubrió el investigador Özgün Kültekin, de Wakefield, y el equipo publicó la corrección al día siguiente. Damien Miller, del proyecto OpenSSH, dijo a quienes tengan sistemas afectados que desactiven la autenticación por contraseña o el SSH «INMEDIATAMENTE». A fecha de hoy no se ha asignado ningún identificador CVE y no se han publicado ataques que lo estén usando. Eso no es tranquilidad: el fallo es trivial de explotar una vez que se conoce.
Cómo funciona el fallo
Tres piezas que por separado son razonables y juntas abren la puerta. Primero, las cuentas sin contraseña se guardan con un asterisco: en Alpine, las cuentas que solo usan clave SSH —y la propia cuenta root, que viene así en la imagen base desde aproximadamente Alpine 3.16— tienen un * en el campo de la contraseña. Segundo, para comprobar una contraseña sin PAM, sshd necesita una sal; como el campo * es demasiado corto para contenerla, toma prestada la sal de otra cuenta con un hash real de tipo $5$ o $6$. Y tercero, con una contraseña de más de 256 bytes, la biblioteca musl devuelve * como error: ese * coincide con lo guardado en el campo de la cuenta sin contraseña, y sshd acepta el inicio de sesión.
El atacante solo necesita acceso de red al puerto SSH, el nombre de una cuenta sin contraseña y una contraseña de entre 257 y 1.024 bytes. Funciona a la primera y con una sola conexión. El límite de 256 bytes viene de un cambio de musl de 2012; el préstamo de la sal, de un cambio de OpenSSH de 2016 que corregía el CVE-2016-6210.
A quién afecta
Un servidor está expuesto solo si se cumplen las cuatro condiciones a la vez: corre openssh-server de Alpine, compilado sin PAM, o openssh-server-pam con UsePAM no; tiene PasswordAuthentication yes, que es el valor por defecto; tiene al menos una cuenta con el campo de contraseña *; y tiene al menos otra cuenta local con un hash $5$ o $6$. Basta una sola cuenta con contraseña para exponer a todas las que no la tienen.
El caso más peligroso son las imágenes oficiales de nube tiny-cloud de Alpine (versiones 3.18.11 a 3.24.3): traen el usuario alpine con campo * y doas sin contraseña. Son seguras al arrancar, pero en cuanto existe cualquier hash $6$ en la máquina —por ejemplo, cuando un administrador pone una contraseña de consola— un atacante puede entrar como alpine y escalar a root con doas. El fallo no se limita a Alpine: Kültekin señala que hay que revisar también OpenWrt, Buildroot y Yocto, otros sistemas basados en musl. En OpenWrt el servidor SSH por defecto es Dropbear, que no está afectado; el riesgo aparece solo si se instaló el servidor OpenSSH. No están afectados los contenedores sin sshd, los sistemas con PasswordAuthentication no, los que usan PAM con UsePAM yes, las cuentas bloqueadas con ! y las imágenes configuradas con cloud-init.
Qué hacer
1. Actualizar y reiniciar. En Alpine:
apk upgrade -U -a
rc-service sshd restartEl reinicio es imprescindible: actualizar el paquete no sustituye al demonio sshd que ya está en ejecución. Las versiones puntuales 3.21.10, 3.22.8, 3.23.8 y 3.24.4 ya incluyen el paquete corregido, y hay paquetes para todas las ramas hasta la 3.16. Quien compile OpenSSH por su cuenta debe pasar a la 10.6p2.
2. Si no se puede actualizar, desactivar la autenticación por contraseña. Antes hay que comprobar que el acceso por clave SSH funciona y mantener la sesión actual abierta hasta probar un inicio nuevo. Después, poner PasswordAuthentication no y reiniciar sshd; se verifica con sshd -T | grep -i passwordauthentication.
3. Buscar indicios de intrusión. En /var/log/messages, buscar líneas de sshd que digan Accepted password for seguidas de una cuenta que no tiene contraseña (alpine, root o cualquier usuario solo-clave). Revisar también el uso de doas, usuarios creados recientemente, archivos nuevos y claves autorizadas. La advertencia de Alpine es clara: «si no puedes descartar un inicio de sesión, trata la máquina como comprometida».
El ángulo Blue Team: qué vigilaría un SOC
Este fallo demuestra que el inventario importa más que el parche en sí. La corrección existe desde el 5 de noviembre, pero el riesgo real está en saber dónde corre sshd sobre Alpine sin PAM. Un SOC debería inventariar qué hosts exponen el puerto 22 con Alpine u otros sistemas musl y cruzar esa lista con la configuración de PasswordAuthentication y UsePAM; lo que no está inventariado no se parchea.
La regla de detección es barata y de alta fidelidad: un Accepted password para una cuenta que por diseño no tiene contraseña es una señal inequívoca de explotación, no un falso positivo. Tras el acceso inicial, el atacante necesita doas o sudo para llegar a root, así que los registros de doas, la creación de usuarios y los cambios en authorized_keys son la segunda línea de detección. Y no hay que fiarse del parche sin reinicio: un host con el paquete actualizado pero con el sshd antiguo en ejecución sigue siendo vulnerable.
El fallo llevaba latente desde 2016, fruto de dos decisiones razonables por separado. Y OpenSSH avisa de que los agentes de IA ya redescubren este tipo de fallos en cuestión de horas, por eso publica correcciones con más frecuencia y con embargos más cortos. La ventana entre la publicación y la explotación se está cerrando: parchear el mismo día ya no es una exageración, es el estándar.
Fuentes
- The Hacker News — «OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux»: https://thehackernews.com/2026/11/openssh-issues-emergency-fix-for-flaw.html
- Alpine Linux — «Security advisory: openssh-server password authentication bypass» (2026-11-05): https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
- OpenSSH — Notas de la versión 10.6p2 (2026-11-05): https://www.openssh.org/releasenotes.html#10.6p2