Fallo crítico en libssh2 (CVE-2026-55200) podría permitir ejecución remota de código en clientes SSH

Un fallo crítico en la biblioteca cliente libssh2 ha vuelto a poner de manifiesto una vieja receta de la inseguridad: una comprobación ausente en el proceso de parsing de paquetes que permite a un servidor SSH malicioso provocar corrupción de memoria en el cliente, y potencialmente ejecución remota de código sin necesidad de credenciales ni interacción del usuario. La vulnerabilidad registrada como CVE-2026-55200 afecta a todas las versiones hasta la 1.11.1 y ha sido corregida en el árbol principal mediante el commit que añade la verificación faltante; puede consultarse el parche en el repositorio oficial (commit 97acf3d) y la pull request asociada (PR #2052).

El núcleo técnico del problema es sencillo pero peligroso: durante el handshake libssh2 lee un campo packet_length controlado por el servidor, acepta cualquier valor mayor que cero y realiza aritmética de 32 bits que puede desbordar, provocando que se asigne un buffer demasiado pequeño y luego se escriba sobre él. Esta clase de fallo, clasificada como CWE-680 (integer overflow to buffer overflow), es históricamente una vía fiable hacia la ejecución de código cuando las condiciones del binario y el allocator son favorables. No es teórico: libssh2 sufrió un error muy similar en 2019 (CVE-2019-3855), lo que subraya cómo la misma pieza de código puede volver a fallar años después si no se endurece la cadena de mantenimiento.

Lo que hace este caso especialmente delicado es la naturaleza cliente de la biblioteca y su penetración masiva: libssh2 se integra en clientes que inician conexiones SSH, incluyendo curl, Git, extensiones de PHP, agentes de backup y numerosos firmware y appliances. Muchas de esas integraciones son estáticas o empaquetadas en binarios propietarios, de modo que una actualización del paquete de la distribución no remediará todos los casos. Eso convierte a esta vulnerabilidad en un riesgo de cadena de suministro inversa: el vector no es un servidor comprometido que reciba conexiones, sino cualquier servidor SSH al que un cliente vulnerable se conecte.

Aunque ya existe un proof-of-concept público en un archivo de exploits en GitHub, su autor admite que las entradas se subieron sin notificación previa y que parte del material es incompleto; hoy ese POC funciona como andamiaje local y un harnero de RCE controlado pero no constituye un exploit remoto “plug-and-play” que funcione de forma fiable contra cualquier producto. Aun así, la publicación reduce la barrera para que atacantes invertidos trabajen en convertir el código local en un exploit remoto y, en presencia de clientes expuestos que resuelvan nombres mediante DNS manipulables o contacten servidores externos, el riesgo operativo aumenta rápidamente.

Las acciones prácticas para equipos de seguridad y desarrolladores deben priorizarse de inmediato. Primero, hacer inventario exhaustivo de dónde aparece libssh2, prestando especial atención a binarios estáticamente vinculados o paquetes de terceros que puedan haber incrustado la biblioteca; un paquete actualizado en tu distro no garantiza que todos los artefactos de tu entorno estén corregidos. Segundo, aplicar ya sea una versión que incluya el commit citado o un backport fiable proporcionado por el proveedor: algunos proyectos y distribuciones ya han publicado builds reparados, pero en otros casos será necesario recompilar software que embebe libssh2. Tercero, como mitigación temporal, restringir las conexiones SSH salientes a servidores de confianza, reforzar la verificación de claves de host y controlar el egress DNS para reducir la posibilidad de que clientes vulnerables contacten servidores arbitrarios.

Además de parchear, conviene ampliar la detección y la respuesta: monitorizar logs por caídas o crashes inexplicables en clientes SSH, analizar core dumps y obtener SBOMs para rastrear copias escondidas de libssh2 dentro de appliances y paquetes independientes. Herramientas de análisis de composición de software (SCA) y escáneres binarios que busquen símbolos o cadenas asociadas a libssh2 pueden acelerar el inventario; cuando no sea posible parchear de inmediato, considerar cambiar temporalmente a clientes alternativos o a implementaciones que no usen libssh2 para conexiones expuestas a entornos no confiables.

El panorama de riesgos se extiende más allá de esta falla puntual: hay dos vulnerabilidades adicionales que conviene remediar en el mismo conjunto de código, CVE-2026-55199 (denegación de servicio por bucle de CPU) y CVE-2025-15661 (SFTP heap over-read), que cuando se combinan con la reciente integer overflow intensifican la necesidad de una revisión amplia de todo el software que implementa clientes SSH. La lección operativa es clara: no subestimes el software cliente embebido en sistemas y appliances; su exposición a servidores remotos puede ser el eslabón débil de tu perímetro.

Para seguir la evolución del incidente y obtener fuentes primarias, consulta la entrada del CVE y el repositorio oficial de libssh2; esas páginas mostrarán cuándo se publica un release etiquetado que incorpore la corrección, lo cual facilita la comprobación de builds y backports. La corrección está en el árbol principal, pero hasta que se despliegue un release y los proveedores actualicen sus productos, la responsabilidad recae en los equipos de seguridad y de desarrollo para identificar, parchear y mitigar las instancias vulnerables en sus entornos.

Fuentes y referencias: el aviso oficial del CVE está disponible en el registro público (CVE-2026-55200) y el parche puede revisarse en el repositorio de libssh2 (commit 97acf3d, PR #2052).