SSHole: la falla que desbloquea cualquier cuenta sin contraseña en Linux

El descubrimiento y la explotación pública de una vulnerabilidad de elusión de autenticación en OpenSSH — bautizada SSHole y rastreada como CVE-2026-123158 — ha expuesto un defecto que permaneció latente durante una década, desde 2016. Con una puntuación de 8.1 en la escala CVSS (Alta), la vulnerabilidad afecta exclusivamente a servidores OpenSSH que ejecutan en distribuciones Linux basadas en la biblioteca musl libc sin el marco PAM (Módulos de Autenticación Enlazables) habilitado — el caso típico de Alpine Linux y de innumerables imágenes de contenedor. La CISA ya ha catalogado la vulnerabilidad como siendo explotada activamente en el entorno real e impuso una fecha límite de remediación del 12 de noviembre para agencias federas de EE.UU.

Cómo funciona la falla

La mecánica del SSHole es elegante en su simplicidad. Los administradores de servidores configuran rutinariamente cuentas de servicio bloqueando el inicio de sesión por contraseña — simplemente reemplazando el hash de contraseña en `/etc/shadow` con un asterisco (``). Esa cuenta nunca debería aceptar un inicio de sesión por contraseña, ya que `` no representa un hash válido.

El problema se remonta a un parche de 2016 destinado a corregir la CVE-2016-6210, una vulnerabilidad de enumeración de usuarios. Para prevenir que atacantes identificaran nombres de usuario válidos a través de tiempos de respuesta diferentes, OpenSSH fue modificado para realizar el hash de contraseñas incluso cuando la cuenta no tenía un hash de contraseña utilizable — incluyendo cuentas configuradas con `*`.

Aquí reside el conflicto: la función `crypt()` de la biblioteca musl libc devuelve `*` cuando el hash falla, inclusive cuando la contraseña enviada excede su límite de 256 bytes. OpenSSH, a su vez, compara el valor devuelto por el hash contra el asterisco almacenado en `/etc/shadow`. El resultado: el inicio de sesión es exitoso. Cualquier contraseña entre 257 y 1.024 caracteres funciona como una llave maestra.

El investigador Ozgun Kultekin, quien descubrió y divulgó la vulnerabilidad, señala que la explotación requiere cinco condiciones simultáneas: OpenSSH en un sistema musl, PAM deshabilitado, autenticación por contraseña habilitada, al menos una cuenta con hash `*`, y otra cuenta con hash válido (`$5$` o `$6$`). Con eso, comprometer una sola cuenta con contraseña hace que todas las cuentas sin contraseña sean accesibles.

Qué está realmente afectado

El impacto es más grave en entornos de nube y IoT. Las imágenes oficiales tiny-cloud de Alpine Linux (qcow2, VHD y AMI) de las versiones 3.18.11 a 3.24.3 vienen con un usuario `alpine` cuyo campo de contraseña es `*` y que tiene privilegios `doas` sin contraseña. Al primer arranque, están seguras. En el momento en que cualquier administrador configura un usuario con contraseña, la máquina se vuelve explotable. Un atacante obtiene un shell como `alpine` y usa `doas` para convertirse en `root`.

Los sistemas basados en glibc — Debian, Ubuntu, Fedora, Red Hat, SUSE — no se ven afectados, ya que la implementación de `crypt()` en glibc no devuelve `*` bajo las mismas condiciones. Del mismo modo, los sistemas que utilizan PAM están protegidos, ya que la cadena de autenticación de PAM intercepta la solicitud antes de que el bug de OpenSSH pueda manifestarse.

Kultekin descubrió la falla utilizando agentes de inteligencia artificial que ejecutaron aproximadamente 17.600 pruebas de autenticación con diferentes configuraciones de OpenSSH, hashes de contraseña malformados y contraseñas de tamaño excesivo — un ejemplo revelador de cómo la automatización impulsada por IA se está empleando tanto para descubrir como, presumiblemente, para explotar vulnerabilidades.

Explotación activa y escala del ataque

Los primeros intentos de explotación se registraron el 5 de noviembre de 2026, inmediatamente después de la divulgación pública del parche y del código de prueba de concepto. En la mañana del 6 de noviembre, watchTower, una empresa de seguridad ofensiva, observó ataques asociados a botnets y mineros de criptomonedas. Para el 9 de noviembre, Previdian había registrado 22 explotaciones exitosas desde 14 direcciones IP únicas distribuidas en 9 países.

La CISA añadió la vulnerabilidad a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV) el 9 de noviembre, clasificándola como explotación confirmada en un entorno productivo. El mandato de remediación para las agencias Federales Civiles Executivas de EE.UU. es el 12 de noviembre — apenas tres días después del listado — uno de los plazos más cortos jamás establecidos por la agencia.

Además del listado en KEV, la CISA invocó los Requisitos de Triaje Forense, sugiriendo que las entidades afectadas deben investigar si sus entornos ya han sido comprometidos. Herramientas de detección como el Goonam Scanner de Google ya se están utilizando para escanear activos expuestos a gran escala.

Mitigación y remediación

OpenSSH 10.6p2, lanzado el 5 de noviembre, corrige el problema definitivamente. Las versiones corregidas del paquete de Alpine Linux son:

- Alpine 3.21.10 - Alpine 3.22.8 - Alpine 3.23.8 - Alpine 3.24.4

Los administradores que no puedan actualizar inmediatamente deben deshabilitar la autenticación por contraseña:

``` PasswordAuthentication no ```

Luego reiniciar el daemon `sshd`.

Para verificar posibles compromisos en Alpine Linux, ejecute:

``` grep "Accepted password" /var/log/messages ```

Si el registro muestra un inicio de sesión por contraseña exitoso para una cuenta sin contraseña (como `alpine`, `root` o cualquier usuario solo con clave), trate la máquina como comprometida. Revise el uso de `doas`, usuarios recientemente creados, archivos sospechosos y claves SSH no autorizadas en `/root/.ssh/authorized_keys`.

Qué revela esta falla sobre la seguridad del ecosistema Linux

SSHole expone dos problemas estructurales del ecosistema de código abierto. Primero, la fragmentación de bibliotecas C — musl vs. glibc — crea vectores de ataque que escapan a las pruebas convencionales, ya que la gran mayoría de investigadores y herramientas de auditoría operan en entornos glibc. Segundo, el descubrimiento de una vulnerabilidad de una década mediante pruebas automatizadas impulsadas por IA señala un cambio de paradigma: el penetration testing impulsado por agentes se está convirtiendo en una amenaza real y accesible. Si los agentes de IA pueden encontrar fallas como esta en 17.600 intentos, no es difícil imaginar que los mismos agentes — o sus adversarios — estén explotando esas mismas fallas simultáneamente.

La pregunta que queda: cuando los agentes de seguridad autónomos se vueltan tan comunes como los maliciosos, ¿será la carrera entre detección y explotación ganada por los defensores?

---

Fuentes: BleepingComputer (9 de nov. de 2026), SecurityWeek (6 de nov. de 2026), CVE Details (CVE-2026-123158), Boletín de Seguridad de Alpine Linux (5 de nov. de 2026)

Fuentes: BleepingComputer, SecurityWeek, Alpine Linux, CVE Details

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