Una contraseña de entre 257 y 1.024 bytes puede abrir por SSH una cuenta que no debería aceptar contraseñas. El fallo, bautizado sshole y registrado como CVE-2026-123158, afecta a ciertas configuraciones de OpenSSH en Linux que usan la biblioteca musl sin PAM. OpenSSH y Alpine Linux publicaron correcciones el 5 de noviembre.
No basta con tener Linux o Alpine para quedar expuesto: deben coincidir varios requisitos, entre ellos que el servidor acepte autenticación por contraseña y que haya cuentas con determinados campos y hashes. Pero una conexión puede ser suficiente para explotarlo. Previdian informó de ocho intentos desde una misma dirección IP y confirmó que uno obtuvo acceso como administrador en un servidor señuelo.
Una comparación de cadenas que termina en acceso
SSH permite administrar equipos a través de la red; OpenSSH es una implementación habitual del protocolo y sshd es su servidor. En Linux, /etc/shadow contiene los datos que se usan para verificar las contraseñas. En algunas cuentas configuradas para autenticarse solo con claves, el campo de contraseña aparece como un asterisco: *. Esa marca debe impedir el acceso mediante una contraseña ordinaria, no autorizarlo.
El fallo surge cuando sshd intenta comprobar una contraseña para una cuenta cuyo campo no contiene un hash utilizable. En las compilaciones sin PAM, OpenSSH usa la función crypt() de la biblioteca del sistema para procesar el intento y compararlo con el valor almacenado. Si el campo de la cuenta no tiene una sal que permita hacer esa comprobación, el servidor toma prestada la sal de otra cuenta.
En musl, crypt() devuelve * como indicador de error si la contraseña supera los 256 bytes. Ese resultado coincide con el carácter guardado en las cuentas sin contraseña. La comparación acaba considerando iguales dos valores que no representan una contraseña válida, y la autenticación se acepta. La ventana explotable descrita por Alpine y OpenSSH va de 257 a 1.024 bytes.
Alpine resume el requisito práctico así: el atacante necesita conocer el nombre de una cuenta con * en el campo de contraseña y que el equipo tenga al menos otra cuenta local con un hash que empiece por $5$ o $6$, correspondientes a SHA-256 y SHA-512. Basta con una cuenta con contraseña para que las cuentas sin ella puedan quedar expuestas, siempre que también se cumplan las demás condiciones.
“An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries.”
— Equipo de Alpine Linux
Alpine concentra los requisitos, pero no es el único sistema a revisar
El caso confirmado por Alpine comprende equipos que ejecutan su paquete openssh-server, compilado sin PAM, o openssh-server-pam con UsePAM no. La autenticación por contraseña debe estar habilitada; Alpine indica que OpenSSH la activa por defecto salvo que el administrador cambie la configuración. También debe existir una cuenta cuyo campo sea * y otra cuenta local con un hash $5$ o $6$.
Entre las cuentas que pueden tener el asterisco están root, usuarios creados para autenticarse únicamente con claves y cuentas procedentes de servicios de directorio mediante musl-nscd, como nslcd, winbind o sssd. En Alpine, la cuenta root viene como root:* en la imagen base desde aproximadamente la versión 3.16. Sin embargo, la configuración predeterminada PermitRootLogin prohibit-password la protege del acceso directo por contraseña. Esa barrera no resuelve el riesgo si otra cuenta que sí puede iniciar sesión obtiene privilegios de root, por ejemplo mediante doas.
Alpine considera afectadas todas las versiones que comprobó: de la 3.21 a la 3.24 y edge, además de las ramas antiguas 3.16 a 3.20, que ya no reciben actualizaciones periódicas. La vulnerabilidad no se limita necesariamente a esa distribución: otras compilaciones de OpenSSH sobre musl y sin PAM pueden reunir las mismas condiciones. Help Net Security cita OpenWrt, Buildroot y Yocto entre los sistemas que conviene revisar.
No están afectados, según el aviso de Alpine, los equipos con PasswordAuthentication no, los que usan PAM con UsePAM yes, los que no tienen hashes de contraseña con formato $, ni las cuentas bloqueadas cuyo campo comienza por !. Tampoco los contenedores Docker u otros contenedores que no ejecutan sshd, ni las imágenes cloud configuradas mediante cloud-init, que establecen PasswordAuthentication no.
Red Hat declaró que sus productos no están afectados: sus compilaciones de OpenSSH enlazan con glibc y usan PAM por defecto. Help Net Security también señala como fuera del escenario a Debian, Ubuntu y Fedora, que emplean glibc, así como a configuraciones que pasan por PAM, Dropbear y OpenBSD. La condición decisiva no es simplemente la distribución, sino la combinación de biblioteca, autenticación y cuentas.
Las imágenes tiny-cloud pueden pasar de seguras a vulnerables
Alpine identificó un riesgo específico en sus imágenes oficiales tiny-cloud, distribuidas como artefactos qcow2, VHD y AMI. Las imágenes de las versiones 3.18.11 a 3.24.3 incluyen un usuario alpine con campo de contraseña * y acceso a doas sin contraseña. Son seguras en el primer arranque, pero pueden volverse explotables en cuanto aparece un hash $6$ en la máquina.
Eso puede ocurrir, por ejemplo, si un administrador configura una contraseña desde la consola o si los datos de usuario añaden una cuenta con hashed_passwd. Si el atacante entra como alpine, puede utilizar doas para convertirse en root. Las imágenes construidas con Alpine 3.21.10, 3.22.8, 3.23.8, 3.24.4 y posteriores ya incluyen el paquete corregido; las imágenes de versiones puntuales anteriores requieren actualizar OpenSSH o desactivar la autenticación por contraseña en cada instancia que siga funcionando.
Alpine precisa que los usuarios de imágenes cloud configuradas por cloud-init quedan fuera del escenario descrito porque esa herramienta escribe PasswordAuthentication no. La diferencia entre una imagen recién iniciada y una máquina modificada después es importante: añadir una contraseña o una cuenta puede satisfacer una de las condiciones que antes faltaban.
Un fallo nacido de decisiones separadas
El investigador Özgün Kültekin, de Wakefield, comunicó el problema. La explicación técnica enlaza cambios introducidos en distintos momentos. En 2012, musl limitó la longitud de las contraseñas procesadas para evitar ataques de denegación de servicio; ante una entrada demasiado larga, crypt() devuelve el asterisco de error. En 2016, OpenSSH cambió la comprobación de cuentas sin un hash utilizable para dificultar que un atacante dedujera qué nombres de usuario existían midiendo los tiempos de respuesta.
Alpine también ajustó en 2022 la configuración de su cuenta de administrador para permitir el acceso mediante claves SSH. Cada cambio atendía un problema o una necesidad distintos. La interacción entre el tratamiento de errores de musl y el mecanismo de comprobación de OpenSSH hizo que el símbolo usado para señalar un fallo coincidiera con el campo de las cuentas sin contraseña.
Help Net Security añade que Kültekin probó distintas compilaciones de sshd y realizó unas 17.600 pruebas de inicio de sesión inusuales. Según ese medio, solo la compilación con musl y sin PAM permitió accesos que debían rechazarse. Kültekin dijo que utilizó agentes de IA para el trabajo, aunque la información disponible no detalla qué parte de las pruebas ejecutó cada uno.
OpenSSH señaló en las notas de la versión 10.6p2 que considera que la causa raíz está fuera de sshd, pero que el problema puede explotarse a través del servidor y evitarse allí. La actualización incluye una solución en OpenSSH. Alpine, por su parte, distribuyó paquetes corregidos para sus ramas.
Previdian confirmó un acceso; los informes iniciales diferían
La vulnerabilidad se hizo pública el 5 de noviembre junto con las correcciones. El 6 de noviembre, Help Net Security informó de que Previdian había observado actividad en sus sensores: ocho intentos, todos desde una única dirección IP japonesa y capturados por un sensor. La empresa confirmó que uno de ellos consiguió acceso como root en un honeypot con Alpine Linux y OpenSSH reales.
El fundador de Previdian, Ryan Dewhurst, dijo a Help Net Security que el primer intento observado llegó menos de nueve horas después de la publicación de la CVE. Según su descripción, la dirección de origen 89.116.89[.]18 envió contraseñas excesivamente largas y ejecutó comandos de reconocimiento como id, uname y hostname en sesiones SSH no interactivas. Previdian añadió el fallo a su propia lista de vulnerabilidades explotadas. CISA no lo había incorporado a su catálogo KEV en ese momento.
La cobertura de SecurityWeek publicada el mismo día recogía una situación anterior: decía que todavía no había informes de explotación y anticipaba que el escaneo podía comenzar en cuestión de horas. Fredrik Almroth, cofundador de Detectify y principal investigador de seguridad, estimó que Shodan mostraba alrededor de 22 millones de sistemas con SSH abierto en el puerto 22, aunque advirtió que la cifra real era superior y que solo una parte ejecutaría Alpine. Jake Knott, responsable de inteligencia de amenazas de WatchTowr, esperaba intentos de fuerza bruta antes del fin de semana. El informe posterior de Help Net Security aportó la confirmación de los intentos y del acceso al señuelo.
Las notas de OpenSSH explican la rapidez de la publicación. El equipo dijo que ha recibido numerosos informes de errores de seguridad, varios hallados por modelos de IA o con ayuda de ellos, y que ha observado casos en los que otro investigador descubre de forma independiente un fallo identificado primero por herramientas de IA. Por ese motivo, anunció que por ahora publicará versiones con más frecuencia para que las correcciones lleguen antes, en lugar de agruparlas hasta el siguiente lanzamiento previsto.
Actualizar no basta si el proceso antiguo sigue activo
OpenSSH publicó la versión 10.6p2 el 5 de noviembre de 2026. La corrección evita el bypass en sshd; las notas también incluyen otros cambios, entre ellos habilitar el algoritmo híbrido de firma poscuántica ssh-mldsa44-ed25519 como algoritmo permitido para firmas de CA y corregir un giro de CPU inferior a un segundo cuando se usaba ChannelTimeout.
Alpine publicó paquetes corregidos para las ramas desde 3.16 hasta edge. Las versiones fijadas en su aviso son: 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; y 3.16, 9.0_p1-r6. Las ramas 3.21 y anteriores incluyen versiones que ya no reciben soporte regular; Alpine publicó, aun así, paquetes corregidos hasta 3.16. La versión 3.21 llegó al fin de soporte el 1 de noviembre de 2026.
El paso operativo que Alpine recalca es reiniciar sshd tras actualizar: instalar el paquete no sustituye el proceso que ya está en ejecución. Si no es posible aplicar el parche, el aviso recomienda desactivar PasswordAuthentication y reiniciar el servicio. Antes de hacerlo, hay que comprobar que el acceso con clave funciona y mantener abierta la sesión actual hasta probar una nueva conexión, para evitar perder el acceso administrativo.
Para buscar indicios de intrusión, Alpine recomienda revisar /var/log/messages en busca de líneas de sshd con “Accepted password for” para cuentas sin contraseña, como alpine, root o usuarios de acceso exclusivo con clave. También aconseja revisar el uso de doas, las cuentas creadas recientemente, los archivos y las claves autorizadas en máquinas expuestas. Si no se puede descartar un inicio de sesión, Alpine indica que se debe tratar el sistema como comprometido.
Help Net Security informó además de que circulaban pruebas de concepto en GitHub, pero Previdian advirtió que no estaban verificadas y podían contener malware. Para los administradores, la acción inmediata que señalan Alpine y OpenSSH sigue siendo concreta: actualizar el paquete y reiniciar el demonio, o deshabilitar el acceso por contraseña y reiniciarlo mientras llega la actualización.
Fuentes: Xataka, Alpine Linux, OpenSSH, Red Hat, Help Net Security, SecurityWeek
