La vulnerabilidad CVE-2026-55200 afecta a libssh2 y abre la puerta a ejecución remota de código mediante paquetes SSH manipulados. El fallo, catalogado como crítico, se corrige con comprobaciones de límites añadidas en el código del proyecto.
La vulnerabilidad CVE-2026-55200 pone en jaque a libssh2, una biblioteca muy usada para añadir soporte de SSH-2 a aplicaciones y servicios. El problema afecta a libssh2 hasta la versión 1.11.1 incluida y permite que un atacante remoto provoque corrupción de memoria y llegue a ejecutar código en el sistema que procese tráfico SSH especialmente manipulado.
El origen del fallo está en la función ssh2_transport_read(), dentro de la capa de transporte. Al leer paquetes SSH, el código acepta un valor packet_length sin imponer un límite superior estricto. Ese detalle, que parece menor, tiene consecuencias serias: un valor desmesurado puede desencadenar una escritura fuera de límites en el heap, con el riesgo clásico de que el proceso se bloquee o, en el peor escenario, ejecute instrucciones controladas por el atacante.
La debilidad encaja en CWE-680, un desbordamiento de entero que acaba derivando en un desbordamiento de búfer. La entrada se mueve en cifras propias de un incidente grave: NVD publica una puntuación CVSS v3.1 de 9.8, mientras que VulnCheck refleja 9.2 en CVSS v4.0. Además, ya existe una prueba de concepto pública referenciada en GitHub, un factor que suele acelerar las pruebas por parte de atacantes y también la reacción de equipos defensivos.
La corrección llega en el commit 97acf3df del repositorio de libssh2. El parche refuerza las comprobaciones del tamaño de los paquetes y rechaza longitudes por encima de LIBSSH2_PACKET_MAXPAYLOAD, cerrando la puerta a ese procesamiento inseguro de datos.
Para reducir el riesgo, conviene actualizar libssh2 a una revisión que incluya el commit 97acf3df o aplicar el parche equivalente en la distribución correspondiente. También toca hacer inventario: libssh2 puede aparecer como dependencia indirecta, y el orden de prioridad debería favorecer a componentes que acepten tráfico SSH desde la red o que se conecten a servidores no confiables. En entornos donde sea posible, limitar el alcance de red ayuda a contener daños. Y en paralelo, resulta prudente reforzar registros y alertas ante patrones anómalos de negociación o tráfico SSH, porque este tipo de ataques suele dejar señales en la capa de transporte.
Un último matiz práctico: la mitigación real depende de la versión concreta que integre cada producto. No basta con ‘tener SSH’. Hay que confirmar que los paquetes del sistema operativo o de la cadena de suministro ya arrastran la corrección.
Más información
- nvd.nist.gov – CVE-2026-55200 Detail : https://nvd.nist.gov/vuln/detail/CVE-2026-55200
- VulnCheck – libssh2 – Out-of-Bounds Write via Unchecked packet_length in transport.c : https://www.vulncheck.com/advisories/libssh2-out-of-bounds-write-via-unchecked-packet-length-in-transport-c
- GitHub – transport.c: Additional boundary checks for packet length (#2052) · libssh2/libssh2@97acf3d : https://github.com/libssh2/libssh2/commit/97acf3dfda80c91c3a8c9f2372546301d4a1a7a8
Deja una respuesta