*sshole en OpenSSH: una contraseña de 257 caracteres vulnera la cuenta root

Lo que parecía un bug de caso extremo — un error de comparación de cadenas en una combinación específica de bibliotecas C — se ha convertido en una de las vulnerabilidades más relevantes del otoño. La falla, apodada \*sshole (CVE-2026-123158) por el investigador Özgün Kültekin de Wakefield, reside en la intersección casi invisible entre OpenSSH y musl libc, la biblioteca C ligera que alimenta Alpine Linux, OpenWrt, Buildroot e innumerables imágenes de contenedores. El resultado: cualquiera con acceso a la red puede iniciar sesión en cuentas configuradas para rechazar contraseñas — incluida la raíz — simplemente enviando una contraseña entre 257 y 1.024 caracteres.

La corrección ya está disponible desde el 5 de noviembre (OpenSSH 10.6p2), pero el código de explotación pública apareció cuatro horas después. Para el 9 de noviembre, la CISA ya había añadido la vulnerabilidad a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV), con plazo hasta el 12 de noviembre para agencias federales de EE.UU. Empresas como GreyNoise, watchTowr, Previdian y Defused confirman explotación activa desde el 7 de noviembre.

Cómo funciona *sshole

La mecánica de la falla es elegante en su simplicidad. Cuando el sshd del OpenSSH se ejecuta en un sistema con musl libc sin PAM (Pluggable Authentication Modules), la verificación de contraseña opera en modo simplificado: el sshd solicita que la biblioteca C realice el hash de la contraseña ingresada y compara el resultado con el valor almacenado en `/etc/shadow`. Las cuentas configuradas para rechazar el inicio de sesión por contraseña tienen un asterisco (`*`) en su campo de hash.

El problema es el siguiente: musl libc, cuando recibe una contraseña con más de 256 bytes para hacer hash, falla silenciosamente y devuelve `*` — el mismo valor usado para indicar "cuenta sin contraseña". OpenSSH, a su vez, interpreta ese retorno como una coincidencia de hash exitosa. El resultado: al enviar 257 caracteres (o cualquier cantidad entre 257 y 1.024) como contraseña, el atacante obtiene acceso exitoso.

El origen del bug se remonta a 2016, cuando un parche para corregir una vulnerabilidad de enumeración de usuarios (CVE-2016-6250) introdujo la lógica de comparación. Nueve años después, Kültekin identificó que el parche no consideraba el comportamiento específico de musl. Describe la falla en sshhole.com, donde detalla todas las condiciones necesarias.

Quiénes están en riesgo

No todos los servidores Linux están en peligro. El ataque solo funciona cuando todas las siguientes condiciones son verdaderas:

1. El servidor ejecuta OpenSSH en musl libc (no en glibc — Debian, Ubuntu, Fedora y Red Hat están seguros) 2. OpenSSH fue compilado sin PAM (el patrón de Alpine Linux) 3. La autenticación por contraseña está habilitada (predeterminado de OpenSSH) 4. Existe al menos una cuenta con `*` en el campo de hash y otra con hash válido en el sistema

Esta combinación es común en: - Alpine Linux — la distribución más afectada, con parches backported desde la versión 3.16 - Imágenes de contenedor base en Alpine — la imagen oficial `alpine:tiny-cloud` desde la 3.18.11 hasta la 3.24.3 incluye el usuario `alpine` sin contraseña y con privilegios `doas` - Routers y dispositivos embebidos — OpenWrt, Buildroot y Yocto que usan musl - Imágenes de cloud en AWS/Azure — donde el usuario predeterminado puede tener privilegios de elevación sin contraseña

Los sistemas con PAM habilitado, los sistemas con glibc y las imágenes configuradas vía cloud-init (que desactivan el login por contraseña) no son afectados.

La línea de tiempo de la explotación

La cronología de explotación del *sshole es un caso de estudio sobre velocidad:

- 5 de noviembre, 09:14 UTC — OpenSSH 10.6p2 liberado; Alpine publica paquetes corregidos - 5 de noviembre, ~13:00 UTC — código de explotación público en GitHub - 7 de noviembre, 00:46 UTC — GreyNoise registra la primera explotación exitosa en su red de honeypots - 7 de noviembre — watchTowr confirma ataques a botnets y mineradores de criptomonedas - 9 de noviembre — CISA añade CVE-2026-123158 al KEV con plazo de 12 de noviembre

Previdian identificó 22 tentativas de explotación a partir de 14 ÍPs únicos hasta el 9 de noviembre. GreyNoise confirmó 16 sesiones de post-explotación a partir de 6 IPs maliciosas. Los ataques observados incluyen ejecución de comandos de reconocimiento (`id`, `uname`, `hostname`), creación de nuevos usuarios, modificación de `authorized_keys` e instalación de mineradores.

La respuesta de la comunidad

La reacción del proyecto OpenSSH fue inusualmente rápida. El desarrollador Damien Miller clasificó el ajuste como "critical security workaround" y alertó a la comunidad a través de oss-security y Mastodon: "stop reading and set `PasswordAuthentication=no` or disable SSH for these systems IMMEDIATELY".

El equipo de Alpine Linux backportó el fix para todas las versiones activas desde la 3.16 — incluyendo releases que ya estaban fuera de soporte. El equipo también recomendó reiniciar `sshd` después de la actualización, ya que la variable de estado en tiempo de ejecución que detecta contraseñas inválidas no se reevalúa automáticamente.

CISA, por su parte, añadió la vulnerabilidad al KEV el 9 de noviembre, lo que obliga agencias federales de EE.UU. a mitigar el riesgo hasta el 12 de noviembre bajo la Directiva Operativa Vinculante 26-04.

Qué hacer ahora

Para administradores enfrentando pánico, el camino de menor resistencia es claro:

1. Actualice OpenSSH a 10.6p2 (o el paquete backported de su distribución). En Alpine, ejecute `apk upgrade -U -a` y compare la versión con la advisory oficial — las versiones backported pueden tener número más bajo que 10.6p2 2. Si no puede actualizar inmediatamente, desactive la autenticación por contraseña: `PasswordAuthentication no` en `sshd_config`, seguido de reinicio del servicio 3. Verifique si hay compromiso: revise usuarios `doas`, `authorized_keys`, archivos modificados recientemente. Si hay cualquier duda de que un login exitoso ocurrió, trate la máquina como comprometida 4. Escanee la infraestructura: el Cloudflare SSHole Lab y el Google goonami-scanner ofrecen herramientas de detección pasiva

Por qué importa

El *sshole es un recordatorio desconfortable de que la seguridad del ecosistema Open Source depende de cadenas de dependencia que se extienden mucho más allá del software en sí. El bug no está en OpenSSH — el proyecto considera la causa raíz "fuera de sshd". Está en musl libc, en la forma como la biblioteca C maneja fallos en operaciones criptográficas. Y musl, a su vez, es elegido por desarrolladores que buscan imágenes más pequeñas y más rápidas para contenedores.

Lo que hace la falla particularmente perturbadora es que fue descubierta por un solo investigador que construyó OpenSSH de múltiples formas — glibc/musl, con/sin PAM, con/sha256/sha512 — y notó una divergencia. La herramienta de descubrimiento fue humana, no automática. Y, sin embargo, la falla estaba allí desde 2016. Lo que cambia no es la existencia de la falla, sino la capacidad de herramientas de generación de código asistidas por IA para encontrar estos patrones a escala.

La pregunta que queda no es sobre *sshole en sí — es sobre cuántas otras como ella están esperando a alguien con tiempo y curiosidad suficientes para construir el sistema errado y notar que se comporta de forma inesperada.

Fuentes: BleepingComputer, Cloudflare Radar, BleepingComputer

✓ Fuentes independientes cruzadas y verificadas antes de la publicación