SSHole: el asterisco que debía cerrar la puerta y acabó siendo la llave de tus servidores Linux

Artículo original en inglés: Hackers exploit SSHole OpenSSH flaw to breach Linux systems, de Bill Toulas en BleepingComputer.

En cualquier castillo medieval hay una puerta que importa más que las murallas: el rastrillo. Si cae, da igual lo gruesas que sean las piedras. En internet esa puerta se llama OpenSSH, el servicio por el que administradores de medio mundo entran en sus servidores desde hace más de un cuarto de siglo. Esta semana se ha confirmado que el rastrillo tiene un agujero, que el agujero tiene nombre, SSHole, y que ya hay gente pasando por él. BleepingComputer recoge la confirmación de varias firmas de seguridad: los intentos de ataque empezaron el 5 de noviembre, el mismo día en que apareció el código de prueba, y las primeras intrusiones con éxito se registraron al día siguiente.

Un asterisco con doble vida

Para entender SSHole (CVE-2026-123158) hay que mirar un archivo que casi nadie abre: /etc/shadow. Ahí guarda Linux las contraseñas cifradas de cada cuenta. Y ahí, en las cuentas que no deben poder entrar nunca con contraseña, en lugar de un hash hay un asterisco. Es el cartel de “cerrado”. Ninguna contraseña produce un asterisco al cifrarse, así que ninguna contraseña coincidirá. Esa era la teoría.

La práctica tiene dos ingredientes. El primero es musl, la biblioteca C ligera que usan distribuciones como Alpine, OpenWrt, Buildroot o Yocto, es decir, buena parte de los contenedores y de los cacharros de red del planeta. La función de cifrado de musl, cada vez que falla, devuelve un asterisco. Y falla, por ejemplo, si le pasas una contraseña de más de 256 bytes. El segundo ingrediente es una corrección de 2016: para impedir que un atacante adivinara nombres de usuario midiendo tiempos de respuesta, OpenSSH empezó a cifrar la contraseña incluso en cuentas sin hash válido. Diez años después, las dos piezas encajan como un mecanismo de relojería invertido: el atacante envía una contraseña gigantesca, musl devuelve un asterisco por error, OpenSSH lo compara con el asterisco del “cerrado” y concluye que coinciden. Bienvenido.

El cartel de “cerrado” y la llave que abre son el mismo carácter. Esa es toda la vulnerabilidad.

Quién está en la diana

El investigador Ozgun Kultekin, que destapó el fallo la semana pasada, ha sido preciso con las condiciones: hace falta un sistema basado en musl, autenticación PAM desactivada (el valor por defecto del paquete de OpenSSH en Alpine), contraseñas habilitadas en SSH, al menos una cuenta con asterisco y otra con hash válido. Las cuentas con contraseña real no se ven afectadas. Parece una lista larga hasta que se repara en que las imágenes oficiales de Alpine para AWS y Azure traen de serie una cuenta alpine con privilegios administrativos sin contraseña. Entrar por ahí es entrar como root.

Hay un detalle que merece subrayarse: Kultekin encontró SSHole lanzando unas 17.600 pruebas de autenticación con agentes de IA, combinando configuraciones, hashes malformados y contraseñas desmesuradas. Un fallo que llevaba diez años a la vista de cualquiera lo ha descubierto una máquina probando a lo bruto. Es la misma historia que contamos con php2shell: la IA está vaciando el cajón de los errores antiguos a una velocidad que los defensores no estaban preparados para asumir.

Cuarenta horas: la cronología de la carrera

Los mantenedores de OpenSSH publicaron la corrección, la versión 10.6p2, el 5 de noviembre. El código de explotación apareció unas cuatro horas más tarde. GreyNoise registró la primera intrusión confirmada el 7 de noviembre a las 00:46 UTC, unas cuarenta horas después del parche. En su red de sensores contaron dieciséis cadenas de explotación completas desde seis direcciones IP, con reconocimiento del sistema y de contenedores, consultas a los servicios de metadatos de la nube, intentos de leer hashes y claves de root y de modificar los archivos authorized_keys para quedarse a vivir.

Uno de los atacantes logró root e instaló TAC Agent, un implante de mando y control escrito en Python capaz de ejecutar comandos, subir y bajar archivos y actualizarse a sí mismo. No tuvo suerte: su servidor de control no respondió y nunca recibió una tarea. Los comentarios y mensajes de error del código estaban en chino, y GreyNoise detecta además indicios de operación automatizada, como una comprobación de herramientas pensada para que un planificador corrija sus órdenes sobre la marcha. Agentes contra agentes, otra vez. Otras firmas completan el cuadro: Previdian vio veinte intentos desde trece direcciones en nueve países; watchTowr observó explotación ligada a botnets y minería de criptomonedas; la finlandesa Defused habla de “una pequeña cantidad de actores”. De fondo, GreyNoise contabiliza 27,5 millones de escaneos del puerto 22 y 20,1 millones de intentos de sesión SSH, que no son todos SSHole pero dibujan la temperatura del foso.

El otoño en que se cayeron todas las puertas

SSHole no llega solo. Octubre nos dejó php2shell, las dos vulnerabilidades de PHP que pusieron en armas a media web, y aquel martes negro con ocho brechas en 48 horas: GitLab con un fallo de gravedad máxima que llevaba doce años instalado, LiteLLM envenenado, Railway con los secretos de sus clientes descifrados. El patrón es siempre el mismo y conviene nombrarlo: infraestructura antigua, de confianza, que nadie mira porque “siempre ha funcionado”, y una ventana de horas entre el parche y el primer ataque. En 2026 el tiempo de reacción ya no se mide en semanas. Se mide en lo que tardas en leer el correo del lunes.

Lo que hace especial a SSHole es su posición. PHP es una capa de aplicación; GitLab, una herramienta concreta. SSH es la puerta de todas las casas. No hay servidor Linux, contenedor, router o cámara que no la tenga, y Alpine es, precisamente, la distribución favorita para contenedores por lo poco que pesa. Lo ligero tiene un precio y hoy lo estamos pagando.

Lo que hay que hacer esta tarde, no la semana que viene

La receta es corta. Actualizar OpenSSH a 10.6p2 o posterior; en Alpine basta un apk upgrade openssh. Si no se puede actualizar de inmediato, desactivar la autenticación por contraseña en la configuración del servidor SSH y reiniciar el servicio, algo que, dicho sea de paso, debería estar hecho desde hace años en cualquier máquina seria: las claves existen para esto. Después, revisar: inicios de sesión con contraseña aceptados en cuentas cuyo campo de /etc/shadow es un asterisco, claves desconocidas en authorized_keys, archivos o servicios de arranque con el nombre TAC Agent.

Y una última reflexión para quien gestiona webs, no servidores, y cree que esto no va con él. Tu hosting, tu CDN, tu canalización de despliegue y la imagen Docker de tu agencia corren sobre alguna de estas puertas. No hace falta entender musl para preguntar a tu proveedor si ya ha parcheado. Hacer esa pregunta, hoy, es la diferencia entre leer esta noticia y protagonizar la siguiente.