Hackers explotan nueva falla de OpenSSH llamada «SSHole» para vulnerar sistemas Alpine Linux

Los atacantes comenzaron a explotar una falla de OpenSSH recién revelada que permite eludir la autenticación apenas horas después de que se publicara una prueba de concepto (PoC), y la primera brecha exitosa confirmada ocurrió solo 40 horas después del lanzamiento del parche. La vulnerabilidad, registrada como CVE-2026-123158 y apodada «SSHole», permite a un atacante iniciar sesión en cuentas que se suponía tenían la autenticación por contraseña completamente deshabilitada.

El fallo reside en cómo OpenSSH interactúa con musl libc, la biblioteca C ligera que utiliza Alpine Linux y otras distribuciones mínimas que predominan como imágenes base de contenedores en plataformas de nube. Cuando un intento de inicio de sesión usa una contraseña de tamaño excesivo, la función de hash de contraseñas de musl devuelve un error representado por un solo carácter, «*», el mismo valor marcador almacenado en el archivo shadow para las cuentas que tienen el inicio de sesión por contraseña deshabilitado. OpenSSH trata esa coincidencia como válida, abriendo así una vía de acceso a cuentas que en teoría nunca debían ser alcanzables mediante contraseña.

Explotar esta falla requiere una configuración específica — sistemas basados en musl con la autenticación PAM deshabilitada —, por lo que no todos los servidores Linux están expuestos. Pero la ligereza de Alpine la ha convertido en la imagen base predeterminada de una enorme proporción de contenedores Docker y cargas de trabajo de Kubernetes, lo que significa que esta configuración afectada es mucho más común en infraestructura nativa de la nube de lo que sugiere por sí sola la puntuación de severidad CVSS de 8.1. El acceso root es posible si la cuenta comprometida tiene privilegios administrativos sin contraseña.

El equipo de OpenSSH publicó una corrección en la versión 10.6p2 el 5 de noviembre. Ese mismo día apareció una prueba de concepto pública, y los intentos de explotación comenzaron casi de inmediato. Según la firma de inteligencia de amenazas GreyNoise, la primera vulneración exitosa confirmada en el mundo real ocurrió el 7 de noviembre a las 00:46 UTC — alrededor de día y medio después del lanzamiento del parche —, con 16 cadenas de explotación exitosas rastreadas hasta seis direcciones IP de origen, cifras que GreyNoise advierte probablemente subestiman el alcance real de la actividad. Por su parte, investigadores de Previdian registraron 20 intentos de explotación desde 13 direcciones IP en nueve países, mientras que WatchTower vinculó parte de la actividad a operaciones existentes de botnets y minería de criptomonedas. Defused informó un número menor de actores diferenciados con seguimiento limitado.

Una vez dentro, se ha observado a los atacantes ejecutar comandos de reconocimiento, consultar servicios de metadatos en la nube (una técnica común para obtener credenciales de nube), intentar leer hashes de contraseñas y claves SSH de root, y modificar archivos authorized_keys para mantener acceso persistente. En al menos un caso, un atacante desplegó una herramienta de comando y control personalizada basada en Python llamada TAC Agent, aunque en ese caso el implante nunca recibió instrucciones porque su servidor C2 era inaccesible, según informó BleepingComputer.

La brecha de aproximadamente 40 horas entre el lanzamiento del parche y la explotación confirmada en el mundo real coincide con un patrón que los investigadores de seguridad han señalado repetidamente a lo largo de 2026: en cuanto se publica una prueba de concepto para una falla de evasión de autenticación, el escaneo masivo y la explotación suelen comenzar en un plazo de uno a dos días, dejando a los defensores una ventana muy estrecha para parchear antes de que lleguen los ataques automatizados.

Los administradores de sistemas basados en musl, particularmente despliegues de Alpine Linux en entornos de contenedores o en la nube, deben actualizar a OpenSSH 10.6p2 de inmediato. Cuando no sea posible aplicar el parche de inmediato, deshabilitar por completo la autenticación por contraseña en SSH cierra esta brecha. Los equipos de seguridad también deberían auditar los registros en busca de inicios de sesión exitosos inesperados con contraseña en cuentas cuyo campo de contraseña en shadow esté configurado como asterisco, revisar si hay entradas no autorizadas en los archivos authorized_keys, y buscar cualquier rastro de TAC Agent o servicios de inicio desconocidos similares.