Seguir Una vulnerabilidad de alta gravedad en OpenSSH permite a atacantes remotos no autenticados eludir la autenticación por contraseña en ciertos sistemas Linux al enviar una contraseña demasiado larga. Catalogada como CVE-2026-123158 y apodada SSHhole, la falla tiene un puntaje CVSS 3.1 de 8,1 y afecta principalmente a entornos Linux donde sshd está vinculado con musl libc y opera sin PAM. Alpine Linux es la plataforma más afectada porque su paquete estándar de openssh-server utiliza esta configuración por defecto.
La vulnerabilidad resulta de una interacción inesperada entre la validación de contraseñas de OpenSSH y la implementación crypt() de musl libc. Cuando se proporciona una contraseña excesivamente larga, crypt() puede devolver la cadena * para indicar un error. Algunas cuentas Linux que están configuradas sin una contraseña convencional también almacenan * en el campo de contraseña de /etc/shadow. En condiciones vulnerables, sshd puede interpretar incorrectamente los valores coincidentes como autentificación exitosa.
Un atacante no necesita conocer la contraseña del usuario objetivo. Si un servicio SSH expuesto cumple con las condiciones requeridas, un atacante que puede acceder al servicio puede autenticar ciertas cuentas usando una contraseña dentro del rango de longitud vulnerable. El impacto depende de los privilegios asignados a la cuenta comprometida. Acceder a un servicio privilegiado o una cuenta capaz de usar doas o otro mecanismo de escalamiento de privilegios podría llevar a un compromiso completo del sistema.
OpenSSH abordó el problema en Portable OpenSSH 10.6p2, lanzado el 5 de noviembre de 2026. Alpine Linux lanzó simultáneamente paquetes de OpenSSH corregidos para todas las ramas soportadas y varias ramas más antiguas. El equipo de OpenSSH describe el lanzamiento como una solución crítica de seguridad para sistemas Linux que utilizan musl libc con PAM deshabilitado.
Ya están disponibles entornos de reproducción pública y material de prueba de concepto. Sin embargo, a partir del 6 de noviembre de 2026, las fuentes revisadas no informan sobre explotación confirmada de la vulnerabilidad en ataques del mundo real, y la falla no ha sido añadida al catálogo de Vulnerabilidades Explotadas Conocidas de CISA.
Las organizaciones pueden fortalecer las defensas contra nuevas vulnerabilidades de elusión de autenticación con la Plataforma de Inteligencia de Detección Nativa AI de SOC Prime, acelerando la caza de amenazas y la ingeniería de detección en entornos SIEM, EDR, XDR y Data Lake.
Los equipos de seguridad también pueden utilizar Prime Architect para transformar la inteligencia de vulnerabilidades en consultas de caza y lógica de detección adaptadas a su telemetría disponible de SSH, autenticación, endpoint y red.
Detectar CVE-2026-123158 monitoreando inicios de sesión exitosos basados en contraseña a cuentas que normalmente utilizan autenticación solo con clave, intentos de autenticación inusuales que contienen contraseñas abnormally largas, acceso remoto inesperado a cuentas de servicio y actividad postautenticación inconsistente con el comportamiento normal de la cuenta.
El contenido de detección puede no estar disponible para cada CVE. Consulte la Plataforma de SOC Prime para conocer la cobertura actual. Si las detecciones relevantes todavía no están disponibles, vuelva a consultar ya que constantemente se añaden nueva inteligencia de amenazas y contenido de detección.
Análisis de CVE-2026-123158
CVE-2026-123158 afecta a OpenSSH sshd antes de Portable OpenSSH 10.6p2 cuando se ejecuta en Linux con musl libc y la autenticación de contraseña ocurre sin PAM. El CVE tiene un puntaje CVSS 3.1 de 8,1 con el vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, reflejando explotación remota sin privilegios previos ni interacción del usuario pero requiriendo una configuración específica del sistema y cuenta.
La causa raíz reside en la interacción entre OpenSSH y la función de hashing de contraseñas proporcionada por musl libc.
En sistemas donde PAM está deshabilitado, sshd realiza la validación de contraseñas utilizando la funcionalidad crypt() del sistema. Para una cuenta típica, /etc/shadow contiene un hash criptográfico de contraseña, y el valor generado a partir de la contraseña proporcionada por el usuario se compara contra el hash almacenado.
musl libc se comporta de manera diferente cuando la contraseña proporcionada excede su longitud de entrada soportada. Para contraseñas más largas de 256 bytes, crypt() devuelve * como un valor de error en lugar de un hash de contraseña normal.
El problema surge porque * también se usa comúnmente en /etc/shadow para cuentas que no tienen una contraseña tradicional configurada.
Si un sshd vulnerable recibe una contraseña demasiado larga para una de estas cuentas, el flujo de autenticación puede comparar efectivamente la * devuelta por crypt() con la * almacenada en la entrada de shadow de la cuenta. Los valores coinciden y la autenticación puede suceder incorrectamente.
La descripción del CVE afirma que, para configuraciones de cuenta afectadas, contraseñas entre 256 y 1024 caracteres pueden resultar en autenticación exitosa. Reproducciones independientes describen contraseñas que superan el límite normal de 256 bytes como suficientes para desencadenar la condición vulnerable.
Por lo tanto, la falla no es un bypass de contraseña universal que afecta a todas las implementaciones de OpenSSH.
Varias condiciones específicas deben alinearse.
Primero, el servidor debe usar musl libc. Alpine Linux es el ejemplo principal en el mercado, aunque otros entornos Linux incrustados o mínimos también pueden usar musl.
Segundo, sshd debe autenticar usuarios sin PAM. El paquete estándar de openssh-server de Alpine está construido sin PAM, mientras que la configuración alternativa openssh-server-pam está protegida cuando UsePAM yes está habilitado.
Tercero, la autenticación por contraseña debe estar habilitada. PasswordAuthentication yes es la configuración relevante. Los sistemas configurados para autenticación solo por clave pública con PasswordAuthentication no, no están expuestos al camino de ataque documentado.
Finalmente, el atacante necesita una cuenta cuyo campo de contraseña contenga *. Estos pueden incluir usuarios solo de clave, cuentas creadas sin contraseñas, algunas identidades proporcionadas a través de servicios de directorio y ciertos usuarios de imágenes en la nube.
Alpine también señala una condición adicional: al menos una cuenta local debe contener un hash de contraseña estilo $5$ o $6$ para que el camino de autenticación vulnerable opere como se describe.
La cuenta root merece especial atención. Alpine comúnmente almacena root:*, pero el PermitRootLogin prohibit-password predeterminado de OpenSSH evita la autenticación por contraseña directamente a root. Como resultado, una instalación estándar de Alpine no expone automáticamente el acceso directo a root a través de este error.
Esa protección no elimina el riesgo más amplio. Si otra cuenta con * en su campo de contraseña es accesible remotamente y tiene derechos administrativos a través de doas, sudo, capacidades de contenedor u otros mecanismos privilegiados, una autenticación exitosa aún puede proporcionar un camino para el compromiso completo del sistema.
Las imágenes tiny-cloud oficiales de Alpine son particularmente relevantes. La investigación de seguridad identificó versiones donde la cuenta alpine podría cumplir con las condiciones vulnerables y también podía usar doas para obtener privilegios elevados. Esto ilustra por qué los defensores deben evaluar los privilegios de la cuenta en lugar de asumir que la vulnerabilidad proporciona acceso inofensivo de usuario o acceso root automático en cada entorno.
Las distribuciones de Linux basadas en glibc como Debian, Ubuntu y RHEL no se ven afectadas por esta vulnerabilidad específica porque el comportamiento vulnerable depende de la implementación de hashing de contraseñas de musl libc. Los sistemas que utilizan PAM para la validación de contraseñas de SSH tampoco están en la configuración vulnerable documentada.
Los contenedores requieren una calificación similar. Alpine se utiliza ampliamente como imagen base de contenedor, pero los contenedores ordinarios que no ejecutan sshd no son vulnerables a través de esta vía de ataque. La principal preocupación son los contenedores, dispositivos, entornos de desarrollo o cargas de trabajo heredadas que instalan y exponen explícitamente un servidor SSH.
El panorama de PoC de CVE-2026-123158 se ha desarrollado rápidamente. Los laboratorios de reproducción pública se mencionan directamente en el registro de vulnerabilidades, demostrando que los defensores deben asumir que la elusión de autenticación puede reproducirse sin acceso a investigación de explotación privada. Esto eleva materialmente la urgencia de remediación aunque no se haya informado de explotación maliciosa confirmada.
La vulnerabilidad fue reportada por Özgün Kültekin de Wakefield. OpenSSH lanzó públicamente la versión 10.6p2 con la solución de seguridad el 5 de noviembre de 2026. Las fuentes primarias revisadas no especifican la fecha exacta en la que el investigador descubrió o informó privadamente el problema.
La corrección de OpenSSH añade una validación diseñada para prevenir que se acepten valores de error y hashes de contraseña cortos no válidos durante la autenticación de contraseña. OpenSSH señala que considera que la causa raíz subyacente existe fuera de sshd, pero debido a que la condición puede ser explotada a través del servidor SSH, el proyecto implementó una solución defensiva en OpenSSH.
Alpine Linux ha aplicado retroactivamente la corrección en varias ramas:
| Rama Alpine | Paquete OpenSSH corregido |
| borde | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
Los administradores deben confiar en el estado del paquete de su distribución en lugar de solo el banner de la versión de SSH. Las distribuciones de Linux frecuentemente aplican retroactivamente parches de seguridad sin cambiar la versión de OpenSSH upstream mostrada durante el handshake de SSH. Por lo tanto, un servidor que muestra una cadena de versión más antigua puede ya contener la corrección del vendedor.
Para la detección de CVE-2026-123158, los defensores deben priorizar la telemetría de autenticación SSH. Una señal de caza particularmente fuerte es un inicio de sesión exitoso con contraseña en una cuenta que está destinada a usarse solo con autenticación de clave pública o que no tiene una contraseña utilizable configurada.
En sistemas Alpine, los administradores pueden revisar /var/log/messages, logs centralizados de autenticación, registros SIEM, o telemetría equivalente para eventos de contraseña aceptada que involucren cuentas de servicio inesperadas, solo de clave o administrativas.
Los defensores deben correlacionar la autenticación exitosa con direcciones IP de origen, tiempos de inicio de sesión, duración de la sesión, comandos ejecutados después del inicio de sesión, elevación de privilegios, cambios en authorized_keys, creación de cuentas, trabajos programados y conexiones de red salientes inesperadas.
La telemetría de red también puede ayudar a identificar sistemas expuestos. Los servicios SSH alcanzables externamente que publicitan autenticación de contraseña o interactiva por teclado deben recibir prioridad de remediación más alta, particularmente cuando el sistema subyacente es Alpine u otra distribución basada en musl.
En este momento, no hay en particular CVE-2026-123158 IOCs como direcciones IP de atacante confirmadas, dominios, hashes de malware, o infraestructura de comando y control. La ausencia de indicadores estáticos hace que el monitoreo del comportamiento del SSH y la actividad de la sesión subsecuente sea particularmente importante.
Mitigación de CVE-2026-123158
La principal remediación es instalar OpenSSH 10.6p2 o el paquete corregido suministrado por la distribución de Linux. Los administradores de Alpine deben actualizar el sistema completo usando los repositorios de paquetes actuales y reiniciar sshd después. Actualizar solo el paquete no reemplaza el proceso del daemon SSH que ya está en ejecución.
Las organizaciones que ejecutan contenedores basados en Alpine deben reconstruir y reimplantar cualquier imagen que instale openssh-server. Simplemente actualizar el sistema operativo host no corrige los paquetes vulnerables de OpenSSH incrustados en imágenes de contenedor.
Los administradores también deben identificar la exposición antes de asumir que cada host de Alpine es vulnerable. Las comprobaciones clave incluyen:
- Determinar si el host utiliza musl libc.
- Verificar si sshd se ejecuta con PAM deshabilitado.
- Comprobar si la autenticación por contraseña está habilitada.
- Identificar cuentas capaces de inicio de sesión cuyo campo de contraseña de /etc/shadow sea *.
- Revisar los privilegios asignados a esas cuentas.
- Confirmar el paquete OpenSSH instalado contra la versión de paquete corregida de la distribución.
Si el parcheo inmediato no es posible, las organizaciones deben desactivar la autenticación por contraseña de SSH.
Configurar:
PasswordAuthentication no
y, donde corresponda:
KbdInteractiveAuthentication no
Los administradores deben confirmar que la autenticación de clave pública funciona antes de aplicar esta configuración para evitar perder acceso administrativo legítimo.
La configuración de SSH debe ser validada y el daemon recargado o reiniciado. Después, una verificación externa debe confirmar que el servidor solo ofrece autenticación por clave pública.
Restringir la accesibilidad de la red proporciona una defensa adicional en profundidad. SSH generalmente debería ser accesible solo desde redes administrativas de confianza, infraestructura VPN, hosts bastión, o listas de acceso de IP de origen explícitas en lugar de estar universalmente expuesto a internet.
Las organizaciones también deben reconsiderar si SSH es necesario dentro de los contenedores en absoluto. Los entornos de orquestación modernos generalmente brindan alternativas como docker exec o kubectl exec, eliminando un servicio de autenticación remoto innecesario.
Para sistemas potencialmente expuestos, revise los inicios de sesión exitosos con contraseña históricos antes de la remediación. Preste especial atención a cuentas configuradas sin contraseñas e identidades que normalmente se espera que autentiquen exclusivamente con claves SSH.
Si se identifica un inicio de sesión exitoso inesperado, trate la cuenta como potencialmente comprometida. Revise el historial de shell donde esté disponible, la ejecución de procesos, la escalación de privilegios, nuevas o modificadas entradas en authorized_keys, cambios de usuarios y grupos, trabajos programados, scripts de inicio, instalación de paquetes y conexiones de red salientes.
Las credenciales y claves accesibles a la cuenta comprometida deben considerarse potencialmente expuestas y rotarse según los hallazgos de la investigación. Si la cuenta tenía privilegios administrativos, los defensores deben expandir la investigación a todo el anfitrión y a cualquier sistema accesible usando credenciales almacenadas allí.
El material público de prueba de concepto significa que las organizaciones no deberían esperar evidencia de ataques generalizados antes de aplicar la corrección. Los requisitos previos de explotación reducen la población vulnerable, pero los sistemas que cumplen con esas condiciones pueden accederse remotamente sin conocimiento de una contraseña válida.
FAQ
¿Qué es CVE-2026-123158 y cómo funciona?
CVE-2026-123158 es un bypass de autenticación por contraseña que afecta a OpenSSH sshd en sistemas Linux que utilizan musl libc sin PAM. Cuando se pasa una contraseña excesivamente larga a la función crypt() de musl, puede devolver * como un valor de error. Si la cuenta objetivo también tiene * almacenado en /etc/shadow, las configuraciones vulnerables de sshd pueden interpretar incorrectamente los valores como coincidentes y permitir la autenticación.
¿Cuándo se descubrió por primera vez CVE-2026-123158?
La vulnerabilidad fue reportada por Özgün Kültekin de Wakefield. OpenSSH publicó la corrección de seguridad en Portable OpenSSH 10.6p2 el 5 de noviembre de 2026, y el CVE se hizo público el mismo día. Las asesorías primarias revisadas actualmente no revelan la fecha exacta del descubrimiento privado original del investigador.
¿Cuál es el impacto de CVE-2026-123158 en los sistemas?
La explotación exitosa permite que un atacante remoto no autenticado inicie sesión en una cuenta calificada sin conocer su contraseña. El impacto resultante depende de los permisos de esa cuenta. El compromiso de un servicio o cuenta estándar puede exponer datos y recursos de aplicaciones, mientras que el acceso a una cuenta con doas, sudo o privilegios equivalentes puede conducir potencialmente a un compromiso completo del sistema.
¿CVE-2026-123158 todavía puede afectarme en 2026?
Sí. Las instalaciones vulnerables de OpenSSH permanecen expuestas hasta que se parcheen o se desactive la autenticación por contraseña. Los sistemas de mayor riesgo son entornos Linux basados en musl como Alpine Linux que ejecutan sshd sin PAM y contienen cuentas sin contraseña calificadas. Existe material de reproducción pública, aunque no se ha informado de explotación confirmada en el entorno en noviembre 6, 2026.
¿Cómo puedo protegerme de CVE-2026-123158?
Actualice a OpenSSH 10.6p2 o al paquete corregido de su distribución y reinicie sshd. Si el parcheo no puede completarse de inmediato, desactive la autenticación por contraseña y por interacción con teclado, restrinja la exposición de SSH a redes de confianza y revise inicios de sesión exitosos con contraseña para detectar actividad sospechosa. Los administradores deben seguir monitoreando los avisos de los proveedores para obtener detalles actualizados sobre CVE-2026-123158 a medida que evoluciona la inteligencia de explotación.
