El 5 de noviembre de 2026 el proyecto OpenSSH publicó la versión portable 10.6p2, una solución provisional para un bypass de contraseña en OpenSSH en sistemas Linux que usan musl libc con PAM desactivado. CERT-FR publicó ese mismo día el aviso CERTFR-2026-ALE-015. Özgün Kültekin, de la empresa de seguridad en IA Wakefield, comunicó el fallo, y el proyecto solo tuvo noticia de él un día antes de la publicación.

Un atacante envía una contraseña de entre 257 y 1.024 bytes y entra en una cuenta que no tiene contraseña. Las instalaciones de OpenSSH en Alpine Linux son el caso evidente, porque Alpine compila su paquete openssh-server sin PAM por defecto. La mayor parte de la cobertura se queda en «actualiza a 10.6p2», que es el último de tres pasos. La secuencia es: inventario, desactivar las contraseñas y, por último, parchear.

El fallo es antiguo, no nuevo. Se remonta a 2016, y el investigador afirma que OpenSSH 7.5p1 sobre musl 1.1.16 (2017) ya era explotable. Lo nuevo es la corrección y los avisos; existen una prueba de concepto pública y un script de verificación. En las fuentes que hemos leído no encontramos explotación confirmada en entornos reales, lo que dice poco sobre la semana que viene.

Cómo se combinan el fallo de crypt() de musl y la búsqueda de salt de sshd

Desde 2012, el crypt() de musl devuelve el literal * cuando falla, y su crypt SHA-512 rechaza las contraseñas de más de 256 bytes. Desde la mitigación de tiempos de 2016 para CVE-2016-6210, un sshd sin PAM toma un salt de otra cuenta real con pick_salt() y llama a crypt(password, salt) incluso para cuentas que no pueden iniciar sesión con contraseña.

Si envías una contraseña dentro del rango útil, crypt() falla y devuelve *. Eso coincide con el * almacenado en /etc/shadow para una cuenta sin contraseña, así que sshd detecta una coincidencia. El agujero nace de la suma de ambos comportamientos; ninguno de los dos es un fallo por sí solo.

CERT-FR formula la longitud como «estrictamente más de 256 y menos de 1024», mientras que otras fuentes hablan de 257 a 1.024 bytes. La diferencia en el límite superior no cambia la auditoría que sigue. Los avisos también discrepan sobre si el atacante envía una contraseña larga o dos; de nuevo, la auditoría es la misma en ambos casos.

Las condiciones señaladas son: sin PAM, inicios de sesión con contraseña habilitados y una cuenta cuyo campo en shadow sea exactamente *. Fuentes secundarias añaden que debe existir otra cuenta con un hash $5$ o $6$. No hemos podido confirmar qué ocurre si no existe, así que no tomes su ausencia como protección.

No están afectados: los sistemas con glibc, UsePAM yes, Dropbear, OpenBSD y los sistemas que no son Linux. Un paquete de Alpine compilado con PAM sigue expuesto si sshd se ejecuta con UsePAM no.

Por qué las cuentas solo con clave son el objetivo

Las cuentas con * en el campo de contraseña suelen ser cuentas que solo admiten clave. El investigador menciona root, los usuarios solo con clave y los usuarios LDAP, además del usuario alpine que traen por defecto las imágenes cloud oficiales de Alpine de la 3.18.11 a la 3.24.3, que no tiene contraseña. Un análisis afirma que ese usuario tiene doas sin contraseña, lo que convierte el bypass, en la práctica, en acceso root.

Una cuenta solo admite clave si sshd rechaza las contraseñas. Mientras PasswordAuthentication no esté en no, «sin contraseña definida» significa «cualquier contraseña que haga fallar a crypt()».

El valor por defecto de PasswordAuthentication en OpenSSH es yes. Si nadie lo ha puesto en no, nada impide un intento de acceso con contraseña contra esas cuentas *.

Paso 1: inventaría los hosts y después las imágenes

Empieza por todas las máquinas que ejecutan sshd, después acota a las que usan musl y, por último, a las que permiten inicios de sesión con contraseña. En cada host, como root:

ldd --version 2>&1 | head -n1
sshd -T | grep -i -E '^(usepam|passwordauthentication)'
awk -F : '$2 == "*" {print $1}' /etc/shadow

Las líneas de ldd y sshd -T son herramientas estándar que no hemos contrastado con el aviso; la de awk procede de CERT-FR. La primera muestra qué libc usa el host; en musl, aparece musl. La segunda muestra la configuración efectiva de sshd. La tercera enumera las cuentas que un atacante elegiría como objetivo. Ninguna demuestra si tu sshd se compiló con PAM: para esa comprobación, usa el script de verificación del investigador y el aviso de Alpine, y no deduzcas «sin PAM» de que falte una línea en la salida.

Después comprueba si alguien ya ha aprovechado el agujero. La comprobación de compromiso de CERT-FR combina la lista de cuentas con el log:

awk -F : '$2 == "*" {print $1}' /etc/shadow | xargs -r -I{} grep "Accepted password for {}" /var/log/messages

La ruta /var/log/messages es la que usa syslog por defecto en Alpine. En otras configuraciones, apúntala a tu archivo de logs o consulta journald. Un inicio de sesión con contraseña aceptado en una cuenta solo con clave es un hallazgo, concluyas lo que concluyas.

Para auditar imágenes de contenedor, comprueba primero si la imagen contiene un servidor SSH. Puedes hacerlo sin tratar la imagen como un host: ejecútala una vez y lista los paquetes instalados, por ejemplo docker run --rm --entrypoint apk your-image info -v | grep openssh (herramienta estándar, no contrastada con el aviso). Después compara las versiones con los paquetes corregidos: edge 10.6_p2-r0, 3.24 10.3_p1-r2, 3.23 10.2_p1-r1, 3.22 10.0_p1-r11 y 3.21 9.9_p2-r1. Las ramas anteriores, hasta la 3.16, incluyen backports en lugar del número de versión 10.6p2, y no hemos obtenido esas versiones, así que tómalas del aviso de Alpine. Ejecuta el script de verificación del investigador para la cuestión de PAM.

No te quedes en las imágenes que has construido tú. Los dispositivos con Buildroot, Yocto y OpenWrt pueden usar musl, y el investigador menciona también postmarketOS, Void-musl y Chimera. Que cada uno esté expuesto depende de cómo se compiló su OpenSSH.

Dónde encajan tus VPS, VDS y servidores bare metal

En los VPS y VDS no gestionados, el sistema operativo invitado y sshd los revisas tú, así que los comandos anteriores te corresponde ejecutarlos a ti. Lo mismo vale para los servidores bare metal, salvo que hayas contratado la opción gestionada, en la que nos encargamos de parchear el sistema operativo; pídenos que confirmemos la versión de sshd en lugar de darla por supuesta. Los mismos comandos sirven allí donde ejecutes Linux con OpenSSH.

El acceso de red es una segunda capa. Si tus administradores llegan a los hosts a través de Private Link, puedes restringir quién puede alcanzar sshd; eso reduce quién puede llegar a sshd, pero no corrige sshd.

Paso 2: endurecimiento de SSH solo con clave en sshd_config

La mitigación oficial de CERT-FR es desactivar la autenticación por contraseña o, si no puedes parchear, el servicio. Damien Miller, de OpenSSH, dice lo mismo: establece PasswordAuthentication no y reinicia sshd. Es la mitigación oficial y no requiere ningún paquete nuevo. Solo surte efecto cuando se reinicia sshd o se recrea el contenedor a partir de una imagen que incluya el ajuste.

  1. Confirma que cada administrador tiene una clave que funciona y una segunda sesión abierta.
  2. Establece PasswordAuthentication no en /etc/ssh/sshd_config o en un drop-in que este incluya, y reinicia sshd.
  3. Vuelve a ejecutar sshd -T | grep -i passwordauthentication y confirma que devuelve no. Lee también a mano tus bloques Match.
  4. Incorpora el ajuste a la imagen o a la gestión de configuración para que la próxima reconstrucción no lo revierta.

Paso 3: parchear y qué cambia 10.6p2

10.6p2 hace que sshd rechace una coincidencia cuando el campo de contraseña almacenado tiene menos de cuatro caracteres. El propio OpenSSH lo califica de solución provisional y afirma que la causa raíz está fuera de sshd. El responsable de musl, Rich Felker, sostiene que no es una vulnerabilidad de musl libc.

Ese argumento decide tu plan: la corrección es una salvaguarda en un demonio, no un cambio en la biblioteca. Actualiza sshd una vez desactivadas las contraseñas e incorpora a tu pipeline de imágenes la comprobación de cuentas * con inicio de sesión por contraseña, para que una imagen reconstruida no pueda traer de vuelta la exposición sin que nadie se dé cuenta.

Fuentes