OpenSSH: omisión de la autenticación con musl y sin PAM
OpenSSH anterior a 10.6p2: en Linux con musl y sin PAM se entra con dos contraseñas. Condiciones, revisión de registros y mitigaciones según el CERT-FR.

El 5 de noviembre de 2026 el proyecto OpenSSH publicó la versión 10.6p2, con un boletín de seguridad sobre una vulnerabilidad que permite eludir la autenticación de un servicio SSH. Ese mismo día el CERT-FR (ANSSI) difundió dos documentos: el aviso CERTFR-2026-AVI-1468 y el boletín de alerta CERTFR-2026-ALE-015. Ambos indican como afectadas las versiones de OpenSSH anteriores a la 10.6p2 y clasifican el riesgo como elusión de la política de seguridad.
Las dos fuentes de este artículo son del CERT-FR. El aviso solo recoge las versiones afectadas y la solución; las condiciones de explotación, los indicadores y la mitigación proceden únicamente del boletín de alerta. Ninguno de los dos documentos da un identificador CVE ni dice si la vulnerabilidad ya se está explotando.
Condiciones para la explotación
Según el boletín de alerta del CERT-FR, la vulnerabilidad afecta a los sistemas Linux que cumplen a la vez estas condiciones:
- usan la biblioteca C estándar musl;
- OpenSSH está compilado sin soporte PAM, o PAM está desactivado.
En esta configuración un atacante puede conectarse proporcionando dos contraseñas, la segunda con una longitud estrictamente superior a 256 caracteres e inferior a 1.024. El CERT-FR escribe que, cuando se dan las condiciones, la explotación es trivial, e invita a comprobar si los propios sistemas están en una configuración vulnerable.
El boletín no describe el fallo en el código ni indica otras configuraciones afectadas. Para los detalles remite al boletín de OpenSSH de la versión 10.6p2 y a la página del investigador que descubrió el fallo, llamada «sshhole».
Indicadores de compromiso
El investigador, según el CERT-FR, recomienda comprobar la legitimidad de los accesos de cada cuenta del sistema que en /etc/shadow tiene un asterisco en lugar de la contraseña (:*:, contraseña desactivada). El boletín propone este comando, que debe ejecutarse como root:
awk -F : '$2 == "*" {print $1}' /etc/shadow | xargs -r -I{} grep "Accepted password for {}" /var/log/messages
El comando lista las cuentas con la contraseña desactivada y busca en el registro /var/log/messages los accesos con contraseña realizados con éxito a su nombre. Cada resultado debe verificarse: es un acceso con contraseña aceptado en una cuenta cuya contraseña está desactivada. Si en tus sistemas los mensajes de sshd van a otro registro, adapta la ruta del comando.
Impacto para las empresas europeas e italianas
OpenSSH es la herramienta estándar para la administración remota de sistemas Linux, y el servicio SSH suele ser accesible desde Internet. Sin embargo, la vulnerabilidad no afecta a todas las instalaciones: según el CERT-FR hacen falta a la vez la biblioteca musl y la ausencia o desactivación de PAM. El primer paso es, por tanto, el inventario: qué sistemas tienen OpenSSH anterior a la 10.6p2, cuáles usan musl, cómo está configurado PAM y si se acepta la autenticación con contraseña.
Un servicio SSH cuya autenticación se puede eludir es un acceso directo al sistema: debe tratarse con prioridad, empezando por los servidores accesibles desde el exterior. Para las entidades sujetas a NIS2, el caso entra en la gestión de vulnerabilidades y en el control de los accesos administrativos que exigen las medidas de seguridad; conviene documentar el inventario, las comprobaciones de los registros y las decisiones tomadas para cada sistema.
Qué hacer ya
- Actualiza OpenSSH a la versión 10.6p2, o al paquete de tu distribución que incluya la corrección, siguiendo el boletín de OpenSSH como indica el CERT-FR.
- Comprueba la configuración de los sistemas que no puedas actualizar enseguida: biblioteca C en uso (musl u otra), OpenSSH compilado con o sin PAM y valor efectivo de la directiva
UsePAM, que puedes leer consshd -T. - Si no puedes actualizar, el CERT-FR recomienda desactivar la autenticación con contraseña (en
sshd_config,PasswordAuthentication no, y después recargar el servicio) o, en su defecto, desactivar el servicio SSH. Antes de quitar las contraseñas, asegúrate de que los administradores pueden entrar con claves, para no quedarte fuera. - Busca rastros con el comando del boletín y revisa, en general, los accesos con contraseña realizados con éxito desde direcciones o en horarios inusuales, sobre todo en las cuentas del sistema.
Cómo ayuda ARXDOME
ARX Sentry recoge de los servidores Linux el inventario del software y los registros de acceso: ayuda a encontrar las máquinas con OpenSSH y a ver su versión, y muestra en las páginas de identidades los accesos con éxito, los privilegiados y los nocturnos. ARX Expose y ARX Scout indican qué direcciones públicas de la empresa exponen un servicio SSH, es decir, por dónde empezar con las actualizaciones y las comprobaciones.
Última actualización:


