Una cadena de contraseña de entre 257 y 1.024 bytes bastaba para iniciar sesión por SSH en determinadas cuentas Linux configuradas sin contraseña. El fallo, divulgado el 5 de noviembre de 2026, afecta a servidores OpenSSH que usan la biblioteca musl y cumplen una combinación concreta de ajustes; OpenSSH publicó la corrección 10.6p2.
La vulnerabilidad, denominada *sshole, fue descubierta y comunicada por el investigador Özgün Kültekin, de Wakefield. Alpine Linux confirmó que sus paquetes estaban afectados y publicó actualizaciones para ramas actuales y antiguas. No se había asignado un identificador CVE al fallo en los avisos publicados ese día.
Una contraseña larga podía coincidir con el asterisco de /etc/shadow
En Linux, una cuenta puede quedar sin acceso mediante contraseña si su campo correspondiente en /etc/shadow contiene un asterisco (*). En las cuentas afectadas, OpenSSH comparaba el resultado del cálculo de la contraseña enviada con ese campo. El problema aparecía cuando el servidor realizaba esa comprobación sin PAM y la función crypt() de musl encontraba una contraseña demasiado larga.
Según el aviso de Alpine, musl devuelve * como indicador de error cuando la contraseña supera los 256 bytes. Como ese mismo carácter figura en el campo de una cuenta sin contraseña, el resultado podía coincidir y sshd aceptaba el acceso. Para que sucediera, el atacante debía conocer el nombre de una cuenta con ese campo y enviar una contraseña de 257 a 1.024 bytes.
Alpine describe el ataque como posible con una sola conexión, sin necesidad de repetir intentos. La distribución también señala que la máquina debe tener al menos otra cuenta local con un hash de contraseña que empiece por $5$ o $6$. Basta una cuenta con uno de esos hashes para que las cuentas sin contraseña queden expuestas si se cumplen las demás condiciones.
El fallo no permite saltarse la autenticación de cuentas que tienen un hash válido. El problema afecta a la ruta de comprobación de contraseñas sin PAM y a cuentas cuyo campo almacenado es *; no es un bypass general de cualquier contraseña SSH.
Las condiciones que dejan expuesto un servidor
Alpine enumera cuatro requisitos simultáneos: ejecutar su paquete openssh-server, compilado sin PAM, o openssh-server-pam con UsePAM no; tener habilitado PasswordAuthentication; contar con una cuenta cuyo campo de contraseña sea *; y disponer de al menos una cuenta local con un hash $5$ o $6$.
La opción de autenticación por contraseña está activada de forma predeterminada en la configuración descrita para Alpine. También quedan dentro del escenario las cuentas creadas para autenticarse solo con clave SSH, las cuentas que usan usermod -p '*' y ciertos usuarios procedentes de servicios de directorio mediante musl-nscd, que pueden no tener una entrada en /etc/shadow.
La cuenta root aparece como root:* en la imagen base de Alpine desde aproximadamente la versión 3.16. El ajuste predeterminado de OpenSSH, PermitRootLogin prohibit-password, impide el acceso directo a root mediante contraseña. Sin embargo, esa barrera no evita que un atacante llegue a root si primero entra en otra cuenta vulnerable que permita elevar privilegios, por ejemplo mediante doas.
El aviso de Alpine incluye entre las instalaciones afectadas las versiones comprobadas de la 3.21 a la 3.24 y edge, además de las ramas 3.16 a 3.20, que ya no reciben actualizaciones regulares. El alcance no se limita a Alpine: Kültekin también señaló OpenWrt, Buildroot y Yocto como sistemas basados en musl que conviene revisar. En OpenWrt, el servidor SSH predeterminado es Dropbear, que no está afectado; el riesgo se plantea si se instala OpenSSH.
Quedan fuera los sistemas que usan glibc, como Debian, Ubuntu y Fedora, los sistemas que autentican mediante PAM con UsePAM yes, y las instalaciones con PasswordAuthentication no. Tampoco afecta a contenedores que no ejecutan sshd, a cuentas bloqueadas con ! en el campo de contraseña ni a máquinas sin cuentas con hashes del tipo indicado. Alpine añade que sus imágenes de nube configuradas mediante cloud-init escriben PasswordAuthentication no.
Imágenes tiny-cloud: del primer arranque al acceso root
El caso más delicado descrito por Alpine afecta a imágenes oficiales tiny-cloud en formatos qcow2, VHD y AMI, desde las versiones 3.18.11 hasta la 3.24.3. Incluyen un usuario alpine sin contraseña y con permiso para usar doas sin contraseña. En el primer arranque no son vulnerables por esa vía, pero pasan a serlo cuando existe en el sistema un hash $6$.
Ese hash puede aparecer cuando un administrador establece una contraseña para la consola o cuando los datos de usuario añaden una cuenta con hashed_passwd. Una vez reunidas las condiciones, el atacante puede iniciar sesión como alpine y utilizar doas para convertirse en root. Alpine especifica que las imágenes construidas desde 3.21.10, 3.22.8, 3.23.8 y 3.24.4 ya incluyen el paquete corregido; las imágenes de versiones anteriores requieren actualizar cada instancia en ejecución o desactivar la autenticación por contraseña.
El aviso de la distribución explica que la corrección también se publicó para ramas antiguas: la versión 3.21 llegó al fin de soporte el 1 de noviembre de 2026, pero Alpine distribuyó paquetes corregidos desde la 3.16. Para las ramas indicadas, las versiones de OpenSSH corregidas son 10.3_p1-r2 en 3.24, 10.2_p1-r1 en 3.23, 10.0_p1-r11 en 3.22, 9.9_p2-r1 en 3.21, 9.7_p1-r6 en 3.20, 9.6_p1-r3 en 3.19, 9.3_p2-r4 en 3.18, 9.1_p1-r7 en 3.17 y 9.0_p1-r6 en 3.16. Para edge, la versión indicada es 10.6_p2-r0.
OpenSSH y Alpine publican la corrección
OpenSSH 10.6p2 evita que sshd acepte esta coincidencia. Los paquetes de las ramas estables de Alpine incorporan un parche para el mismo problema. Actualizar el paquete no sustituye el proceso sshd que ya está en ejecución: Alpine pide reiniciar el servicio después de la actualización. Su recomendación es ejecutar apk upgrade -U -a y después rc-service sshd restart.
Si no es posible instalar el parche de inmediato, Alpine recomienda desactivar la autenticación por contraseña configurando PasswordAuthentication no y reiniciando sshd. La distribución advierte que antes hay que comprobar que el acceso con clave SSH funciona y mantener abierta la sesión actual hasta probar una nueva conexión. Para las instalaciones que no puedan actualizar o aplicar ese cambio, el CERT-FR recomienda desactivar el servicio SSH.
“set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY.”
— Damien Miller, proyecto OpenSSH
El CERT-FR publicó su alerta inicial el 5 de noviembre de 2026 y calificó el riesgo como un bypass de la política de seguridad. Su resumen considera trivial la explotación cuando se cumplen las condiciones y pide comprobar si los sistemas están configurados de forma vulnerable. El organismo también recoge como mitigación preferente desactivar la autenticación por contraseña mientras no se pueda instalar la corrección.
Qué revisar en los registros
Alpine pide buscar en /var/log/messages líneas de sshd con el texto Accepted password para cuentas que no deberían admitir contraseñas, como alpine, root o usuarios de clave pública. También recomienda revisar el uso de doas, las cuentas creadas recientemente, los archivos y las claves autorizadas en máquinas expuestas.
El CERT-FR propone identificar primero las cuentas cuyo campo en /etc/shadow es * y comprobar si existen registros de accesos aceptados para ellas. Si no se puede descartar que haya ocurrido uno, Alpine indica que se debe tratar la máquina como comprometida. En las imágenes vulnerables, una entrada a alpine seguida del uso de doas puede implicar acceso root.
Kültekin sitúa el origen del problema en un cambio de OpenSSH de 2016 destinado a corregir la enumeración de usuarios asociada a CVE-2016-6210. Para evitar que las diferencias de tiempo revelaran si un nombre de usuario era válido, OpenSSH pasó a calcular contraseñas incluso para cuentas sin un hash utilizable. El fallo permaneció en esa interacción con musl, cuya función crypt() devuelve el asterisco cuando excede el límite de longitud.
El investigador cuenta que encontró el fallo con agentes de IA que ejecutaron alrededor de 17.600 pruebas de autenticación, con distintas configuraciones de OpenSSH, hashes malformados y contraseñas demasiado largas. Damien Miller dijo que el equipo de OpenSSH conoció el problema a principios de esa semana y publicó la corrección con rapidez. The Hacker News recoge además su explicación de que el proyecto ve los embargos prolongados como un riesgo, porque agentes de IA han encontrado fallos del mismo tipo por su cuenta, a veces en cuestión de horas.
En la página de *sshole, Kültekin describe varios indicios previos que estuvieron cerca del problema, entre ellos un cambio en Debian relacionado con el valor devuelto por glibc y una revisión de seguridad que corrigió pick_salt() cuatro días antes de su hallazgo. No afirma que esos episodios hubieran detectado la vulnerabilidad de sshd. A fecha de los avisos del 5 de noviembre, el fallo seguía sin identificador CVE y no se habían comunicado ataques reales.
Fuentes: BleepingComputer, RedesZone, alpinelinux.org, Alpine Linux, Özgün Kültekin / Wakefield, CERT-FR, The Hacker News
