OpenSSH SSHole CVE-2026-123158: Parchee sus Servidores Linux

La causa raíz se remonta a 2016, cuando un parche para un problema de enumeración de usuarios (CVE-2016-6210) introdujo un efecto secundario sutil que permaneció oculto cerca de diez años. Esa historia es el verdadero desafío para los equipos empresariales: el comportamiento vulnerable no está en una función nueva, sino en código en el que se confía desde hace una década.

Tres realidades dificultan la gestión de este tipo de fallas. Primero, la configuración determina la exposición. Que un servidor sea vulnerable depende de la biblioteca C, del ajuste de PAM y de que existan cuentas sin contraseña, datos que rara vez aparecen en un inventario de activos. Segundo, los contenedores y equipos ocultan el problema. Alpine es una imagen base muy popular, de modo que el OpenSSH vulnerable puede estar dentro de imágenes que nadie considera servidores. Tercero, la velocidad cambió. El primer intento de explotación se observó menos de nueve horas después de publicado el CVE y, al 8 de noviembre, ya eran 20 intentos desde 13 direcciones IP distintas en países como Dinamarca, Irán, Japón, Países Bajos, Noruega, Singapur, Suecia, Suiza y Estados Unidos.

La ventana entre la divulgación y el ataque se mide ahora en horas. Los equipos que parchean con ciclo mensual quedan, en la práctica, desprotegidos durante la parte más peligrosa de cada divulgación.

SSHole convierte una operación fallida de cálculo de hash de contraseña en un inicio de sesión exitoso. La secuencia siguiente sigue la descripción técnica pública.

1. Encontrar un servicio SSH expuesto. El atacante apunta a un servidor OpenSSH sobre musl con PAM desactivado, como una configuración predeterminada de Alpine Linux accesible desde la red.
2. Elegir una cuenta sin contraseña. La cuenta objetivo está configurada deliberadamente sin contraseña utilizable, lo que el sistema marca con un asterisco (*) en el campo de contraseña.
3. Enviar una contraseña de tamaño excesivo. El atacante entrega una contraseña arbitraria de entre 257 y 1.024 bytes.
4. Falla el cálculo del hash. El código de manejo de contraseñas no puede procesar la entrada y, en lugar de informar un error, devuelve el mismo asterisco que indica una contraseña deshabilitada.
5. La comparación resulta exitosa. El demonio sshd compara el asterisco devuelto con el asterisco almacenado para la cuenta, los considera iguales y concede el acceso.

En el caso del honeypot descrito por Previdian, el atacante usó contraseñas de tamaño excesivo para entrar y luego ejecutó comandos de reconocimiento como id, uname y hostname mediante sesiones SSH no interactivas. Es un comportamiento típico de primera fase: confirmar el acceso, conocer el sistema y decidir el siguiente paso.

¿Qué puede hacer un atacante que lo logra? Según Safe Security, el impacto depende de los privilegios de la cuenta comprometida. Además del acceso SSH no autorizado, los atacantes pueden llegar a credenciales de despliegue, secretos de aplicaciones e infraestructura conectada, lo que permite movimiento lateral o interrupción del servicio. Unos servicios gestionados de TI disciplinados reducen este riesgo al mantener un inventario preciso, aplicar parches con un calendario definido y verificar el resultado en lugar de suponerlo.

Un plan de respuesta claro convierte una vulnerabilidad de titular en un evento de mantenimiento rutinario. Las acciones inmediatas recomendadas en las publicaciones son sencillas.

• Parchear. Instale OpenSSH 10.6p2 o el paquete corregido de su distribución y luego reinicie sshd. Reiniciar importa: un paquete actualizado en disco no protege a un demonio que sigue ejecutando el código anterior.
• Buscar. Alpine aconseja revisar /var/log/messages en busca de líneas de sshd con "Accepted password for" en cuentas que nunca deberían aceptar inicios de sesión con contraseña, como alpine, root o cualquier usuario solo con llaves. Revise el uso de doas y los usuarios, archivos y llaves autorizadas creados recientemente en equipos expuestos.
• Suponer compromiso ante la duda. La guía de Alpine es explícita: si no puede descartar un inicio de sesión, trate la máquina como comprometida.
• Reducir la exposición. No deje SSH abierto a todo internet. Restrinjalo a redes de gestión, una VPN o una puerta de enlace de confianza cero. Una arquitectura de conectividad multioperador y SD-WAN bien diseñada hace esa segmentación consistente en todas las sedes y nubes.
• Eliminar cuentas sin contraseña innecesarias. Menos cuentas con hash de asterisco significa menos formas de activar el error.

El beneficio para el negocio es concreto. Parchear más rápido reduce la ventana de ataque, la revisión de registros limita el daño de un acceso no detectado y las restricciones de red hacen mucho menos probable que la próxima falla de SSH sea siquiera alcanzable. En sectores regulados también genera la evidencia que piden los auditores: qué estaba expuesto, cuándo se corrigió y cómo se verificó.

Una lista práctica para esta semana: inventariar todos los servidores e imágenes de contenedor con OpenSSH, identificar los que usan Alpine o musl, actualizar a 10.6p2 o al paquete del proveedor, reiniciar sshd, buscar en los registros inicios de sesión con contraseña sospechosos y restringir el acceso SSH a redes administradas.

HIT Communications cuenta con más de 30 años de experiencia conectando y protegiendo empresas en América Latina, Estados Unidos y Europa. Una falla como SSHole requiere tres capas trabajando juntas: parcheo rápido, detección continua y una red que limite la exposición.

Nuestros servicios de ciberseguridad incluyen un centro de operaciones de seguridad (SOC) 24/7, SIEM y detección y respuesta gestionadas, para que los inicios de sesión SSH sospechosos se investiguen en el momento y no semanas después. Nuestros servicios gestionados de TI cubren inventario, parcheo, endurecimiento e infraestructura en la nube, de modo que las actualizaciones lleguen a servidores e imágenes de contenedor según el calendario. Por debajo de ambos, nuestro diseño de conectividad multioperador entrega redes segmentadas y redundantes donde el acceso administrativo está restringido por diseño.

Trabajamos con CIOs y gerentes de TI que quieren un solo socio responsable en lugar de varios proveedores. Si no está seguro de cuáles de sus servidores y contenedores usan OpenSSH sobre Alpine o musl, ese es el mejor punto de partida.

SSHole muestra con qué rapidez una falla divulgada se convierte en un ataque: menos de nueve horas hasta el primer intento y un número creciente de atacantes desde entonces. La corrección existe, la exposición se limita a una configuración específica y el momento más económico para actuar es ahora.

Actualice a OpenSSH 10.6p2, reinicie sshd, revise sus registros en busca de inicios de sesión con contraseña que no deberían existir y cierre SSH a internet público. Si desea apoyo para encontrar los sistemas afectados o construir una rutina de parcheo y monitoreo que no dependa de una sola persona, contacte al equipo de HIT Communications y revisaremos su entorno con usted.