Un servidor Alpine con OpenSSH por defecto y la autenticación por contraseña activada acepta la entrada a cualquier cuenta sin contraseña si el atacante envía una cadena de 257 caracteres o más. No hace falta conocer el usuario y la contraseña, no hay que adivinar nada y no hay límite de intentos: una conexión basta. Eso es básicamente lo que dice la ficha es CVE-2026-123158 y puntúa 8,1 sobre 10. OpenSSH puso el parche el 5 de noviembre con la versión 10.6p2.
El error no está en sshd. Está en cómo la biblioteca musl devuelve un error de crypt() cuando la clave supera los 256 bytes: responde con un asterisco, y ese asterisco es exactamente lo que /etc/shadow guarda en las cuentas que no tienen contraseña. OpenSSH compara el resultado con el campo almacenado, los dos son *, y la autenticación pasa. Un solo usuario con contraseña real en la máquina basta para que todos los demás queden alcanzables.
La consecuencia práctica es que el parche no termina al actualizar el paquete. Alpine publicó versiones corregidas para todas sus ramas y advirtió de que el demonio en ejecución sigue siendo el vulnerable hasta que se reinicia, algo que en un contenedor o en un servidor al que solo se entra por SSH no ocurre por sí solo. El aviso de Alpine del 5 de noviembre lo dice con claridad: actualizar y reiniciar, o desactivar el acceso por contraseña mientras tanto.
¿Qué falla exactamente en musl y sshd?
Cuando sshd se compila sin PAM (un módulo de seguridad en Linux), comprueba una contraseña aplicando crypt() y comparando el resultado con el campo de /etc/shadow. Para las cuentas sin contraseña ese campo es un *, una cadena demasiado corta para contener una sal, así que sshd toma la sal de otra cuenta de la máquina y sigue adelante.
Esa lógica asume que crypt() falla con un valor que nunca coincidirá con un hash real, y ahí es donde musl rompe la premisa. Con una clave de más de 256 bytes devuelve `` como indicador de error, sshd compara con * y acepta.
El anuncio de OpenSSH 10.6p2, firmado por Damien Miller, situó la causa fuera de sshd aunque la explotación pase por él. Ese matiz importa para quien tenga que decidir qué parchear: los paquetes de Alpine y de openssh-server sin PAM son los afectados, no las distribuciones con glibc ni las instalaciones con PAM activo.
El origen de la exposición
La lista de condiciones es corta, y las cuatro tienen que cumplirse a la vez. Alpine con su paquete openssh-server habitual, que va sin PAM. PasswordAuthentication yes, que es el valor por defecto si nadie lo cambió. Una cuenta con * en /etc/shadow, que desde Alpine 3.16 incluye root en la imagen base. Y otra cuenta con hash $5$ o $6$ en el mismo fichero.
Hay más sistemas con musl en producción de los que sugiere la conversación pública: OpenWrt, Buildroot, Yocto y buena parte de las imágenes de contenedor minimalistas comparten biblioteca. El análisis de SecurityWeek recoge esos nombres y el detalle que más incomoda: cuentas creadas con `adduser` sin contraseña, usuarios que llegan por un servicio de directorio con musl-nscd y el usuario alpine de las imágenes tiny-cloud entran en la categoría de alcanzables.
Quedan fuera los equipos con PasswordAuthentication no, las cuentas bloqueadas y los servidores donde ninguna cuenta tenga un hash. En la práctica, un servidor al que solo se entra con clave y sin ningún usuario con contraseña no es explotable por esta vía, y ese es el estado en el que debería estar cualquier máquina expuesta a internet desde hace años.
¿Qué hacer hoy y en que en orden?
El primer paso es actualizar y reiniciar. Alpine dejó paquetes corregidos en 3.21.10, 3.22.8, 3.23.8 y 3.24.4, con las versiones de openssh que acompañan a cada rama, desde la 9.9_p2-r1 de la 3.21 hasta la 10.6_p2-r0 de edge. El detalle que se olvida es el reinicio del servicio: apk upgrade -U -a, sustituye el binario, no el proceso que está escuchando.
El segundo paso es cerrar la puerta mientras se propaga la actualización. Poner PasswordAuthentication no en la configuración de sshd y reiniciar resuelve el problema sin tocar el binario, siempre que antes se haya comprobado que la entrada con clave funciona y que la sesión abierta sigue viva. Alpine recomienda crear un fichero en /etc/ssh/sshd_config.d/ para no editar el original a mano.
El error que conviene evitar es el de siempre: aplicar el parche en el servidor de pruebas y dejarlo pendiente en el de producción porque el reinicio de sshd corta la sesión. Un sshd -t antes del reinicio, y una segunda sesión abierta en paralelo, evitan la conversación incómoda con el equipo que se queda fuera.
OpenSSH rompió su propio embargo
Miller explicó la prisa en el anuncio: conocieron el problema el día anterior y decidieron publicar de inmediato porque han visto varios casos de redescubrimiento rápido por agentes de IA, a veces en cuestión de horas.
Durante años el embargo ha sido la norma en seguridad, y el argumento para acortarlo es que un fallo que se puede volver a encontrar con un modelo no está protegido por el silencio.
Esa decisión tiene un coste para quien administra sistemas. Un parche publicado sin ventana de coordinación deja a las distribuciones corriendo para compilar, a los escáneres sin firma y a los equipos sin tiempo para probar. El CVE-2026-98432 del kernel siguió el camino contrario y sirvió para comprobar lo que pasa cuando el parche llega tarde: tres semanas después, Ubuntu y RHEL seguían sin solución publicada.
El resultado de esta vez es que la ventana entre publicación y explotación fue de horas. Previdian registró el primer intento menos de nueve horas después de que se asignara el CVE, con ocho intentos desde una única IP geolocalizada en Japón y acceso de root confirmado en un honeypot con Alpine. No es una campaña: es alguien leyendo el aviso y probando.
Lo que hay que mirar si el servidor estuvo expuesto
La detección es más sencilla que en otros incidentes porque el propio sshd deja rastro. Cualquier línea Accepted password for sobre una cuenta que no tiene contraseña es una señal de alquiler: usuarios como root con PermitRootLogin prohibit-password, cuentas creadas para entrar solo con clave o el usuario alpine de las imágenes en la nube no deberían aparecer nunca en ese registro.
Si el servidor estaba expuesto y no hay forma de descartar una entrada, el criterio de Alpine es tajante: tratarlo como comprometido. Eso significa revisar claves autorizadas nuevas, usuarios creados en la ventana, uso de doas y cualquier proceso que no se explique, antes de volver a confiar en la máquina. El procedimiento para leer un CVE del propio sitio sirve de recordatorio: la puntuación no dice si te afecta, las condiciones sí.
La lección que deja el caso es incómoda y tiene poco de novedosa. Dos bibliotecas que hacían lo que su documentación promete, combinadas, convirtieron el * de las cuentas sin contraseña en una credencial válida. El fallo estuvo once años sin que nadie lo viera, igual que el Brotli que abrió Node2Shell llevaba años en el decodificador que nadie miraba.
Lo que sí cambia es la velocidad. Un fallo de autenticación en el servidor que gestiona el acceso a media infraestructura europea se encontró, se parcheó y se explotó en menos de una semana, y el aviso se escribió pensando en que un modelo lo volvería a encontrar antes que un humano. Para quien administra, la conclusión práctica cabe en una frase: la contraseña por SSH dejó de ser una comodidad para convertirse en una superficie que hay que apagar.
