Saltar al contenido
Fali Fuentes

OpenSSH «SSHole» (CVE-2026-123158): bypass de autenticación en Alpine Linux y musl libc

Read this article in English

La vulnerabilidad CVE-2026-123158, denominada «SSHole», permite a un atacante remoto autenticarse sin contraseña en servidores OpenSSH compilados contra musl libc sin PAM. Con CVSS 8.1, afecta principalmente a Alpine Linux en su configuración por defecto, donde PasswordAuthentication yes y la ausencia de PAM crean la superficie de ataque. El fallo se corrigió en OpenSSH 10.6p2 y en los paquetes de Alpine publicados el 5 de noviembre de 2026; aunque la divulgación ocurrió hace cinco días, la ventana de parcheo sigue siendo crítica porque el PoC es público, el escaneo de puertos 22/TCP con credenciales sobredimensionadas está automatizado y la ruta a root en imágenes cloud está documentada y reproducible.

Condiciones de explotación y alcance en Alpine Linux

La explotación requiere tres condiciones simultáneas: OpenSSH anterior a 10.6p2 vinculado a musl libc sin PAM, PasswordAuthentication yes (valor por defecto en Alpine) y al menos una cuenta local con hash SHA-256 o SHA-512 ($5$/$6$) en /etc/shadow. Si existe una cuenta con campo de contraseña * (sin contraseña, típica para acceso solo por clave), el atacante puede enviar una contraseña sobredimensionada (257-1024 bytes) y lograr autenticación. Alpine confirmó que todas las ramas 3.16-3.24 y edge son vulnerables.

El aviso oficial de Alpine Linux detalla que el paquete openssh-server se compila sin PAM por defecto, lo que expone a la inmensa mayoría de instalaciones. Las imágenes cloud «tiny-cloud» (3.18.11-3.24.3) incluyen el usuario alpine con campo * y doas sin contraseña, lo que convierte un bypass inicial en compromiso total de root tras establecer cualquier hash $6$ en el sistema. Esta cadena de privilegio está documentada en el aviso de Alpine y en el análisis de Safe Security.

No se ha confirmado explotación en campañas reales hasta el 6 de noviembre, solo actividad de escaneo y prueba de concepto en un honeypot. La primera explotación observada ocurrió en menos de nueve horas tras la publicación, desde una IP geolocalizada en Japón, ejecutando comandos de reconocimiento id, uname y hostname. La velocidad de aparición de PoC público reduce drásticamente la ventana de parcheo seguro.

Mecanismo técnico: cadena de tres fallos en musl libc

El bug no es corrupción de memoria sino un fallo lógico en la validación de contraseña introducido por el parche de CVE-2016-6210. En musl libc, la función crypt() devuelve una cadena vacía cuando la entrada supera 256 bytes, y OpenSSH interpreta ese resultado como coincidencia con el campo * de cuentas sin contraseña. La reutilización del salt de una cuenta con hash válido completa la cadena de tres fallos: límite de 256 bytes, comparación errónea y ausencia de PAM.

Safe Security explica que el atacante necesita conocer un nombre de usuario con campo * y que exista al menos un hash $5$/$6$ en el sistema. La contraseña oversized fuerza a crypt() a fallar silenciosamente, produciendo la cadena vacía que OpenSSH equipara al marcador de cuenta deshabilitada. Este comportamiento solo ocurre en builds sin PAM, ya que PAM maneja la verificación por separado y no está afectado.

El parche upstream en OpenSSH 10.6p2 corrige la validación de contraseñas para cuentas con campo *. Alpine backportó la corrección a todas las ramas, incluidas las EOL 3.16-3.20, demostrando buena práctica de cadena de suministro. La solución requiere reiniciar sshd tras actualizar el paquete; el mero apk upgrade no reemplaza el demonio en ejecución.

Impacto en imágenes cloud y escalada a root

Las imágenes oficiales tiny-cloud de Alpine son vector crítico: arrancan con usuario alpine (campo *) y doas sin contraseña. Al establecer cualquier contraseña de consola se crea un hash $6$, activando instantáneamente la vulnerabilidad para ese usuario. Un atacante remoto logra entonces acceso SSH sin credenciales y, mediante doas -n id, obtiene root en un solo paso. Safe Security publicó una demostración completa de esta ruta.

Esta dinámica rompe la asumida seguridad de cuentas «solo clave»: el campo * ya no garantiza inmunidad a autenticación por contraseña si convive con cualquier hash SHA-crypt. Bloquear root con PermitRootLogin prohibit-password no mitiga el riesgo si existe otro usuario con escalada sin contraseña. La defensa debe abordar tanto el parche como la configuración de privilegios locales.

En entornos contenedorizados, la imagen base vulnerable persiste aunque el host esté parcheado. La recomendación es reconstruir imágenes sobre paquetes Alpine corregidos (p. ej., 10.3_p1-r2 en 3.24, 9.0_p1-r6 en 3.16) y redeployar contenedores. La superficie de ataque incluye appliances, routers y cualquier dispositivo que exponga SSH con la configuración por defecto de Alpine.

Detección, velocidad de explotación y ventana de parcheo

Los logs estándar de Alpine (/var/log/messages) registran Accepted password for en cuentas sin contraseña, pero no la longitud de la contraseña enviada. El indicador clave es un login por contraseña exitoso en una cuenta configurada para acceso solo por clave. Correlacionar con creación de usuarios, claves SSH autorizadas y posteriores comandos doas/sudo permite caza de amenazas efectiva.

La explotación en un honeypot a las nueve horas demuestra que el escaneo masivo de puertos 22/TCP con credenciales oversized está automatizado. La ventana de parcheo crítica exige priorizar la actualización de sistemas expuestos a Internet o redes de gestión. La ausencia de explotación en campaña confirmada no reduce la urgencia; el PoC público y la simplicidad del exploit (una conexión, sin reintentos) garantizan adopción rápida por actores de amenaza.

Como referencia, la misma semana se divulgó CVE-2026-116606/CVE-2026-111560 en Barracuda ESG (bypass de autorización pre-auth + inyección de comandos), distinta en vector (appliance de correo) pero igual en urgencia de parcheo. Ambos casos ilustran la convergencia de fallos de autenticación en infraestructura crítica y la necesidad de procesos de parcheo automatizados y probados.

Mitigaciones inmediatas y recomendaciones de hardening

La acción prioritaria es actualizar a OpenSSH 10.6p2 o al paquete Alpine corregido correspondiente a cada rama (p. ej., 10.3_p1-r2 en 3.24, 9.0_p1-r6 en 3.16) y reiniciar sshd con rc-service sshd restart. En contenedores, reconstruir imagen y redeployar. Verificar con sshd -T | grep -i passwordauthentication que el valor sea no tras aplicar PasswordAuthentication no como medida temporal.

Si no es posible parchear de inmediato, desactivar autenticación por contraseña (PasswordAuthentication no en sshd_config o drop-in en /etc/ssh/sshd_config.d/00-no-passwords.conf), validar configuración con sshd -t y reiniciar. Requiere acceso por clave SSH ya funcional; mantener sesión abierta hasta validar nuevo login. No protege si UsePAM yes y PAM permite contraseña por otra vía.

Auditar cuentas con campo * en /etc/shadow y privilegios de escalada (doas, sudo sin contraseña). Eliminar o bloquear cuentas innecesarias. Restringir exposición SSH a redes de gestión (VPN, bastión, firewall cloud). Desactivar sshd en contenedores que no lo requieran. Estas medidas son defensa en profundidad; no sustituyen al parche pero reducen superficie mientras se despliega la actualización.

Ficha estructurada para consulta y agentes de IA

{
  "format": "rafael-fuentes-article/1.0",
  "language": "es",
  "title": "OpenSSH «SSHole» (CVE-2026-123158): bypass de autenticación en Alpine Linux y musl libc",
  "summary": "Análisis técnico del bypass de autenticación en OpenSSH sobre musl sin PAM: condiciones, mecanismo, impacto en imágenes cloud y mitigaciones inmediatas.",
  "author": "Rafael Fuentes",
  "publicationDate": "2026-11-10T06:01:35.051+01:00",
  "eventDate": "2026-11-05",
  "url": "https://falifuentes.com/rafael-fuentes-2026-11-10-am-es/",
  "translation": {
    "language": "en",
    "url": "https://falifuentes.com/rafael-fuentes-2026-11-10-am-en/"
  },
  "topics": [
    "Ciberseguridad",
    "Correo",
    "Español",
    "Noticias de Ciberseguridad",
    "Seguridad en la Nube"
  ],
  "sources": [
    "https://www.alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass",
    "https://safe.security/resources/blog/sshole-high-severity-openssh-vulnerability-turns-disabled-passwords-into-unauthorized-access"
  ]
}
SYSTEM_EXPERT
Rafael Fuentes – BIO

Soy un experto en ciberseguridad con más de veinte años de experiencia liderando proyectos estratégicos en la industria. A lo largo de mi carrera, me he especializado en la gestión integral de riesgos cibernéticos, la protección avanzada de datos y la respuesta efectiva a incidentes de seguridad. Poseo una certificación en Ciberseguridad Industrial, que me ha dotado de un conocimiento profundo en el cumplimiento de normas y regulaciones clave en ciberseguridad. Mi experiencia abarca la implementación de políticas de seguridad robustas y adaptadas a las necesidades específicas de cada organización, asegurando un entorno digital seguro y resiliente.

Comparte
Scroll al inicio