OpenSSH: 8 CVEs parcheados y un RCE en el cliente vía MITM

El 13 de julio de 2026, Canonical publicó la nota de seguridad USN-8533-1, que parchea ocho vulnerabilidades de OpenSSH en Ubuntu 22.04, 24.04 y 26.04 LTS. La que se llevó todos los titulares es CVE-2026-60002, y por un motivo poco habitual: no es un agujero en el servidor sshd que todos vigilamos, sino en el cliente ssh. Es decir, el riesgo aparece cuando vos te conectás a un servidor, no cuando alguien se conecta al tuyo.

CVE-2026-60002 es una vulnerabilidad de tipo use-after-free en el cliente OpenSSH (ssh) en versiones anteriores a la 10.4. Se dispara cuando un servidor cambia su clave de host (host key) durante una re-negociación de claves (key re-exchange). Un atacante en posición de man-in-the-middle puede aprovechar ese fallo para ejecutar código arbitrario en la máquina cliente o extraer información sensible del proceso. Se corrige actualizando OpenSSH a la versión 10.4 o superior, o al paquete parcheado de tu release de Ubuntu.

¿A quién afecta un RCE en el cliente SSH y no en el servidor?

Afecta a cualquier máquina que inicie conexiones SSH salientes hacia hosts que no controla del todo: servidores de CI/CD, runners de deploy, jobs de cron que hacen rsync o scp, y estaciones de trabajo de developers que saltan entre servidores. La intuición de seguridad de SSH está entrenada al revés: casi siempre pensamos en proteger el sshd expuesto a Internet. Acá el vector se invierte.

La consecuencia práctica es que un servidor comprometido —o un atacante que logre interceptar el tráfico entre tu cliente y el destino— puede terminar ejecutando código de tu lado. Para un pipeline automatizado que se conecta a decenas de hosts, cada conexión saliente es una superficie de ataque nueva. Por eso las máquinas que más hay que apurar a parchear no son solo los bastiones, sino todo lo que hace ssh, scp o sftp hacia afuera.

¿Qué es exactamente CVE-2026-60002 y cómo se explota?

Es un use-after-free: el cliente libera una porción de memoria y luego la vuelve a usar, y ese estado inconsistente es lo que un atacante puede manipular. El disparador concreto, según la ficha del NVD, es que el servidor cambie su host key durante un key re-exchange. SSH renegocia claves periódicamente dentro de una sesión larga; el fallo vive en ese camino de código.

La severidad está en disputa entre los organismos, y vale la pena mirarla con lupa:

• El NVD lo califica 9,4 (crítico), con vector AV:N/AC:L — o sea, complejidad de ataque baja.
• MITRE lo ubica en 7,7 (alto), con AC:H — complejidad alta, porque hace falta que se alineen varias condiciones (posición MITM efectiva + que el servidor fuerce el cambio de host key en pleno rekey).

Más allá de qué número te convenza, ambos coinciden en el impacto: confidencialidad e integridad altas. Traducido: en el peor caso, ejecución de código; en el caso menos malo, filtración de datos del proceso cliente. No es algo para dejar en la cola de "lo parcheo el mes que viene".

¿Qué otras 7 vulnerabilidades trae USN-8533-1?

USN-8533-1 no es un CVE suelto: son ocho, y varios afectan también flujos cotidianos. Según la nota oficial de Ubuntu, los otros siete son:

• CVE-2026-59995 — sftp escribe fuera de lugar: el cliente sftp no restringía bien dónde se guardaban los archivos descargados desde un servidor controlado por el atacante.
• CVE-2026-59996 — scp escapa al directorio padre: scp podía colocar archivos en el directorio padre al copiar entre hosts remotos.
• CVE-2026-59997 — internal-sftp ignora argumentos: solo reconocía los primeros nueve argumentos de la línea de comandos.
• CVE-2026-59998 — GSSAPIStrictAcceptorCheck con AD: comportamiento no documentado frente a Windows Active Directory.
• CVE-2026-59999 — DisableForwarding no se respeta: DisableForwarding=yes no se aplicaba correctamente sobre PermitTunnel=yes.
• CVE-2026-60000 — bypass de MaxAuthTries: el límite de intentos se manejaba mal para la autenticación GSSAPI.
• CVE-2026-60001 — delay de autenticación salteado: el retardo mínimo de autenticación no siempre se honraba, debilitando la resistencia a fuerza bruta.

Los dos de escritura de archivos (59995 y 59996) son relevantes si tu automatización descarga cosas desde endpoints que no son 100% de confianza; los dos de fuerza bruta (60000 y 60001) importan sobre todo en sshd expuestos a Internet. Ninguno solo iguala a 60002, pero juntos justifican actualizar de una.

¿Cómo sé si mi Cloud Server está afectado?

Corré dos comandos y comparás contra las versiones parcheadas. Primero mirá la versión de OpenSSH y la política del paquete:

ssh -V
apt-cache policy openssh-client openssh-server

Después comparás el número instalado contra el mínimo seguro de tu release, según USN-8533-1:

Ojo con un detalle que confunde: Ubuntu no te lleva a OpenSSH 10.4. Canonical hace backport del parche a la versión que ya trae cada release (por eso 24.04 sigue en la serie 9.6). Lo que importa no es el número de OpenSSH upstream, sino que el sufijo -ubuntuX.Y del paquete sea igual o mayor al de la tabla.

¿Cómo lo parcheo hoy?

Actualizás los paquetes y reiniciás el servicio SSH. En la mayoría de los Cloud Servers Ubuntu alcanza con:

sudo apt update && sudo apt upgrade
sudo systemctl restart ssh

El apt upgrade trae el paquete corregido; el restart del servicio asegura que el sshd nuevo quede corriendo. Un matiz importante para 60002: como es un fallo del cliente, reiniciar el servidor no alcanza para blindar las conexiones salientes. Cualquier sesión ssh que ya esté abierta seguirá usando el binario viejo hasta que la cierres y abras una nueva. Revisá procesos de larga duración —túneles persistentes, agentes de deploy— y reinícialos.

Si administrás una flota, este es el escenario para el que existe el unattended-upgrades con control de reinicios. Si querés profundizar en cómo automatizar este tipo de parches de seguridad sin que un reboot inesperado te tumbe producción, tenemos una nota dedicada a automatizar actualizaciones de seguridad en Ubuntu con control de reinicios que complementa esto.

¿Por qué esto importa especialmente en CI/CD y automatización?

Porque los pipelines son clientes SSH de alto volumen y baja supervisión. Un runner de CI/CD hace decenas de conexiones salientes por día —a repos, a servidores de staging, a nodos de deploy— y nadie está mirando la terminal cuando pasa. Es exactamente el perfil de víctima que describe el análisis de eolrisk sobre USN-8533-1: sistemas automatizados que se conectan a hosts externos.

La recomendación operativa: tratá las imágenes base de tus runners y contenedores de deploy como parte del inventario a parchear, no solo los servidores. Si construís imágenes Docker con un openssh-client adentro, reconstruílas contra la base actualizada. Un pipeline que sigue corriendo con un cliente vulnerable es un canal por el que un host comprometido puede escalar hacia tu infraestructura de build.

Preguntas frecuentes

¿CVE-2026-60002 afecta al servidor SSH?

No. El fallo está en el cliente ssh, no en sshd. El riesgo aparece cuando tu máquina se conecta hacia afuera, no cuando recibe conexiones. Aun así, conviene actualizar el paquete completo, porque otros siete CVEs de USN-8533-1 sí tocan el lado servidor.

¿Necesito OpenSSH 10.4 para estar seguro en Ubuntu?

No en Ubuntu. Canonical hace backport del parche a la versión de cada release, así que 24.04 sigue en la serie 9.6 pero con la corrección incluida. Fijate el sufijo del paquete (por ejemplo 1:9.6p1-3ubuntu13.18), no el número de OpenSSH upstream. La 10.4 es la referencia para quien compila OpenSSH desde el código fuente.

¿Alcanza con reiniciar el servidor después de actualizar?

No para 60002. Reiniciar sshd cubre el lado servidor, pero como esta es una vulnerabilidad del cliente, cualquier sesión o proceso ssh saliente que ya esté abierto sigue usando el binario viejo. Cerrá y reabrí las sesiones activas y reiniciá agentes de deploy o túneles persistentes.

¿Hay un exploit público en circulación?

La explotación de CVE-2026-60002 exige una posición de man-in-the-middle sobre la conexión y que el servidor fuerce un cambio de host key durante el rekey, lo que MITRE refleja en su complejidad de ataque "alta" (7,7). Es un fallo serio, pero no es un "apuntá y disparás". Igual, la existencia del parche facilita el análisis del bug, así que la ventana para actualizar es ahora.

¿Qué versiones de Ubuntu están cubiertas por USN-8533-1?

Ubuntu 22.04 LTS, 24.04 LTS y 26.04 LTS, según la nota oficial publicada el 13 de julio de 2026. Cada una tiene su propia versión de paquete parcheada; corré apt-cache policy openssh-client openssh-server y compará contra la tabla de arriba.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting