SSHole: el fallo de OpenSSH ya se explota en Linux

Una conexión, sin contraseña y con permisos de administrador

Un atacante que alcance el puerto SSH de un servidor Alpine Linux puede entrar sin saber ninguna contraseña: una sola conexión, funciona siempre y no necesita reintentos, según el aviso de seguridad del propio equipo de Alpine. El fallo, bautizado SSHole y registrado como CVE-2026-123158, se hizo público el jueves 5 de noviembre y cuatro días después ya hay explotación activa y acceso root confirmado en honeypots reales.

Para un founder esto no es una nota de infraestructura ajena. Alpine es una de las bases de contenedor más usadas del mundo, y muchas startups corren sobre ella sin saberlo: la eligen por defecto los equipos que optimizan tamaño de imagen y velocidad de despliegue. El problema no está en tu código, está en una capa dos niveles más abajo.

¿Qué es SSHole y cómo permite entrar sin contraseña?

El fallo no vive en OpenSSH ni en musl por separado: aparece en la interacción de ambos. Lo encontró el investigador Özgün Kültekin, que le puso el nombre y publicó una explicación en tono informal.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

La cadena es más simple de lo que parece:

OpenSSH debe estar compilado sin PAM (el paquete openssh-server por defecto en Alpine, o openssh-server-pam con UsePAM no).
La autenticación por contraseña debe estar activada, que es el valor por defecto de OpenSSH.
El sistema necesita una cuenta con * en el campo de contraseña de /etc/shadow (típico de usuarios solo con clave pública) y otra cuenta activa con un hash SHA-256 o SHA-512.
El atacante envía una contraseña de entre 257 y 1.024 bytes.

Ahí se produce la colisión. Desde 2012, la función crypt() de musl rechaza contraseñas SHA-256 y SHA-512 de más de 256 bytes y, al fallar, devuelve el carácter *. Ese * es exactamente lo que hay almacenado como contraseña de las cuentas sin contraseña. OpenSSH compara, coincide y deja pasar. El origen se remonta a un ajuste introducido en 2016 para corregir otra vulnerabilidad (CVE-2016-6210), un efecto secundario que llevaba una década dormido.

Kültekin lo comprobó compilando sshd en todas las combinaciones que se le ocurrieron y lanzando unas 17.600 tentativas de login anómalas. Solo la build con musl y sin PAM aceptó accesos que debía rechazar. Y hay un detalle que vale la pena leer dos veces: reconoció que no lo hizo solo, sino con "enjambres de agentes" de IA trabajando en paralelo.

¿Qué servidores están expuestos y cuáles no?

Alpine confirmó que todas las versiones que revisó están afectadas: 3.21 a 3.24, la rama edge y las anteriores 3.16 a 3.20. Los casos más delicados son las imágenes oficiales tiny-cloud 3.18.11 a 3.24.3, que traen un usuario alpine con * en el campo de contraseña y doas sin contraseña. Son seguras en el primer arranque, pero se vuelven explotables en cuanto existe en la máquina cualquier hash de tipo 6, algo que pasa prácticamente siempre que un administrador define una contraseña de consola o los datos de usuario crean una cuenta con hash.

Buena noticia para el resto del ecosistema: las distribuciones basadas en glibc —Debian, Ubuntu, Fedora— no están afectadas, porque su crypt() devuelve NULL ante el error y sshd ya rechaza ese caso. Tampoco lo están los sistemas con autenticación por contraseña desactivada, los que usan openssh-server-pam con UsePAM yes, las cuentas bloqueadas con ! en el campo de contraseña, Dropbear y OpenBSD.

El riesgo real es la escalada indirecta a root. La cuenta root viene con * desde Alpine 3.16, pero el valor por defecto PermitRootLogin prohibit-password la protege. El problema es cualquier cuenta accesible con permisos de doas o sudo: en las imágenes cloud oficiales de AWS y Azure esa cuenta es el usuario alpine por defecto, con doas sin contraseña. Como resume Kültekin, "eso es root".

¿Quién está explotando el fallo y qué hace al entrar?

GreyNoise informó el lunes que sus honeypots en el sudeste asiático fueron atacados por un grupo que sigue como GT10, con "intrusiones maduras" —es decir, no escaneos oportunistas, sino campañas con post-explotación estructurada. La firma consiguió acceso a un servidor del atacante que reveló otras posibles víctimas y parte de las herramientas usadas.

El backdoor que instala GT10 se rastrea como TAC Agent, soporta ejecución de comandos de shell, reconocimiento del sistema y persistencia, y sus comentarios, logs y errores están en chino. GreyNoise señala además que el implante parece generado con IA. GT10 incluso instala Python 3 en las máquinas que no lo tienen, porque lo necesita para correr su herramienta.

Los números de otras firmas completan el cuadro:

GreyNoise registró la primera explotación exitosa el 7 de noviembre a las 00:46 UTC, unas 40 horas después del parche, con 16 cadenas de explotación exitosas desde seis direcciones IP, según BleepingComputer. En total ha contabilizado 27,5 millones de escaneos al puerto 22 y 20,1 millones de intentos de sesión SSH, aunque no todos son ataques confirmados de SSHole.
Previdian confirmó acceso root en un honeypot con Alpine y OpenSSH reales. Su primer intento llegó menos de nueve horas después de la publicación del CVE, según Help Net Security, desde una IP con base en Japón.
watchTower observó el 6 de noviembre explotación asociada a botnets y a actividad de criptominería, y la finlandesa Defused reportó "una pequeña cantidad de actores" probando el fallo.
CISA no ha incluido el fallo en su catálogo de vulnerabilidades explotadas conocidas (KEV), aunque Previdian sí lo añadió al suyo, según Help Net Security.

En los ataques observados, los intrusos hacen reconocimiento de sistema y contenedor, consultan los servicios de metadatos del cloud, intentan leer hashes de contraseñas y claves SSH de root, y modifican authorized_keys para dejar acceso permanente.

¿Cómo saber si tu servidor ya fue comprometido?

La detección es concreta y no requiere herramientas nuevas. Alpine recomienda buscar en /var/log/messages líneas "Accepted password for" que nombren cuentas sin contraseña, como alpine, root o usuarios solo con clave. Después toca revisar el uso de doas, los usuarios creados recientemente y los archivos authorized_keys.

Si no puedes descartar un login de ese tipo, la instrucción de Alpine es directa: trata la máquina como comprometida. En ese escenario, reconstruir desde una imagen limpia y rotar credenciales es más barato que intentar limpiar el implante.

¿Qué significa esto para tu startup?

Hay tres lecciones que no dependen del tamaño del equipo.

La primera es que la superficie de ataque se hereda. Nadie en tu empresa escribió este bug, pero si tu imagen base usa Alpine sin PAM y con autenticación por contraseña, el agujero es tuyo. Y las imágenes base se actualizan con menos disciplina que el código propio, porque nadie las percibe como código.

La segunda es la velocidad de armado. El aviso de Alpine aísló el problema: menos de nueve horas entre la publicación del CVE y el primer intento, y apenas 40 horas hasta la primera explotación exitosa registrada. Cualquier ventana de "lo parcheamos la semana que viene" equivale a regalar el servidor. Ryan Dewhurst, fundador de Previdian, lo atribuye en parte a la IA: el fallo era trivial de explotar y eso acortó todavía más los tiempos.

La tercera es de fondo: la autenticación por contraseña ya no tiene defensa. Este fallo se apoya en algo que los equipos de seguridad vienen repitiendo hace años. Si tus servidores solo aceptan claves, el ataque no arranca.

¿Qué hacer en las próximas horas?

Inventaría primero. Busca en tus repositorios y pipelines cualquier FROM alpine, imágenes de OpenWrt, Buildroot o Yocto, y contenedores con sshd corriendo. Revisa también qué imágenes base usan tus proveedores gestionados.
Parchea y reinicia. El arreglo está en OpenSSH 10.6p2, publicado el 5 de noviembre, y Alpine liberó paquetes corregidos para todas sus ramas desde la 3.16. En Alpine: apk upgrade -U -a y luego rc-service sshd restart. El reinicio no es opcional: actualizar el paquete no reemplaza el demonio que está corriendo y el binario viejo sigue aceptando conexiones.
Desactiva la contraseña como método. Si no puedes parchear de inmediato, pon PasswordAuthentication no y reinicia sshd después de confirmar que el login por clave funciona. Damien Miller, desarrollador de OpenSSH, fue tajante: estos sistemas deberían dejar de aceptar contraseñas "IMMEDIATELY".
Revisa los metadatos del cloud. Si un atacante ya entró, lo siguiente que hace es pedir credenciales al endpoint de metadatos de la instancia. Restringe el acceso a ese endpoint desde los contenedores que no lo necesitan.
Rota lo que estaba expuesto. Claves SSH, tokens y contraseñas de base de datos que vivían en máquinas afectadas deben considerarse comprometidos si no puedes probar lo contrario.

Conclusión

SSHole es un caso de manual sobre por qué la seguridad de una startup no se mide en herramientas contratadas sino en disciplina de actualización. El fallo llevaba una década latente, se activó por la combinación de dos decisiones razonables tomadas en 2012 y 2016, y pasó de teoría a acceso root real en menos de 48 horas.

La parte incómoda es que el arreglo es trivial: un apk upgrade, un reinicio y desactivar la autenticación por contraseña. La parte peligrosa es que casi nadie reinicia. Si diriges un equipo pequeño, hoy tienes dos tareas y ninguna es opcional: saber qué corren tus servidores y garantizar que el sshd que acepta conexiones sea el parcheado, no el que quedó en memoria desde el último despliegue.