OpenSSH: la autenticación por contraseña puede eludirse en sistemas Linux con musl sin PAM, advierte el CERT-FR

Vigilancia cibernética de Top-Secured: análisis independiente basado en las fuentes citadas más abajo. Top-Secured no está afiliado a las empresas mencionadas y nunca le pedirá sus datos bancarios ni sus contraseñas.

OpenSSH publicó el 5 de noviembre de 2026 la versión 10.6p2 para cerrar una elusión de la autenticación por contraseña en sshd que afecta a los sistemas Linux basados en la biblioteca C musl sin PAM, como muchos servidores y contenedores Alpine. El CERT-FR emitió una alerta ese mismo día y considera trivial la explotación cuando se cumplen las condiciones.

Qué ha pasado

El 5 de noviembre de 2026, el proyecto OpenSSH publicó la versión portable OpenSSH 10.6p2, que corrige una elusión de la autenticación por contraseña explotable a través de sshd. Según las notas de la versión, la causa de fondo está fuera de OpenSSH, pero sshd se ha modificado para evitarla. Ese mismo día, el CERT-FR publicó la alerta CERTFR-2026-ALE-015: afecta a todas las versiones anteriores a la 10.6p2 y la explotación se califica de trivial si se dan las condiciones. No se indica ningún identificador CVE y ninguna de las dos fuentes informa de ataques hasta ahora.

A quién afecta

Solo están afectados los sistemas Linux que usan la biblioteca C musl y ejecutan sshd sin PAM. Según el investigador que descubrió el fallo, la función crypt() de musl falla con contraseñas de más de 256 bytes y devuelve *, justo el valor que marca en /etc/shadow una cuenta sin contraseña utilizable. Un atacante puede así entrar en esa cuenta (usuarios que solo usan clave, o root en las versiones recientes de Alpine, según el investigador) con una contraseña desmesurada, siempre que la autenticación por contraseña esté activa. El investigador cita Alpine, OpenWrt, Buildroot, Yocto y las imágenes Docker basadas en ellos. Las distribuciones basadas en glibc, las configuraciones con PAM y Dropbear no están afectadas, según el mismo análisis.

Qué hacer ahora

1. Localice los sistemas expuestos: ldd --version muestra musl en las plataformas afectadas; revise sshd -T | grep -Ei 'usepam|passwordauthentication'.
2. Actualice: apk upgrade openssh y compruebe que ssh -V indica 10.6p2. Reconstruya y vuelva a desplegar las imágenes de contenedores que incluyan sshd.
3. Si la actualización debe esperar, desactive el acceso por contraseña con PasswordAuthentication no en un archivo de /etc/ssh/sshd_config.d/ y reinicie sshd (rc-service sshd restart). En su defecto, el CERT-FR recomienda detener el servicio SSH.
4. Busque rastros: liste las cuentas cuyo campo de contraseña es * (grep -E '^[^:]+:\*:' /etc/shadow | cut -d: -f1) y busque líneas Accepted password for sobre ellas en /var/log/messages, como sugiere el CERT-FR.

Nuestra opinión

Las imágenes ligeras están en todas partes, en contenedores y equipos, y heredan los valores por defecto de su sistema base, incluido un SSH sin PAM. La autenticación solo por clave debe imponerse de forma explícita en la configuración, no darse por supuesta: con PasswordAuthentication no, este fallo no habría tenido efecto.

Fuentes

• CERT-FR — CERTFR-2026-ALE-015 : Vulnérabilité dans OpenSSH
• OpenSSH — Release notes for OpenSSH 10.6p2
• sshhole — OpenSSH password bypass on musl libc (researcher write-up)

Cómo elegimos, verificamos y redactamos nuestros análisis →