La vulnerabilidad SSHole de OpenSSH permite acceso root en Alpine Linux en cuestión de horas

Actores de amenazas comenzaron a explotar una vulnerabilidad crítica de OpenSSH, registrada como CVE-2026-123158 y denominada SSHole, menos de nueve horas después de su divulgación pública. El fallo permite a atacantes no autenticados obtener acceso a cuentas configuradas sin contraseña en distribuciones Linux específicas, incluida Alpine Linux. Investigadores de seguridad confirmaron el éxito del acceso root en honeypots, destacando el riesgo inmediato para infraestructuras que dependen de configuraciones predeterminadas.

Qué ocurrió

La vulnerabilidad afecta a sistemas Linux que ejecutan OpenSSH sobre la biblioteca C musl con los Módulos de Autenticación Pluggable (PAM) deshabilitados. Esta configuración es común en distribuciones ligeras como Alpine Linux, que la utiliza por defecto. Un atacante puede enviar una contraseña de tamaño excesivo, entre 257 y 1.024 bytes, a una cuenta que no tiene una contraseña útil establecida. En lugar de rechazar el inicio de sesión, el sistema autentica erróneamente al usuario.

El investigador de seguridad Ozgun Kultekin descubrió el problema, que surge de un parche introducido en 2016 para corregir otra vulnerabilidad, la CVE-2016-6210. La corrección para la enumeración de nombres de usuario creó inadvertidamente un error lógico en el manejo de contraseñas. Cuando la operación de hashing falla debido a la entrada de tamaño excesivo, OpenSSH devuelve un carácter asterisco. El daemon compara entonces este resultado con el asterisco almacenado en el campo de contraseña de las cuentas deshabilitadas, interpretando la coincidencia como un inicio de sesión exitoso.

La firma de inteligencia de amenazas Previdian observó el primer intento de explotación rápidamente tras la publicación de la CVE. Los datos de telemetría identificaron ocho intentos desde una dirección IP geolocalizada en Japón. El atacante utilizó contraseñas de tamaño excesivo para eludir la autenticación y ejecutó comandos de reconocimiento como id, uname y hostname mediante sesiones SSH no interactivas. Previdian confirmó que estos intentos resultaron en un acceso root exitoso en un honeypot que ejecutaba Alpine Linux.

Cómo funciona

El mecanismo central depende de cómo OpenSSH maneja la verificación de contraseñas para cuentas que están deliberadamente bloqueadas o configuradas sin contraseñas. En estos casos, el sistema almacena un asterisco (*) en el campo de contraseña para indicar que el inicio de sesión basado en contraseña está deshabilitado. Normalmente, cualquier intento de contraseña debería fallar. Sin embargo, cuando un atacante proporciona una cadena de contraseña que excede el tamaño esperado del búfer, la función interna de hashing falla de manera controlada pero devuelve el mismo carácter asterisco.

El daemon sshd no distingue entre un fallo legítimo de hashing y el marcador de posición almacenado. Ve el asterisco devuelto por la operación de hashing fallida y lo compara con el asterisco en el campo de contraseña de la cuenta. Esta colisión lógica engaña al módulo de autenticación para que conceda el acceso. El exploit solo funciona en cuentas donde el campo de contraseña está establecido explícitamente en un asterisco. No afecta a cuentas con hashes de contraseña válidos ni a aquellas que utilizan PAM para las comprobaciones de autenticación.

Este comportamiento es específico de la interacción entre OpenSSH y la biblioteca C musl. Los sistemas que utilizan la biblioteca glibc, Dropbear SSH o sistemas operativos no Linux no se ven afectados. Además, cualquier sistema que delegue la comprobación de contraseñas a PAM permanece seguro porque PAM maneja la lógica de validación de manera diferente, evitando la comparación defectuosa dentro de OpenSSH.

Detalles clave

• ID de Vulnerabilidad: CVE-2026-123158 con una puntuación CVSS de 8.1.
• Sistemas Afectados: Sistemas Linux que usan OpenSSH sobre musl libc con PAM deshabilitado, notablemente los valores predeterminados de Alpine Linux.
• Método de Explotación: Enviar una contraseña arbitraria de entre 257 y 1.024 bytes a una cuenta con contraseña deshabilitada.
• Versión del Parche: Corregido en OpenSSH 10.6p2.
• Explotación Activa: Primeros intentos observados menos de nueve horas después de la divulgación; acceso root confirmado en honeypots.
• Limitaciones: No afecta a distribuciones basadas en glibc, Dropbear ni a sistemas que usan PAM para la autenticación.

Por qué importa

Para los equipos de ingeniería que gestionan infraestructura en la nube, esta vulnerabilidad destaca los riesgos asociados con las configuraciones predeterminadas en entornos de contenedores ligeros. Alpine Linux se usa ampliamente en contenedores Docker y clústeres Kubernetes debido a su pequeña huella. Si estas instancias exponen puertos SSH y dependen de la autenticación basada únicamente en claves sin deshabilitar correctamente los campos de contraseña o habilitar PAM, se vuelven vulnerables a una toma de control inmediata. La velocidad de la explotación demuestra que los escáneres automatizados ya están apuntando a este fallo específico.

El impacto va más allá del acceso inicial. Como señaló Safe Security, un ataque exitoso otorga los permisos de la cuenta comprometida. Si el objetivo es una cuenta root o una cuenta de servicio con privilegios elevados, los atacantes pueden acceder a credenciales de despliegue, secretos de aplicaciones e infraestructura conectada. Esto facilita el movimiento lateral a través de la red, pudiendo conducir a interrupciones generalizadas del servicio o exfiltración de datos. El hecho de que el exploit no requiera credenciales robadas lo hace particularmente peligroso para servicios expuestos.

Qué puede hacer

• Actualice inmediatamente a OpenSSH 10.6p2 o aplique el paquete parcheado proporcionado por su distribución Linux.
• Reinicie el servicio sshd después de actualizar para asegurar que la nueva versión esté activa.
• Revise /var/log/messages buscando entradas que digan "Accepted password for" en cuentas que no deberían aceptar contraseñas, como root o alpine.
• Revise el uso de doas, usuarios recién creados, archivos y claves autorizadas en cualquier máquina expuesta para detectar signos de compromiso.
• Si no puede descartar un inicio de sesión no autorizado basándose en los registros, trate la máquina como comprometida y aíslela.
• Considere habilitar PAM si su distribución lo soporta, ya que esto mitiga la vulnerabilidad al cambiar el flujo de autenticación.