SSHole ya permite entrar en servidores Linux con configuraciones vulnerables de OpenSSH: los atacantes pueden saltarse la autenticación, ejecutar comandos, buscar credenciales y tratar de conservar el acceso. Varias firmas de seguridad han observado intentos y explotaciones exitosas desde los primeros días de noviembre, y GreyNoise registró un caso en el que el intruso obtuvo privilegios de root.
La vulnerabilidad, identificada como CVE-2026-123158, afecta a sistemas que reúnen condiciones concretas, no a cualquier instalación de OpenSSH. La corrección llegó con OpenSSH 10.6p2, publicado el 5 de noviembre. Administradores que todavía no puedan actualizar pueden desactivar la autenticación por contraseña, aunque eso impide el acceso a quienes aún dependan de ella.
Un fallo ligado a musl y a cuentas con contraseña deshabilitada
El investigador de seguridad Özgün Kültekin divulgó SSHole la semana pasada. El problema se encuentra en la forma en que OpenSSH interpreta el resultado de una función de la biblioteca musl libc al comprobar contraseñas. Puede afectar a distribuciones como Alpine Linux, usada también en entornos cloud y virtualizados.
Para que el ataque sea posible deben coincidir varios requisitos: OpenSSH tiene que ejecutarse con musl, la comprobación debe realizarse sin PAM y la autenticación por contraseña debe estar habilitada. Además, la cuenta objetivo debe tener un asterisco en el campo de contraseña de /etc/shadow, y debe existir otra cuenta local con un hash SHA-crypt válido, según la descripción publicada por RedesZone.
El error se activa con una contraseña excepcionalmente larga. Cuando supera los 256 bytes, la función de hash de contraseñas de musl puede devolver un asterisco como señal de error. OpenSSH interpreta ese valor como una coincidencia con el asterisco almacenado para la cuenta objetivo y acepta la autenticación. Debian Security Tracker describe un intervalo de 256 a 1.024 caracteres en el que algunas configuraciones pueden aceptar cualquier contraseña; RedesZone sitúa el rango documentado entre 257 y 1.024 bytes.
La diferencia entre esos umbrales aparece en las descripciones disponibles, pero ambas coinciden en el mecanismo y en que la vulnerabilidad depende de la configuración. Las cuentas con hashes de contraseña válidos no se pueden saltar mediante este fallo. Kültekin también señaló que hacen falta opciones de autenticación específicas y que el acceso puede elevarse a root si la cuenta comprometida dispone de privilegios administrativos sin contraseña.
GovCERT.HK calificó el aviso como de amenaza alta el 6 de noviembre y recomendó aplicar de inmediato la actualización. Su alerta identifica como afectados los sistemas con versiones de OpenSSH anteriores a 10.6p2 y describe el impacto como una elusión de restricciones de seguridad.
Los primeros indicios aparecieron el 5 de noviembre
El código de prueba de concepto se publicó el 5 de noviembre, unas cuatro horas después de que los mantenedores de OpenSSH lanzaran la versión corregida. BleepingComputer recoge que varias firmas situaron el inicio de los intentos de explotación ese mismo día y que algunas registraron accesos exitosos al día siguiente.
Los datos de honeypots recopilados por Johannes Ullrich, investigador del SANS Internet Storm Center, muestran un aumento brusco de peticiones sospechosas. Sus sistemas Cowrie registraron 232 solicitudes con contraseñas formadas por la letra «A» repetida el 5 de noviembre; el día siguiente fueron 713. Esas cifras cuentan peticiones, no ataques confirmados ni autores únicos: una misma dirección IP puede repetirlas.
Ullrich observó actividad desde el 1 de noviembre, pero consideró que los primeros intentos parecían scripts de fuerza bruta mal configurados, no necesariamente ataques deliberados con SSHole. Algunos habrían introducido comandos de descarga dentro del propio campo de contraseña. Cowrie conserva solo los primeros 255 caracteres de cada entrada, por lo que no permite revisar completamente las contraseñas más largas. Ullrich sospechó que algún inicio de sesión contra sus honeypots pudo tener éxito, aunque sus registros no confirmaron una sesión abierta.
Las direcciones que más intentos generaron en esos datos fueron 213.86.169.133, con 48; 152.233.50.185, con 44; y 92.255.57.7, con 43. RedesZone también informó de que algunas fuentes afirmaban haber confirmado acceso root en un honeypot con Alpine Linux, citando el CVE en una publicación del 6 de noviembre. SANS mantuvo cautela sobre el alcance de la explotación en servidores de producción expuestos a internet.
GreyNoise documentó acceso root y un agente TAC
GreyNoise situó su primer caso exitoso observado en la red el 7 de noviembre a las 00:46 UTC, aproximadamente 40 horas después de publicarse la corrección. Sus investigadores contabilizaron 16 cadenas de explotación exitosas contra redes protegidas por sus sensores, procedentes de seis direcciones IP vinculadas a actividad posterior al acceso. La empresa advirtió que sus observaciones no representan necesariamente el conjunto de ataques relacionados con SSHole.
Tras entrar, los atacantes realizaron reconocimiento del sistema y de contenedores, consultaron servicios de metadatos cloud e intentaron leer hashes de contraseñas y claves SSH de root. También trataron de modificar archivos authorized_keys para mantener el acceso.
En uno de los incidentes, un atacante consiguió privilegios de root e instaló TAC Agent, un agente de comando y control escrito en Python. El implante no logró conectarse a su servidor C2, tac.vpnla[.]org, y no recibió ninguna tarea. Por tanto, aunque el acceso y la instalación se produjeron, GreyNoise no observó que el agente llegara a ejecutar instrucciones de ese servidor.
El análisis del programa muestra funciones para ejecutar comandos de shell, recopilar información extensa del sistema, subir y descargar archivos y actualizarse. TAC Agent no incorpora persistencia por sí mismo; en la actividad observada, los atacantes intentaron asegurar su ejecución configurando un servicio de inicio.
Los comentarios, registros y errores del agente estaban en chino, un indicio que GreyNoise plantea como una pieza que podría combinarse con otras pruebas para investigar el origen del atacante. La empresa también señaló que faltaba una comprobación de herramientas: el programa podía devolver un error que ayudara a un planificador automatizado a corregir comandos y continuar el ataque. Ese detalle apunta a una posible operación automatizada, pero no identifica por sí solo a sus responsables.
GreyNoise ha contado además 27,5 millones de escaneos del puerto 22 y 20,1 millones de sesiones SSH intentadas. La empresa aclara que esas cifras no son ataques SSHole confirmados. Por separado, la firma finlandesa Defused comunicó durante el fin de semana que había visto «a small amount of actors» intentando explotar el fallo y describió la actividad como limitada.
Previdian, otra empresa de seguridad de redes, también confirmó explotaciones exitosas. Sus datos de telemetría mostraron 20 intentos desde 13 direcciones IP de atacantes repartidas en nueve países. La firma de seguridad ofensiva watchTower informó el 6 de noviembre de ataques asociados a botnets y actividad de minería de criptomonedas.
Qué sistemas parcheó Debian y cómo reducir el riesgo
Debian Security Tracker registra como vulnerables los paquetes de OpenSSH incluidos en bookworm, con las versiones 1:9.2p1-2+deb12u10 y 1:9.2p1-2+deb12u9, y en trixie, con 1:10.0p1-7+deb13u4 y 1:10.0p1-7+deb13u2. En forky y sid, el paquete 1:10.6p2-1 figura como corregido. La situación depende de la distribución y del paquete instalado; un número de versión visible no siempre refleja un backport, por lo que RedesZone recomienda comprobar la revisión concreta del paquete.
La recomendación principal de BleepingComputer y GovCERT.HK es actualizar OpenSSH. Alpine ya había publicado paquetes corregidos en sus repositorios, según RedesZone, que aconseja instalar la actualización de la distribución y reiniciar sshd. Si no es posible parchear de inmediato, desactivar PasswordAuthentication cierra esta vía de ataque. La medida requiere comprobar antes si hay usuarios que todavía necesiten iniciar sesión con contraseña, ya que dejarían de poder hacerlo.
También conviene revisar los registros de acceso en busca de inicios de sesión exitosos con contraseña en cuentas cuyo campo de /etc/shadow contiene un asterisco, así como claves SSH no autorizadas o archivos y servicios de inicio relacionados con TAC Agent. RedesZone recomienda fijarse especialmente en intentos fallidos seguidos de una autenticación aceptada dentro de la misma sesión.
La corrección está disponible, pero las observaciones de GreyNoise, Previdian y watchTower muestran que el fallo ya ha pasado de la prueba de concepto a intentos y accesos en entornos reales. Para los sistemas que no pueden aplicar el parche todavía, la decisión inmediata es si pueden prescindir temporalmente del acceso SSH mediante contraseña.
Fuentes: BleepingComputer, RedesZone, GovCERT.HK, Debian Security Tracker
