Una contraseña de 257 letras basta para entrar por SSH en Alpine Linux

A las 00:05 UTC del 6 de noviembre de 2026, ocho horas y diecinueve minutos después de que MITRE publicara el registro de CVE-2026-123158, un sensor de Previdian registró el primer intento de explotación de SSHole, el fallo que permite entrar por SSH en cualquier cuenta sin contraseña de un Alpine Linux con solo escribir entre 257 y 1.024 caracteres cualquiera. OpenSSH publicó el 5 de noviembre la versión 10.6p2 con la corrección, Alpine sacó paquetes para todas sus ramas desde la 3.16 y, en España, INCIBE-CERT emitió el 6 de noviembre un aviso de importancia alta.

Un asterisco, dos decisiones de 2012 y un salt prestado en 2016

El fallo no está en el cifrado de SSH ni en la comprobación de claves. Está en cómo sshd compara una contraseña con el campo correspondiente del fichero shadow cuando no delega esa tarea en PAM, que es la configuración por defecto del paquete openssh-server de Alpine. En Unix, un asterisco en ese campo significa que la cuenta no tiene contraseña válida y que nadie debe poder entrar con una. Es el estado de root en las imágenes base de Alpine, de los usuarios que solo entran con clave y de las cuentas que vienen de un directorio LDAP.

Según la cronología que el descubridor, Özgün Kültekin, de la empresa Wakefield, publica en su web *sshole, la cadena empezó en agosto de 2012, cuando musl cambió el comportamiento de crypt() ante un error. El estándar dice que la función debe devolver NULL, pero varios programas no comprobaban ese valor y se caían, así que musl decidió devolver un asterisco, un hash que en teoría nunca coincidiría con nada.

La captura del diff de ese commit, que Kültekin reproduce en su informe, muestra el cambio exacto: desaparece el return NULL y entra un return que devuelve x o un asterisco según el salt recibido. Veinte días después, el 29 de agosto de 2012, musl incorporó las variantes SHA-256 y SHA-512 de crypt() con un límite de 256 bytes para la contraseña, pensado para evitar que una entrada enorme consumiera CPU, y con el mismo asterisco como respuesta cuando ese límite se supera.

La tercera pieza la puso OpenSSH en julio de 2016 al corregir CVE-2016-6210, una fuga por tiempos de respuesta que permitía saber si un usuario existía. Para igualar los tiempos, sshd empezó a tomar prestado el salt de otra cuenta con hash real cuando la cuenta solicitada no tenía uno que comprobar. Desde entonces, en un sistema con musl y sin PAM, una contraseña de más de 256 bytes contra una cuenta con asterisco hace que crypt() falle, devuelva un asterisco y sshd lo compare con el asterisco almacenado. Coinciden, y la sesión se abre.

Alpine añadió el último eslabón en diciembre de 2021. Tras CVE-2019-5021, que dejaba el root de sus imágenes Docker sin contraseña, el proyecto había bloqueado root con un signo de exclamación, pero eso impedía también entrar con clave SSH sin PAM. El commit fbe926af cambió ese bloqueo por un asterisco y lo dejó listo para el fallo.

OpenSSH cerró la puerta el 5 de noviembre con el commit 4353fdc43, que añade a auth-passwd.c una constante MIN_PASSWORD_HASH_LEN de cuatro caracteres y rechaza cualquier comparación cuando el campo almacenado es más corto. Kültekin cuenta que compiló sshd con glibc y musl, con y sin PAM, con y sin shadow, y que lanzó con enjambres de agentes unas 17.600 autenticaciones anómalas contra todas las combinaciones. Todas se comportaron igual salvo la de musl sin PAM.

Qué servidor está expuesto y cuál no, según Alpine y Check Point

El aviso de Alpine del 5 de noviembre exige que se cumplan cuatro condiciones a la vez: sshd sin PAM (openssh-server, o openssh-server-pam con UsePAM no), PasswordAuthentication en yes (el valor por defecto de OpenSSH), una cuenta con asterisco como contraseña y al menos otra cuenta local con un hash $5$ o $6$ del que sshd pueda tomar el salt. Check Point añade un matiz tras probarlo en su laboratorio, en el análisis de Adi Bleih, responsable de un equipo de investigación de la compañía: esa segunda cuenta tiene que estar activa y tener una contraseña real, y no basta con que exista un hash guardado.

Root queda fuera del alcance mientras PermitRootLogin conserve su valor por defecto, prohibit-password. El problema está en las cuentas que pueden escalar sin contraseña. Alpine reconoce que sus imágenes tiny-cloud para nubes públicas, de la 3.18.11 a la 3.24.3, traen un usuario alpine con asterisco y doas sin contraseña. Esas máquinas no son explotables en el primer arranque, pero pasan a serlo en cuanto un administrador fija una contraseña de consola o cloud-init añade un hash $6$ a cualquier cuenta.

No están afectados, según el mismo aviso, los contenedores que no ejecutan sshd, los sistemas con PasswordAuthentication no, los que usan openssh-server-pam con UsePAM yes, las cuentas bloqueadas con exclamación y los sistemas sin ningún hash con formato $. Damien Miller, desarrollador de OpenSSH, dejó por escrito que el fallo no existe en sistemas distintos de Linux, en Linux con glibc ni en Linux que usa PAM para contraseñas, lo que descarta Debian, Ubuntu, RHEL y sus derivados. Natanael Copa, desarrollador de Alpine, confirmó el 5 de noviembre que Dropbear, el servidor SSH que usan OpenWrt y muchos sistemas embebidos, no está afectado tras revisar su código.

El post de Copa en Fosstodon enlaza la función de comprobación de contraseñas de Dropbear, que no toma prestado ningún salt, y zanja la duda que varios administradores de OpenWrt plantearon a Miller en las horas siguientes al anuncio.

Check Point señala dos cosas que un escáner externo sí puede ver, la versión de OpenSSH en el banner y si el servidor ofrece autenticación por contraseña, y advierte de que los paquetes corregidos de Alpine conservan números de versión antiguos, como 10.3_p1-r2 en la rama 3.24, de modo que un host parcheado puede parecer vulnerable por versión. Cycode revisó las imágenes públicas de Docker Hub que ejecutan un servidor SSH y encontró que Gitea, Gogs, el agente SSH de Jenkins y la imagen openssh-server de linuxserver desactivan el acceso por contraseña por defecto, mientras que las imágenes basadas en Alpine anteriores a la 3.16 se explotan en laboratorio y no van a recibir parche. No hay, en el momento de escribir esta noticia, ningún recuento publicado de servidores expuestos en España ni en el resto del mundo.

Ocho intentos desde Japón y un honeypot de Previdian con root

El registro de CVE-2026-123158 se publicó el 5 de noviembre a las 15:46 UTC con MITRE como CNA. La ficha en NVD sigue en estado recibido y sin análisis propio a 6 de noviembre, así que la puntuación disponible es la del CNA: 8,1 en CVSS 3.1 con vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, complejidad alta por las condiciones que hay que reunir y debilidad CWE-394. El equipo de enriquecimiento de CISA marcó el 5 de noviembre el fallo con exploitation poc, automatable no y technical impact total, y el catálogo KEV no lo incluía a las 13:00 UTC del 6 de noviembre.

Previdian, la empresa de inteligencia de amenazas de Ryan Dewhurst, lo incorporó a su propio catálogo de explotadas a las 09:53 UTC del 6 de noviembre a partir de la telemetría de sus sensores. En declaraciones recogidas por Help Net Security, Dewhurst sitúa el primer intento «less than nine hours after CVE publication» (menos de nueve horas después de la publicación del CVE) y afirma que, en un honeypot con un Alpine real y OpenSSH sin parchear, el atacante consiguió root con una contraseña sobredimensionada y ejecutó id, uname y hostname en sesiones no interactivas. Los ocho intentos salieron de 89.116.89.18, una dirección de Japón. Detectify, por su parte, no tenía constancia de explotación pública a las 15:30 CET del 5 de noviembre, y ninguna autoridad ha confirmado ataques contra sistemas en producción.

La ficha de Previdian, capturada el 6 de noviembre a las 13:08 UTC, recoge esos ocho intentos desde una sola dirección IP contra un único sensor, con la vulnerabilidad fuera del catálogo KEV de CISA. El propio panel advierte de que un intento observado no implica que tuviera éxito, de modo que el root del honeypot es, por ahora, la palabra de Previdian.

La PoC es pública desde el día de la divulgación. El repositorio de Kültekin contiene un script de comprobación, un Dockerfile con un sshd vulnerable para reproducir el fallo en local y el parche de OpenSSH, que según el autor se aplica sobre cualquier versión desde la 7.3p1. El BSI alemán recogió el 6 de noviembre la existencia de esa prueba de concepto en su alerta. Previdian añade que en GitHub circulan otros exploits sin verificar que pueden llevar malware.

Actualizar a 10.6p2 en Alpine y buscar accesos por contraseña en cuentas sin ella

El orden que proponen Alpine, OpenSSH e INCIBE-CERT es este:

1. Comprueba si el servidor cumple las condiciones. En el host, ejecuta como root sshd -T y mira passwordauthentication y usepam. Si el primero está en no o el segundo en yes, no estás expuesto.
2. Actualiza el paquete y reinicia el servicio, porque actualizar no sustituye al demonio en marcha. Las versiones corregidas son 10.6_p2-r0 en edge, 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. Alpine las ha publicado también para las ramas que ya no reciben mantenimiento, incluida la 3.21, cuyo soporte terminó el 1 de noviembre.
3. Si no puedes actualizar hoy, desactiva la autenticación por contraseña, antes comprueba que entras con clave y no cierres la sesión actual hasta verificar un inicio de sesión nuevo.
4. Reconstruye las imágenes de contenedor que lleven un openssh anterior y las instancias creadas a partir de imágenes tiny-cloud anteriores a 3.21.10, 3.22.8, 3.23.8 o 3.24.4.
5. Si el servidor estuvo accesible desde internet antes del parche, busca en los registros accesos por contraseña a cuentas que no la tienen y revisa el uso de doas, los usuarios y ficheros recientes y los authorized_keys. Alpine es tajante: si no puedes descartar un inicio de sesión, trata la máquina como comprometida.
6. Notifica el incidente a INCIBE-CERT si eres empresa o ciudadano y al CCN-CERT si administras sistemas del sector público.

Para el paso 3, Alpine propone crear un fichero nuevo dentro del directorio sshd_config.d con una sola línea:

PasswordAuthentication no

Después hay que comprobar la sintaxis, reiniciar el servicio y verificar que el valor efectivo es el nuevo, porque una directiva anterior en sshd_config puede pisarlo:

sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

Para el paso 5, esta búsqueda localiza en el registro messages de Alpine las entradas de sshd que aceptaron una contraseña. Los usuarios que devuelva hay que cruzarlos con los que tienen un asterisco en el fichero shadow, que son los únicos que no deberían aparecer:

grep -h "Accepted password for" /var/log/messages*

Cualquier coincidencia con una cuenta sin contraseña es un acceso que no debería haber ocurrido. El aviso de INCIBE-CERT, con referencia INCIBE-2026-842 e importancia 4 sobre 4, repite las versiones corregidas de Alpine y la alternativa de desactivar las contraseñas. Quien mantenga clústeres con nodos Alpine encontrará en nuestra guía de ciberseguridad en Kubernetes el contexto para decidir qué contenedores deberían llevar sshd y cuáles no, que en la práctica son casi todos.

OpenSSH, musl y Alpine se reparten un fallo que llevaba diez años a la vista

Miller anunció la versión en Mastodon a las 09:03 UTC del 5 de noviembre, con una instrucción que no deja margen a quien use musl sin PAM: «set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY» (pon PasswordAuthentication=no o desactiva SSH en esos sistemas de inmediato). El post explica también por qué OpenSSH publicó el parche un día después de conocer el problema y sin ventana de divulgación coordinada.

La razón es que el proyecto dice haber observado varios casos de «rapid bug rediscovery by AI agents» (redescubrimiento rápido de fallos por agentes de IA), a veces en horas, y considera ahora que los embargos largos benefician sobre todo a los atacantes. Es la misma lógica que Fortinet aplicó en octubre al parchear fallos encontrados con IA sin detallar cuáles eran, y encaja con el caso del fallo TCP del kernel Linux cuyo exploit escribió un modelo en menos de una hora. SSHole suma otro dato a esa tendencia, porque el propio descubridor atribuye el hallazgo a un barrido con agentes y no a una auditoría manual.

Las notas de la versión 10.6p2 lo dicen con claridad: «We consider the root cause of this bug to be outside sshd» (consideramos que la causa raíz del fallo está fuera de sshd). Rich Felker, autor de musl, respondió el mismo día en la lista de su proyecto y en Mastodon con la posición contraria, y adelantó que el mecanismo de crypt() cambiará en el próximo ciclo de versiones.

Felker escribe que «it is not a musl vulnerability» (no es una vulnerabilidad de musl) y que prefiere no entrar en detalles hasta que los afectados hayan mitigado el problema. Su aviso en la lista de musl recomienda lo mismo que OpenSSH: actualizar a 10.6p2 o poner PasswordAuthentication en no, comprobando antes que el acceso por clave funciona.

Nuestra lectura es que el reparto de responsabilidades importa menos que lo que revela sobre el modelo de seguridad de Alpine. Es la segunda vez en diez días que el proyecto tiene que rehacer algo de urgencia, tras reconstruir su GitLab el 28 de octubre por un ataque que el parche de GitLab no había cerrado, y en ambos casos la distribución ha respondido en horas. El fallo de fondo es otro: Alpine es la base de una parte enorme de las imágenes de contenedor del mundo, y la combinación musl sin PAM que la hace ligera es también la que nadie más prueba. Las 17.600 autenticaciones de Kültekin no encontraron nada en glibc porque esa ruta la ejercitan millones de servidores cada día. La de musl sin PAM solo la ejercitaba Alpine.

También conviene leer el límite de esta noticia. Un contenedor que no ejecuta sshd, que es la inmensa mayoría, no tiene nada que parchear. El riesgo se concentra en máquinas virtuales Alpine en nubes públicas, en los pocos contenedores con un servidor SSH expuesto y en appliances construidos con Buildroot o Yocto sobre musl que lleven OpenSSH en lugar de Dropbear. Como ocurrió con las claves root copiadas por cPGuard la semana pasada, el trabajo posterior al parche es rotar lo que un intruso haya podido leer, y en un Alpine expuesto desde 2016 eso incluye cualquier clave privada almacenada en el equipo.

Dudas habituales sobre OpenSSH tras el parche 10.6p2

Qué es OpenSSH server

Es el componente sshd del proyecto OpenSSH, el servidor que escucha en el puerto 22 y autentica a quien se conecta por SSH. En Alpine se instala con el paquete openssh-server, que está compilado sin PAM y por eso comprueba las contraseñas por su cuenta con crypt(). La variante openssh-server-pam delega esa comprobación en PAM y, con UsePAM en yes, no está afectada por SSHole.

OpenSSH cómo funciona la autenticación por contraseña

El cliente envía la contraseña cifrada dentro del túnel SSH y sshd la pasa a PAM o, si no lo hay, la hashea con crypt() usando el salt del hash almacenado y compara el resultado con el fichero shadow. SSHole aprovecha que en musl ese hash falla con entradas de más de 256 bytes y devuelve el mismo asterisco que marca a las cuentas sin contraseña. Si administras un Alpine expuesto, revisa hoy la salida de sshd -T antes de dar el servidor por seguro.