CVE-2026-55200: exploit publico para un fallo critico en libssh2 que afecta a curl, Git y PHP sin que exista todavia un parche oficial

El 29 de junio de 2026 se publico en GitHub una prueba de concepto para CVE-2026-55200 (CVSS 9.2), una vulnerabilidad critica de corrupcion de memoria en libssh2, la libreria cliente de SSH integrada en cientos de herramientas y dispositivos. El fallo permite a un servidor SSH malicioso o comprometido provocar un desbordamiento de heap en cualquier cliente que se conecte a el, sin necesidad de credenciales validas ni interaccion adicional del usuario. La direccion del ataque es la que menos se suele vigilar: no es el servidor el que esta en peligro, es el cliente que se conecta a un servidor SSH no confiable. libssh2 esta integrado en curl, Git, PHP, agentes de copia de seguridad, actualizadores de firmware y un largo listado de dispositivos embebidos. Muchas de esas copias estan enlazadas de forma estatica, lo que significa que una actualizacion del paquete de la distribucion no las corrige, y en muchos casos el equipo que mantiene la herramienta ni siquiera recuerda que incluye libssh2 internamente. El parche ya esta fusionado en el repositorio principal del proyecto, pero a fecha de publicacion de este articulo todavia no existe una version oficial etiquetada, lo que obliga a las distribuciones y a los proyectos dependientes a aplicar el parche por su cuenta antes de que llegue el paquete oficial.

‍

¿Que se sabe de CVE-2026-55200?

Los hechos documentados por The Hacker News, VulnCheck, OpenCVE, CyberSIXT y PurpleOps son los siguientes:

• Vulnerabilidad: desbordamiento de entero a desbordamiento de buffer (CWE-680) en la funcion ssh2_transport_read() del fichero transport.c, la funcion que analiza los paquetes SSH entrantes durante el handshake. El campo packet_length no se valida correctamente antes de usarse en operaciones aritmeticas de 32 bits.
• Mecanismo tecnico: cuando un atacante envia un valor de packet_length de 0xffffffff, la operacion aritmetica de 32 bits que calcula el tamano del buffer da la vuelta (overflow) y produce un numero muy pequeno. libssh2 reserva entonces un buffer dimensionado para ese numero diminuto e incorrecto, pero el codigo posterior escribe el paquete completo, de tamano real mucho mayor, en ese buffer insuficiente. El resultado es una escritura fuera de los limites del heap, el patron clasico que habilita la ejecucion de codigo arbitrario.
• CVSS 9.2: sin autenticacion requerida, sin interaccion adicional del usuario tras iniciar la conexion SSH, vector de ataque de red.
• Versiones afectadas: todas las versiones de libssh2 hasta la 1.11.1 inclusive. El parche se fusiono en el repositorio principal el 12 de junio mediante el pull request #2052, pero el proyecto todavia no ha publicado una version etiquetada que lo incluya.
• Alcance del ecosistema afectado: libssh2 esta integrado en curl, Git, PHP, agentes de backup, actualizadores de firmware y un largo listado de dispositivos de red embebidos. Cualquier aplicacion que enlace la libreria y se conecte a un endpoint SSH no completamente confiable es un objetivo potencial.
• El PoC es parcial, no un exploit listo para usar: el archivo de codigo publicado en GitHub contiene un scaffold de activacion SSH verificado localmente y un harness de RCE local controlado, no un exploit remoto llave en mano. Conseguir ejecucion de codigo fiable contra una aplicacion real depende del binario objetivo, el comportamiento del allocator de memoria, las mitigaciones del sistema y como esa aplicacion concreta integra libssh2.
• Sin explotacion activa confirmada: a fecha de publicacion, la calificacion de explotacion de CISA para este CVE sigue marcada como ninguna, y no se ha reportado uso en ataques reales. Sin embargo, la disponibilidad publica de un exploit funcional reduce significativamente la barrera tecnica.
• Precedente directo en la misma libreria: en 2019, libssh2 publico la version 1.8.1 para corregir un lote de nueve fallos liderado por CVE-2019-3855, un desbordamiento de entero casi identico en la misma funcion de lectura de transporte, que tambien permitia a un servidor malicioso ejecutar codigo en el cliente conectado. Siete anos despues, la misma clase de fallo reaparece en el mismo codigo.
• Segunda vulnerabilidad relacionada: en la misma divulgacion se publico tambien CVE-2026-55199 (CVSS 8.2), un fallo de denegacion de servicio en la misma fase de la conexion (el intercambio de claves previo a la autenticacion), donde el servidor puede anunciar una lista anomala de extensiones soportadas.

‍

Por que un fallo en el cliente SSH es mas peligroso de lo que parece

La mayoria de los equipos de seguridad concentran su atencion en proteger servidores SSH expuestos a internet. CVE-2026-55200 invierte esa logica y expone un punto ciego habitual en la gestion de riesgos:

1. El atacante no necesita comprometer el perimetro de la organizacion victima: necesita controlar un servidor SSH al que el cliente se conecte. Esto incluye servidores de terceros, repositorios Git externos, servicios de despliegue en la nube, proveedores que ofrecen acceso SSH, o cualquier servidor SSH legitimo que haya sido previamente comprometido por otro actor. Cualquier flujo de trabajo que conecte herramientas internas a servidores SSH fuera del control directo de la organizacion es una superficie de ataque potencial.
2. libssh2 esta presente en lugares que los equipos de seguridad no inventarian habitualmente. A diferencia de una aplicacion con un CVE propio que aparece claramente en los escaneres de dependencias, libssh2 suele llegar enlazado de forma estatica dentro de otras herramientas: agentes de backup, actualizadores de firmware, scripts de automatizacion, dispositivos de red. El equipo que opera esas herramientas frecuentemente no sabe que libssh2 esta dentro.
3. El enlazado estatico rompe el modelo habitual de parcheo por gestor de paquetes. Cuando una distribucion Linux actualiza su paquete libssh2, las copias enlazadas de forma estatica dentro de otros binarios no se actualizan automaticamente. Cada herramienta que empaqueta su propia copia de libssh2 requiere su propio ciclo de actualizacion independiente.
4. El mismo patron de fallo ya causo problemas hace siete anos. Que la misma clase de vulnerabilidad reaparezca en la misma funcion del codigo siete anos despues de CVE-2019-3855 sugiere que la correccion original no incluyo proteccion estructural contra esta clase de error, solo el caso especifico detectado entonces.

‍

Como funciona la cadena de explotacion de CVE-2026-55200

1. El cliente con libssh2 vulnerable inicia una conexion SSH hacia un servidor controlado por el atacante. Esto puede ocurrir de forma rutinaria: un script de despliegue que conecta a un repositorio Git externo, un agente de backup que sincroniza con un servidor remoto, o cualquier herramienta que use SSH para transferencia de ficheros o ejecucion remota.
2. El servidor malicioso envia un paquete SSH con un valor de packet_length manipulado, tipicamente 0xffffffff. Esto ocurre durante el handshake o en comunicaciones posteriores como mensajes SSH_MSG_CHANNEL_DATA.
3. La libreria del cliente calcula el tamano del buffer con aritmetica de 32 bits sin validar el limite superior. El valor manipulado provoca un desbordamiento de entero que produce un tamano de asignacion incorrectamente pequeno.
4. El codigo posterior escribe el paquete completo, de tamano real mucho mayor, en el buffer insuficiente. Esto sobrescribe regiones de memoria adyacentes con datos controlados por el atacante.
5. La memoria sobrescrita puede contener codigo controlado por el atacante que se ejecuta en el contexto del proceso cliente, entregando ejecucion de codigo arbitrario en el sistema que inicio la conexion SSH.

‍

Lecciones clave y checklist de mitigacion

Paso 1 - Inventariar donde esta libssh2 (la parte mas dificil):

• Identificar las herramientas y aplicaciones internas que usan libssh2, no solo mediante el gestor de paquetes del sistema operativo sino revisando dependencias de aplicaciones, agentes de backup, herramientas de automatizacion y dispositivos de red.
• Prestar especial atencion a binarios que enlazan libssh2 de forma estatica: estos no se actualizan con un simple apt upgrade o equivalente.
• Revisar curl, Git y PHP especificamente, las tres herramientas de mayor despliegue que integran la libreria.

Paso 2 - Aplicar el parche disponible mientras se espera la version oficial:

• El parche esta disponible en el commit 97acf3dfda80c91c3a8c9f2372546301d4a1a7a8 del repositorio principal de libssh2. Debian ya tiene una build reparada en testing.
• Las organizaciones que no pueden esperar a la version oficial etiquetada deben evaluar aplicar el backport del parche directamente o seguir el ejemplo de las distribuciones que ya lo estan haciendo.

Paso 3 - Restringir conexiones SSH salientes a servidores no confiables (mitigacion mientras se parchea):

• Bloquear o limitar severamente las conexiones SSH desde sistemas cliente hacia servidores SSH externos o no confiables.
• Implementar politicas de acceso de red estrictas que segmenten el acceso en funcion de la postura del dispositivo y la identidad del usuario, especialmente para herramientas de automatizacion y CI/CD que conectan a repositorios o servicios externos via SSH.

Paso 4 - Monitorizar conexiones salientes anomalas:

• Vigilar conexiones SSH salientes inusuales desde maquinas cliente tras establecer sesiones SSH con destinos no habituales.
• Revisar logs de aplicaciones que usan SSH en busca de tamanos de paquete anomalos o intentos de conexion repetidos hacia endpoints desconocidos.

‍

La ciberseguridad como prioridad estrategica

CVE-2026-55200 ilustra un problema estructural de la cadena de suministro de software de codigo abierto: una libreria critica de bajo nivel, enlazada de forma estatica en cientos de herramientas, con un patron de fallo que ya causo problemas hace siete anos y que ahora reaparece con un exploit publico antes de que exista una version oficial corregida. El reto no es tecnico unicamente, es de visibilidad: la mayoria de las organizaciones no tienen un inventario preciso de donde esta libssh2 dentro de su stack de software. Para los equipos de seguridad y desarrollo, la pregunta de hoy es directa: sabes que herramientas de tu organizacion conectan via SSH a servidores fuera de tu control directo, y cuantas de ellas tienen libssh2 enlazado de forma estatica sin que nadie lo recuerde?

‍

Apolo Cybersecurity: inventario de dependencias y mitigacion de CVE-2026-55200

En Apolo Cybersecurity ayudamos a organizaciones a evaluar su exposicion ante vulnerabilidades de cadena de suministro como CVE-2026-55200: inventario de herramientas y dispositivos que integran libssh2, identificacion de binarios con enlazado estatico que no se actualizan via gestor de paquetes, aplicacion de parches y mitigaciones de red mientras no existe version oficial, y revision de las politicas de conexion SSH saliente hacia servidores externos.

Si tu organizacion usa curl, Git, agentes de backup o herramientas de automatizacion que se conectan via SSH a servidores fuera de tu control directo, este es el momento de verificar si libssh2 esta entre sus dependencias.

‍