Vulnerabilidad en OpenSSH permite iniciar sesión con contraseñas vacías en configuraciones específicas de Linux

Actores de amenazas han comenzado a explotar activamente una vulnerabilidad crítica en OpenSSH que permite la autenticación en cuentas de usuario configuradas sin contraseñas. El fallo, identificado como CVE-2026-123158 y apodado SSHole, afecta específicamente a distribuciones de Linux que utilizan la biblioteca C musl con los Módulos de Autenticación Pluggable (PAM) deshabilitados. Hasta el 9 de noviembre de 2026, los investigadores de seguridad registraron veinte intentos de explotación originados desde trece direcciones IP únicas en varios países.

Qué ocurrió

La vulnerabilidad afecta a sistemas que ejecutan OpenSSH sobre la biblioteca C musl, principalmente en la configuración predeterminada encontrada en Alpine Linux. Cuando los Módulos de Autenticación Pluggable (PAM) están deshabilitados, la lógica de autenticación no aplica correctamente los requisitos de contraseña para campos vacíos. Esta omisión permite a un atacante iniciar sesión en cualquier cuenta que no tenga una contraseña definida, eludiendo efectivamente las verificaciones estándar de credenciales.

Aunque el problema requiere una configuración específica del sistema, representa un riesgo significativo para entornos contenedorizados y despliegues de servidores ligeros que dependen frecuentemente de Alpine Linux. El Sistema Común de Puntuación de Vulnerabilidades (CVSS) califica este fallo con 8.1, lo que indica un nivel de severidad alto. La explotación no requiere herramientas complejas; los atacantes simplemente intentan iniciar sesión con credenciales en blanco, aprovechando la mala configuración para obtener acceso no autorizado.

Más allá de este problema específico de OpenSSH, la semana vio varios otros incidentes de seguridad notables. Una versión troyanizada del demonio del servidor Control Web Panel, cwpsrv, fue distribuida para entregar una puerta trasera sigilosa llamada CWPdoor. Además, se explotó una vulnerabilidad de día cero en los conmutadores de red Zyxel GS1900 para comprometer casi mil dispositivos en todo el mundo, permitiendo a los atacantes robar credenciales e implementar rootkits.

Detalles clave

• ID de la vulnerabilidad: CVE-2026-123158, también conocida como SSHole.
• Sistemas afectados: Sistemas Linux que usan OpenSSH con la biblioteca C musl y PAM deshabilitado, incluyendo instalaciones predeterminadas de Alpine Linux.
• Impacto: Permite el inicio de sesión remoto en cuentas de usuario que no tienen contraseña definida.
• Severidad: Puntuación CVSS de 8.1.
• Nivel de actividad: Se detectaron veinte intentos de explotación desde trece direcciones IP únicas hasta el 9 de noviembre de 2026.
• Ubicaciones de origen: Los intentos provenían de Dinamarca, Irán, Japón, Países Bajos, Noruega, Singapur, Suecia, Suiza y Estados Unidos.

Antecedentes

OpenSSH es la implementación estándar del protocolo de shell seguro utilizada por la mayoría de los sistemas operativos Linux y similares a Unix para la administración remota. Depende de bibliotecas del sistema subyacentes para operaciones criptográficas y manejo de autenticación. La biblioteca C musl es una biblioteca estándar C ligera, rápida y conforme a estándares, a menudo elegida para sistemas embebidos y contenedores debido a su pequeño tamaño. Alpine Linux, una distribución popular para contenedores Docker, utiliza musl por defecto en lugar de la más común glibc.

Los Módulos de Autenticación Pluggable (PAM) proporcionan un mecanismo flexible para autenticar usuarios. Cuando PAM está habilitado, maneja políticas de autenticación complejas, incluyendo la fuerza y la expiración de la contraseña. Sin embargo, algunas configuraciones mínimas deshabilitan PAM para reducir dependencias o mejorar el rendimiento. En estos casos, OpenSSH maneja la autenticación directamente. La vulnerabilidad SSHole surge de un error lógico en esta ruta de manejo directo al interactuar con musl, donde las cadenas de contraseña vacías no se rechazan correctamente para cuentas que deberían requerir credenciales.

Por qué importa

Para los equipos que gestionan infraestructura autoalojada, esta vulnerabilidad destaca los riesgos asociados con configuraciones mínimas o predeterminadas. Muchos desarrolladores eligen Alpine Linux por su pequeño tamaño y reputación de seguridad, asumiendo que menos componentes significan una superficie de ataque menor. Sin embargo, este incidente demuestra que la configuración predeterminada puede introducir debilidades inesperadas. Si sus servidores usan Alpine u otras distribuciones basadas en musl y tienen cuentas de usuario sin contraseñas, son inmediatamente vulnerables a la toma de control remota.

La explotación activa de este fallo significa que los servidores expuestos a Internet ya están siendo escaneados y dirigidos. A diferencia de las vulnerabilidades teóricas, SSHole se está utilizando en la naturaleza ahora mismo. Para ingenieros DevOps y administradores de sistemas, esto requiere una verificación inmediata de las configuraciones del servidor. No basta con parchear el software; también debe asegurarse de que las políticas de autenticación se apliquen correctamente, especialmente en entornos donde PAM ha sido deliberadamente deshabilitado por simplicidad o razones de rendimiento.

Además, este evento sirve como recordatorio de que la higiene de la cadena de suministro y de la configuración es crítica. La misma semana vio ataques contra mecanismos de actualización de suites de seguridad web y dispositivos de red. Confiar en la configuración predeterminada sin comprender sus implicaciones de seguridad puede dejar brechas que los atacantes explotan rápidamente. Los equipos deben equilibrar la conveniencia de las distribuciones ligeras con la necesidad de controles de autenticación robustos.

Qué puede hacer

• Audite todos los servidores Linux que ejecutan OpenSSH para identificar aquellos que usan la biblioteca C musl, como Alpine Linux.
• Compruebe si los Módulos de Autenticación Pluggable (PAM) están deshabilitados en sus archivos de configuración de OpenSSH.
• Asegúrese de que ninguna cuenta de usuario en los sistemas afectados esté configurada con contraseñas vacías o en blanco.
• Aplique inmediatamente los últimos parches de seguridad para OpenSSH proporcionados por el proveedor de su distribución.
• Monitoree los registros de acceso para detectar intentos de inicio de sesión fallidos o exitosos desde direcciones IP desconocidas, especialmente aquellas listadas en informes recientes de amenazas.
• Considere habilitar PAM o cambiar a una distribución basada en glibc si su política de seguridad requiere una aplicación estricta de contraseñas y no puede garantizar que todas las cuentas tengan credenciales fuertes.