CVE-2026-55200: la PoC pública que convierte a cualquier cliente SSH en el objetivo

Introducción

El 29 de junio de 2026 se hizo pública una prueba de concepto (PoC) funcional para CVE-2026-55200, una vulnerabilidad crítica (CVSS 4.0: 9.2) en libssh2, la librería de código abierto que implementa el protocolo SSHv2 del lado del cliente. Esta a diferencia de la mayoría de los incidentes que acaparan titulares, centrados en servidores expuestos a internet, este caso invierte el modelo de amenaza tradicional: el elemento vulnerable no es el servidor SSH, sino cualquier aplicación cliente que se conecte a un servidor SSH malicioso o comprometido. Ya que libssh2 está embebida en herramientas como curl, Git, PHP, agentes de backup, actualizadores de firmware y una lista muy extensa de dispositivos embebidos, la publicación de este PoC reduce de manera drástica la barrera de entrada para explotación y esto obliga a los equipos de seguridad a repensar su inventario de activos: ya no es suficiente el solo auditar lo qué expone la organización hacia afuera, sino también hacia dónde se conectan sus propios sistemas.

¿Qué es el fallo en libssh2?

CVE-2026-55200 es un fallo de corrupción de memoria explotable antes de la autenticación (pre-auth), este afecta a todas las versiones de libssh2 hasta la 1.11.1.

• libssh2 no es un servidor SSH, es una biblioteca en lenguaje C que numerosas aplicaciones utilizan para actuar como cliente SSH/SFTP: establecer conexiones salientes, transferir archivos o ejecutar comandos remotos.
• El problema surge durante el handshake (negociación inicial de la conexión), es decir, en el momento en que el cliente y el servidor hacen el intercambio de los primeros paquetes del protocolo, antes de que exista cualquier autenticación.
• Un atacante que controle o haya comprometido un servidor SSH puede enviar un paquete manipulado a cualquier cliente que se conecte a él. Dicho paquete provoca una corrupción de memoria en el proceso cliente, lo que en el peor escenario resulta en una ejecución remota de código (RCE).
• Lo más relevante es que no se requieren credenciales válidas ni interacción del usuario más allá de que la aplicación cliente inicie la conexión al servidor malicioso. Esto la convierte en una vulnerabilidad de alto impacto y baja complejidad de explotación.
• Al tratarse de una librería frecuentemente enlazada de forma estática, muchas copias vulnerables no se actualizan automáticamente cuando el sistema operativo aplica parches, lo que amplía silenciosamente la superficie de exposición.

¿Cómo funciona?

El fallo reside en la función ssh2_transport_read(), dentro de transport.c, encargada de analizar (parsear) los paquetes SSH entrantes durante la fase de transporte del handshake.

Mecanismo del desbordamiento:

• El protocolo SSH incluye un campo packet_length que indica el tamaño del paquete recibido.
• En la ruta de código vulnerable, libssh2 calcula el tamaño total a reservar en memoria sumando packet_length + mac_len + auth_len, usando operandos de 32 bits antes de convertir el resultado a size_t.
• Un servidor malicioso puede enviar un paquete cifrado cuyo campo packet_length contenga un valor excesivamente grande. Al sumarse con los componentes mac_len y auth_len usando operandos de 32 bits, la operación matemática desborda el entero (integer overflow) y provoca una envoltura (wrap-around).
• Debido a que la validación del límite superior de packet_length ocurre demasiado tarde o está ausente en esa ruta, el asignador de memoria (heap) reserva un búfer diminuto; sin embargo, la lógica posterior intenta escribir el tamaño real del paquete enviado, resultando en una escritura fuera de los límites del búfer asignado (heap out-of-bounds write, CWE-680) que corrompe las estructuras adyacentes en memoria y permite a los datos del atacante desbordar el espacio reservado.
• Dependiendo del binario objetivo, el comportamiento del asignador de memoria y las mitigaciones activas en el sistema (ASLR, canarios de pila, etc.), esta corrupción puede evolucionar desde una simple caída del proceso (DoS) hasta el control de punteros de función y, en consecuencia, ejecución arbitraria de código con los privilegios del proceso cliente.

Sobre la PoC publicada:

• Fue subida a un repositorio de GitHub denominado “exploitarium”, cuyo propio autor advierte que las entradas se publicaron sin un proceso previo de divulgación coordinada.
• El material consiste en un verificador aritmético que demuestra el desbordamiento, un scaffold que simula un servidor SSH malicioso capaz de disparar la condición, y un harness de ejecución remota de código controlado y local que demuestra la clase de explotación en un entorno de laboratorio.
• Los propios autores e investigadores que han analizado el material coinciden en que no se trata de un exploit remoto “llave en mano”: convertirlo en una cadena de RCE fiable contra una aplicación real en producción todavía depende del binario específico, el comportamiento del asignador de memoria, las mitigaciones del sistema operativo y la forma en que cada software integra libssh2.
• Aun así, la disponibilidad pública del código reduce significativamente el esfuerzo de ingeniería inversa necesario para que un actor de amenazas desarrolle una variante funcional contra un objetivo concreto.

Sistemas y componentes afectados

• libssh2: todas las versiones hasta la 1.11.1 inclusive. Corregido en el commit 97acf3d (fusionado el 12 de junio de 2026 vía el pull request #2052), que añade una validación de packet_length contra el límite LIBSSH2_PACKET_MAXPAYLOAD antes de la operación de suma vulnerable.
• Aplicaciones y proyectos que enlazan libssh2 (y por tanto heredan la exposición si conectan con servidores SSH no confiables):
  • curl, cuando se compila con soporte SFTP/SCP basado en libssh2.
  • Git y clientes gráficos que dependen de libssh2 para operaciones sobre SSH.
  • PHP, a través de la extensión ssh2.
  • El paquete ssh del lenguaje R.
  • Agentes de backup, actualizadores de firmware, dispositivos de red y appliances embebidos que implementan funcionalidad de cliente SSH sobre esta librería.
• Un factor agravante: al ser una biblioteca frecuentemente enlazada de forma estática, la actualización del paquete del sistema operativo (por ejemplo, vía apt o yum) no necesariamente actualiza las copias embebidas dentro de binarios de terceros.
• En el mismo lote de parches y divulgación de junio de 2026 se incluyeron y corrigieron dos vulnerabilidades adicionales de alto impacto:
  CVE-2026-55199 (CVSS 8.2): Una denegación de servicio (DoS) que atrapa al cliente en un bucle de CPU mediante un conteo de extensiones falsificado durante el intercambio de claves.
  CVE-2025-15661 (CVSS 8.3): Una vulnerabilidad de lectura excesiva de memoria (heap over-read) en el manejo de SFTP. Nota: Aunque este identificador fue reservado originalmente a finales de 2025, su mitigación oficial y despliegue público masivo se coordinaron para formar parte de este mismo paquete de actualizaciones globales de la librería en 2026.

Mitigación y detección

Remediación prioritaria:

• Inventariar de forma exhaustiva todo software que enlaza libssh2, incluyendo copias estáticas o empaquetadas que los gestores de paquetes del sistema operativo no reportarán automáticamente. curl, Git y despliegues de PHP son los portadores más comunes; también deben revisarse agentes de backup, firmware de dispositivos de red y herramientas de automatización/CI-CD.
• Aplicar una compilación que incluya el commit 97acf3d, ya sea mediante un backport de la distribución utilizada o compilando desde el código fuente parcheado. Algunas distribuciones (como Debian, en su rama testing) ya distribuyen la versión corregida; conviene monitorear los canales de anuncios del proveedor correspondiente para conocer el estado del release oficial etiquetado.
• Aplicar también los parches de CVE-2026-55199 y CVE-2025-15661, corregidos en el mismo lote.
• Para binarios de terceros o de proveedores con enlace estático, solicitar parches fuera de banda y monitorear los boletines de seguridad del fabricante, ya que la corrección depende de que ellos recompilen y distribuyan una nueva versión.

Controles compensatorios mientras se completa el parcheo:

• Restringir las conexiones SSH salientes desde sistemas cliente únicamente a servidores explícitamente confiables, priorizando aquellos procesos que se conectan a endpoints externos o que resuelven nombres de host que un atacante podría redirigir (por ejemplo, mediante DNS spoofing o compromiso de infraestructura intermedia).
• Verificar rigurosamente las claves de host (host keys) en cada conexión, evitando la aceptación automática de huellas digitales no reconocidas.
• Dar prioridad, dentro del proceso de parcheo, a los clientes que interactúan con servidores SSH externos, servicios de automatización, pipelines de CI/CD, agentes de backup y dispositivos IoT/embebidos, dado su mayor nivel de exposición.

Indicadores de compromiso y auditoría:

• Monitorear anomalías en el tamaño de los paquetes durante la fase de negociación SSH, en particular valores de packet_length inusualmente grandes o cercanos a los límites de un entero de 32 bits.
• Vigilar caídas o cierres inesperados de procesos cliente (curl, agentes de backup, procesos PHP, clientes Git) inmediatamente después de iniciar una conexión SSH saliente, especialmente durante la fase de handshake.
• Registrar y correlacionar los destinos de las conexiones SSH salientes iniciadas por sistemas críticos, prestando especial atención a conexiones hacia hosts no catalogados previamente en el inventario de activos confiables.
• Dado que actualmente no se ha reportado explotación activa en estado salvaje, la prioridad de detección debe orientarse a identificar intentos de reconocimiento o pruebas de explotación tempranas, más que a una respuesta a incidentes ya consumados.

Recapitulando…

CVE-2026-55200 ilustra un patrón que la comunidad de inteligencia de amenazas ya había observado en 2019 con CVE-2019-3855, un desbordamiento de enteros casi idéntico en la misma función de transporte de libssh2: los fallos del lado del cliente en librerías de infraestructura ampliamente reutilizadas pueden ser tan peligrosos, o más, que las vulnerabilidades del lado del servidor, precisamente porque rompen el supuesto de que el riesgo se concentra en los sistemas que reciben conexiones entrantes. Con un CVSS de 9.2, ausencia de requisitos de autenticación o interacción del usuario, y una PoC ya disponible públicamente, aunque de naturaleza local y no directamente “llave en mano”, la ventana entre divulgación y explotación activa se estrecha considerablemente. Para los equipos de TI y seguridad, la lección operativa es clara: el ejercicio de gestión de vulnerabilidades no puede limitarse a los sistemas expuestos a internet; el inventario de dependencias enlazadas de forma estática y el control de las conexiones salientes hacia infraestructura no confiable deben tratarse con la misma prioridad crítica que históricamente se ha reservado para la superficie de ataque del lado del servidor.

Referencias

The Hacker News. (2026, 29 de junio). Public PoC released for critical libssh2 CVE-2026-55200 client-side SSH flaw. https://thehackernews.com/2026/06/public-poc-released-for-critical.html

Arctic Wolf. (2026, 30 de junio). Critical remote code execution vulnerability in libssh2 client library require urgent mitigation. https://arcticwolf.com/resources/blog/critical-remote-code-execution-vulnerability-in-libssh2-client-library-require-urgent-mitigation/

GitHub, Inc. (2026, 17 de junio). CVE-2026-55200: libssh2 through 1.11.1 heap-based buffer overflow [Aviso de seguridad]. GitHub Advisory Database. https://github.com/advisories/GHSA-r8mh-x5qv-7gg2

Heise Online. (2026, 29 de junio). Critical libssh2 vulnerability: Proof-of-concept exploit released. https://www.heise.de/en/news/Critical-libssh2-vulnerability-Proof-of-concept-exploit-released-11347906.html

National Institute of Standards and Technology. (2026, 17 de junio). CVE-2026-55200 detail. National Vulnerability Database. https://nvd.nist.gov/vuln/detail/CVE-2026-55200