Ing. Calogero Bono
La vulnerabilidad SSHole de OpenSSH, identificada como CVE-2026-123158, se está explotando en ataques reales. Según BleepingComputer, los primeros intentos comenzaron el 5 de noviembre, el mismo día en que apareció un exploit de demostración, y al día siguiente se produjo el primer éxito. El fallo permite entrar en cuentas de Linux sin conocer la contraseña, en ciertas configuraciones. Si administras servidores con Alpine Linux o contenedores ligeros, el problema te afecta directamente.
Algunos términos, antes de entrar en los hechos. OpenSSH es el software que permite conectarse de forma remota a los servidores. musl es una biblioteca C alternativa a la más común, usada por ejemplo en Alpine Linux. PAM es el sistema modular que gestiona la autenticación en Linux. Hash de la contraseña es el valor con el que el sistema guarda la contraseña en forma no legible. C2 es el servidor de mando y control con el que los atacantes dirigen el malware.
¿Qué es SSHole y cómo funciona?
Según BleepingComputer, el fallo fue hecho público por el investigador Ozgun Kultekin. Afecta a OpenSSH en sistemas Linux basados en musl, entre ellos Alpine, muy usada en entornos cloud y virtuales.
El mecanismo es este. Algunas cuentas tienen en el campo de la contraseña un asterisco, para impedir el acceso con contraseña. Si se envía una contraseña demasiado larga, la función de hash de musl devuelve un asterisco como error. OpenSSH lo toma por una coincidencia con el valor guardado y deja entrar.
Ya escribimos sobre ello en nuestro artículo sobre el bug *sshole en cuentas de Alpine Linux.
¿Qué sistemas están realmente expuestos?
The Hacker News indica una puntuación CVSS de 8,1 y precisa las condiciones. Se necesitan Linux con OpenSSH sobre musl y PAM desactivado, lo que incluye la configuración predeterminada del servidor OpenSSH de Alpine.
Kultekin explica que se necesitan ajustes de autenticación específicos y que las cuentas con hash válido no se ven afectadas. El acceso root es posible donde la cuenta comprometida tiene privilegios administrativos sin contraseña.
¿Qué están haciendo los atacantes?
Según GreyNoise, la primera explotación exitosa se remonta al 7 de noviembre a las 00.46 UTC, unas 40 horas después de la corrección. La empresa registró 16 cadenas de explotación exitosas contra redes que protege, desde seis direcciones IP. Sin embargo, dice que no representan la actividad total.
Los atacantes hicieron reconocimiento del sistema y de los contenedores, consultaron los servicios de metadatos de la nube, intentaron leer hashes y claves SSH de root y modificar el archivo authorized_keys para mantenerse dentro. Previdian habla de 20 intentos desde 13 IP en nueve países. watchTower vio usos ligados a botnets y criptominería.
¿Qué es TAC Agent?
Es un agente Python de mando y control instalado en un ataque a un sistema donde el atacante obtuvo privilegios de root. Según BleepingComputer, ejecuta comandos, realiza un reconocimiento amplio, sube y descarga archivos y puede actualizarse. No tiene persistencia integrada, así que los atacantes configuran un servicio de inicio.
En ese caso no logró alcanzar el servidor C2 y nunca recibió tareas. Ars Technica, citando a GreyNoise, atribuye la actividad a un grupo llamado GT10 y señala que la backdoor tiene comentarios en chino y parece generada con IA. El mismo grupo instala Python3 donde falta.
Límites que conviene conocer
No sabemos cuántos sistemas han sido comprometidos. GreyNoise dice que sus 27,5 millones de escaneos en el puerto 22 y 20,1 millones de sesiones SSH no son ataques SSHole confirmados. Los comentarios en chino no bastan para atribuir el ataque, y las fuentes no coinciden sobre quién es el autor. Ars Technica habla de un grupo llamado GT10, BleepingComputer no lo menciona.
Qué cambia para quien trabaja con lo digital
Si administras servidores Linux, actualiza OpenSSH a la versión 10.6p2, publicada el 5 de noviembre. Como alternativa, desactiva la autenticación por contraseña en SSH, tal como recomienda BleepingComputer. Después verifica los accesos con contraseña exitosos en cuentas con asterisco en /etc/shadow, las claves SSH no autorizadas y los archivos o servicios de inicio de TAC Agent. Quienes usen Alpine en contenedores deben reconstruir las imágenes. Si tienes servidores gestionados por terceros, pregunta si han sido actualizados, por ejemplo con un hosting con actualizaciones de seguridad gestionadas.
Nuestra opinión
El caso muestra lo frágil que es la confianza en un valor de error. Un asterisco devuelto por una biblioteca se convierte en una clave válida para otro componente. No es un fallo exótico, es un error en el límite entre dos componentes. El dato más útil es la rapidez. El código de ataque apareció unas cuatro horas después de la corrección. El margen entre el parche y la explotación ahora se mide en horas, y quien actualiza a final de mes ya llega tarde.
Preguntas frecuentes
¿SSHole afecta a todos los servidores Linux?
No. Afecta a OpenSSH en sistemas con musl y PAM desactivado, como la configuración predeterminada de Alpine. También se necesitan ajustes de autenticación específicos.
¿Cuál es la versión correcta de OpenSSH?
La 10.6p2, publicada el 5 de noviembre según BleepingComputer. Actualizar es la medida principal.
Si no puedo actualizar de inmediato, ¿qué hago?
Desactiva la autenticación SSH con contraseña, como sugiere BleepingComputer. Luego revisa los accesos sospechosos.
¿Qué busca el atacante?
Según GreyNoise, hashes de contraseñas, claves SSH de root y metadatos de la nube. También intentan modificar authorized_keys para mantenerse dentro.
¿Cómo reconozco TAC Agent?
Busca sus archivos y los servicios de inicio creados para él. BleepingComputer también aconseja revisar las claves SSH no autorizadas.
Qué vigilar en las próximas semanas sobre SSH y musl
El panorama sigue en movimiento, con nuevos datos esperados de quienes monitorizan los ataques. Conviene seguir unas pocas cosas concretas.
- Sigue las actualizaciones de GreyNoise y Previdian sobre el número de sistemas comprometidos.
- Comprueba cuándo tu distribución publica las imágenes de Alpine con OpenSSH corregido.
- Revisa qué cuentas tienen asterisco en /etc/shadow y si todavía las necesitas.
