Una vulnerabilidad en libssh2 ha encendido las alertas de seguridad en sistemas y aplicaciones que incorporan esta biblioteca para gestionar conexiones SSH-2. El fallo, identificado como CVE-2026-55200, afecta a libssh2 hasta la versión 1.11.1 incluida y puede permitir a un atacante remoto provocar corrupción de memoria mediante paquetes SSH especialmente manipulados.
El problema no afecta a “SSH” en general ni implica automáticamente que todos los servidores con OpenSSH estén expuestos. La clave está en identificar qué productos, herramientas o desarrollos propios usan libssh2 como dependencia, directa o indirecta, y en qué contexto procesan tráfico SSH. Ahí es donde la vulnerabilidad puede convertirse en un riesgo real para servidores, agentes, herramientas de despliegue, clientes automatizados o componentes integrados en otras aplicaciones.
Un fallo en el tamaño de los paquetes
El origen del problema está en la función ssh2_transport_read(), dentro de transport.c. Según la descripción publicada en NVD y VulnCheck, libssh2 no imponía un límite superior adecuado al campo packet_length al procesar paquetes SSH. Un valor excesivamente grande podía derivar en una escritura fuera de límites en memoria heap, con impacto potencial en disponibilidad, integridad y confidencialidad.
La vulnerabilidad está clasificada como CWE-680, una debilidad que combina un desbordamiento de entero con un desbordamiento de búfer posterior. En la práctica, este tipo de errores son especialmente sensibles porque un fallo aparentemente limitado al cálculo o validación de tamaños puede acabar abriendo la puerta a corrupción de memoria y, en determinadas condiciones, a ejecución remota de código.
Las puntuaciones publicadas no son idénticas, algo habitual cuando distintas fuentes aplican métricas o revisiones en momentos diferentes. VulnCheck califica el fallo como crítico, con 9,2 en CVSS 4.0, mientras que NVD muestra una puntuación 8,3 en CVSS 3.1 tras su análisis, con severidad alta.
Más allá de la cifra exacta, el mensaje operativo es claro: se trata de una vulnerabilidad seria en una biblioteca de bajo nivel, usada como dependencia por software que puede no aparecer a primera vista en el inventario.
La corrección ya está en el código
La corrección se introdujo en el commit 97acf3d del repositorio de libssh2, asociado al cambio “Additional boundary checks for packet length”. El parche añade comprobaciones adicionales sobre la longitud del paquete y devuelve un error cuando packet_length supera LIBSSH2_PACKET_MAXPAYLOAD, en lugar de continuar con un procesamiento inseguro.
El cambio es pequeño en tamaño, pero relevante en impacto. Cinco líneas añadidas y una modificada bastan para cerrar una ruta de corrupción de memoria que podía activarse con paquetes preparados para forzar longitudes fuera de rango. Este tipo de parches recuerdan por qué las validaciones de límites siguen siendo una parte crítica de la seguridad en bibliotecas escritas en C.
Para administradores de sistemas y equipos de seguridad, la recomendación inmediata es actualizar libssh2 a una versión o paquete que incluya la corrección, o aplicar el parche equivalente cuando la distribución todavía no haya publicado una actualización empaquetada.
El trabajo no debería limitarse al paquete instalado en el sistema operativo. libssh2 puede estar embebida en aplicaciones, appliances, clientes de backup, herramientas de despliegue, integraciones DevOps o productos comerciales. Por eso conviene revisar SBOM, escáneres de dependencias, paquetes vinculados dinámicamente y versiones incluidas en contenedores.
Qué deberían revisar los equipos técnicos
La prioridad debe estar en los sistemas que aceptan tráfico SSH desde redes no confiables o que se conectan a servidores SSH que no están bajo control de la organización. Aunque el riesgo exacto depende de cómo cada aplicación use libssh2, los entornos expuestos a Internet, redes de clientes, conexiones automatizadas y flujos de administración remota merecen atención preferente.
En servidores Linux, el primer paso es comprobar si libssh2 está instalada y qué versión empaqueta la distribución. Después conviene validar si el proveedor ya ha incorporado el parche, porque algunas distribuciones aplican backports de seguridad sin cambiar necesariamente a la última versión “upstream”. Mirar solo el número de versión puede llevar a conclusiones incorrectas.
En contenedores, la revisión debe incluir imágenes base, imágenes de herramientas internas y pipelines que construyen software con dependencias nativas. Un contenedor antiguo con libssh2 vulnerable puede pasar desapercibido si no se reconstruye con paquetes actualizados.
También es recomendable reforzar la monitorización. Los intentos de explotación pueden dejar señales en errores de negociación, cierres anómalos de conexión, caídas inesperadas de procesos o tráfico SSH con patrones inusuales. No sustituye al parche, pero ayuda a detectar actividad sospechosa durante la ventana de exposición.
La lección de fondo es conocida, aunque a veces se olvida: las vulnerabilidades críticas no siempre están en el servicio visible. Muchas viven en bibliotecas compartidas que otros programas usan por debajo. En este caso, confirmar dónde aparece libssh2 en la cadena de suministro es tan importante como aplicar la actualización.
Preguntas frecuentes
¿Qué es CVE-2026-55200?
Es una vulnerabilidad en libssh2 que permite provocar una escritura fuera de límites en memoria al procesar paquetes SSH manipulados, con riesgo potencial de ejecución remota de código.
¿Afecta a todos los servidores SSH?
No necesariamente. Afecta a software que utiliza libssh2 vulnerable. No debe confundirse automáticamente con OpenSSH ni con cualquier servidor que tenga el puerto 22 abierto.
¿Qué medida hay que aplicar primero?
Actualizar libssh2 o instalar el paquete de la distribución que incluya el parche del commit 97acf3d. Después conviene revisar dependencias indirectas, contenedores y productos que puedan incorporar la biblioteca.
Fuentes:
NVD.
VulnCheck.
GitHub – libssh2.
