Cybersecurity·9 min read

CVE crítico en SSH: millones de servidores expuestos por un fallo en el handshake de intercambio de claves

Un fallo en la implementación del KEX de OpenSSH anterior a la versión 9.9 permite a un atacante en posición de red forzar el uso de algoritmos débiles. Parche disponible, acción inmediata recomendada.

Dax Reyes
··11,240 views

Los CVEs críticos en SSH son raros precisamente porque el protocolo lleva décadas de auditorías y análisis. Cuando uno aparece, conviene tomárselo en serio. El CVE-2026-4821, publicado esta semana por el equipo de seguridad de OpenBSD con coordinación de CERT/CC, afecta al mecanismo de intercambio de claves (KEX) de OpenSSH en versiones anteriores a la 9.9 y tiene una ventana de explotación real bajo ciertas condiciones de red.

Ciberseguridad SSH vulnerabilidad

La buena noticia: el parche está disponible, la actualización a OpenSSH 9.9 es sencilla, y no hay evidencia de explotación activa en el momento de la publicación. La mala noticia: el número de servidores con versiones afectadas en internet es enorme. Los escáneres de Shodan y Censys reportan decenas de millones de endpoints SSH expuestos con versiones vulnerables.

¿Qué hace exactamente el bug?

El fallo está en cómo OpenSSH maneja la negociación de algoritmos durante el handshake KEX cuando el cliente propone una lista de algoritmos que incluye variantes obsoletas (específicamente diffie-hellman-group1-sha1 y diffie-hellman-group14-sha1) y el servidor tiene configuradas ciertas combinaciones de KexAlgorithms.

Un atacante con capacidad de estar en posición de Man-in-the-Middle (por ejemplo, en la misma red, mediante ARP spoofing, o comprometiendo un router intermedio) puede manipular los paquetes de negociación para forzar el uso del algoritmo más débil de la lista, incluso si el servidor está configurado para preferir algoritmos modernos.

Esto no permite acceso directo al servidor; requiere que el atacante ya esté en posición de interceptar el tráfico. Pero una vez conseguido, puede degradar la seguridad del canal a un nivel donde ataques de recuperación de sesión son factibles con recursos modernos.

Quién está afectado

  • OpenSSH < 9.9 en cualquier sistema operativo: Linux, macOS, BSDs.
  • Libssh versiones < 0.10.7 (parche separado, mismo vector).
  • Sistemas embebidos con SSH dropbear < 2024.85 (en evaluación).

Versiones de OpenSSH >= 9.9 no son vulnerables. Si actualizaste en los últimos tres meses, probablemente estés bien.

Cómo verificar y parchear

# Verificar la versión actual
ssh -V
# OpenSSH_9.9p1 es la versión parcheada mínima

# En sistemas Debian/Ubuntu
sudo apt update && sudo apt upgrade openssh-server

# En sistemas RHEL/CentOS/Fedora
sudo dnf update openssh

# En macOS (vía Homebrew, la versión del sistema no actualiza automáticamente)
brew upgrade openssh

Después de actualizar, reinicia el servicio SSH. En sistemas críticos, verifica que el servicio levanta correctamente antes de cerrar la sesión actual.

Mitigación adicional: desactiva los algoritmos KEX obsoletos

Aunque el parche es la solución correcta, si por alguna razón no puedes actualizar de inmediato, puedes mitigar el riesgo eliminando los algoritmos débiles de la negociación en /etc/ssh/sshd_config:

KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group18-sha512,diffie-hellman-group16-sha512

Esta configuración elimina todos los algoritmos Diffie-Hellman de grupos pequeños y SHA-1, cerrando el vector de ataque sin necesidad de actualizar el binario. Reinicia sshd después del cambio.

El contexto más amplio

Este CVE es un recordatorio de por qué la configuración por defecto de SSH importa tanto como la versión. Muchos servidores tienen KexAlgorithms sin configurar explícitamente, lo que deja la decisión al defecto del binario — y los valores por defecto históricos de OpenSSH han incluido algoritmos legacy para compatibilidad con clientes antiguos.

La recomendación del equipo de OpenBSD, que van a implementar en futuras versiones, es cambiar el comportamiento por defecto para no ofrecer algoritmos SHA-1 a menos que estén explícitamente habilitados en la configuración. Es el tipo de cambio que genera alguna queja de compatibilidad a corto plazo y mejora materialmente la postura de seguridad por defecto a largo plazo.

TAGS

#ssh#cve#openssh#vulnerabilidad#parche
Share

Dax Reyes

Sistemas y Kernel

// Related

CVE crítico en SSH: millones de servidores expuestos por un fallo en el handshake de intercambio de claves — SYNTHNODE