¿Qué fallo crítico de libssh2 permite ejecutar código de forma remota?

Dos vulnerabilidades graves afectan a libssh2, una biblioteca SSH empleada para establecer conexiones SSH, transferir archivos mediante SFTP o SCP y automatizar tareas remotas. La más peligrosa, identificada como CVE-2026-55200, puede permitir que un atacante corrompa la memoria y ejecute código en el sistema vulnerable sin disponer de credenciales ni necesitar que un usuario pulse un enlace, abra un archivo o confirme nada.

El segundo fallo, CVE-2026-55199, permite que un servidor SSH manipulado atrape al cliente en un bucle que consume la CPU durante más de un minuto. Todas las versiones de libssh2 hasta la 1.11.1, incluida, están afectadas. El código corrector ya ha sido incorporado al repositorio del proyecto, pero a 23 de junio de 2026 todavía no se había publicado una nueva versión oficial que reuniera ambos parches. Ahí está el problema: la reparación existe, aunque no siempre ha llegado a los paquetes instalados.

La noticia tiene un alcance difícil de medir con exactitud. Libssh2 suele trabajar entre bambalinas, integrada en aplicaciones de transferencia de archivos, herramientas de copias de seguridad, programas de administración remota, dispositivos de red y sistemas conectados. No existe un recuento fiable de instalaciones vulnerables, pero su presencia en el ecosistema tecnológico es enorme. Podrían ser millones de sistemas. Y muchas organizaciones ni siquiera saben que la utilizan.

Una longitud sin freno abre la puerta al código remoto

La vulnerabilidad más grave se encuentra en la función encargada de leer el tráfico SSH. Al recibir un paquete, libssh2 consulta un campo denominado packet_length, que indica cuánto ocupa la información entrante. La biblioteca dispone de un límite interno, pero el código vulnerable no comprobaba correctamente que el valor recibido respetara ese máximo.

Un atacante puede enviar un paquete con una longitud desmesurada. El programa reserva o maneja la memoria esperando una cantidad de datos y termina escribiendo más allá del espacio disponible, como quien intenta meter un sofá por el buzón y decide continuar empujando. El resultado es una escritura fuera de límites en la memoria dinámica del proceso.

Ese tipo de error no provoca únicamente un cierre inesperado. Si la corrupción puede controlarse con suficiente precisión, permite alterar estructuras internas, desviar el flujo de ejecución y lograr que la máquina procese instrucciones elegidas por el atacante. Es lo que se conoce como ejecución remota de código: la posibilidad de convertir un paquete de red malicioso en órdenes ejecutadas dentro del sistema afectado.

El fallo ha recibido una puntuación de 9,2 sobre 10 en la versión 4 del sistema CVSS, utilizada para valorar la gravedad técnica de las vulnerabilidades. El impacto potencial sobre la confidencialidad, la integridad y la disponibilidad es alto. Dicho sin liturgia informática: un ataque logrado podría permitir robar datos, modificarlos, instalar programas o dejar el servicio fuera de combate.

El ataque no necesita contraseña ni clic

La explotación de CVE-2026-55200 puede realizarse a través de la red, sin privilegios previos, autenticación ni intervención del usuario. Aun así, esto no significa que cualquier ordenador con libssh2 pueda ser asaltado indiscriminadamente desde internet.

La aplicación vulnerable debe procesar paquetes SSH manipulados procedentes de un extremo controlado por el atacante. La exposición real depende de cómo esté integrada la biblioteca, de qué conexiones acepte o inicie el programa y de las defensas del sistema operativo. Algunas configuraciones estarán al alcance directo de una contraparte remota; otras requerirán que el software se conecte a una infraestructura hostil.

Tampoco existe, por el momento, constancia pública de que CVE-2026-55200 esté siendo explotada en ataques reales. No es una absolución, claro. La ubicación exacta del error y la corrección aplicada son públicas, de modo que investigadores y delincuentes pueden estudiar la diferencia entre ambas versiones. El reloj empezó a correr en cuanto el parche quedó visible.

El segundo fallo pone la CPU a girar en vacío

CVE-2026-55199 sigue un camino diferente. No busca escribir fuera de la memoria ni ejecutar código, sino agotar la capacidad de procesamiento de un cliente que se conecta a un servidor SSH malicioso.

Durante el intercambio inicial de claves, un servidor puede comunicar al cliente qué extensiones admite. El fallo permite declarar una cantidad absurda de ellas: hasta 4.294.967.295. Libssh2 intenta procesar esa cifra sin comprobar correctamente ciertos errores internos y entra en un bucle de trabajo intensivo que puede prolongarse durante más de 60 segundos.

Mientras dura el bucle, el proceso puede ocupar un núcleo de la CPU casi por completo. Una sola conexión causaría una interrupción temporal; varias conexiones simultáneas o repetidas podrían degradar una aplicación, bloquear trabajadores de un servicio o provocar un ataque de denegación de servicio más amplio.

Esta vulnerabilidad ha recibido una puntuación de 8,2 sobre 10. Su alcance es más limitado que el de la ejecución remota de código, pero resulta especialmente incómodo para sistemas que realizan conexiones automáticas: copias de seguridad, sincronización de archivos, recopilación de datos o procesos industriales que esperan comunicarse con servidores remotos sin supervisión humana.

La biblioteca que se esconde dentro de otras aplicaciones

Libssh2 es una biblioteca escrita en C que implementa el protocolo SSH2 desde el lado del cliente. Proporciona a otros programas funciones de autenticación, ejecución de comandos remotos y transferencia de archivos mediante SCP y SFTP. El usuario rara vez la abre o instala de manera consciente. Llega como dependencia de otra herramienta y se queda allí, discreta, como una tubería detrás de la pared.

Curl, por ejemplo, puede utilizar libssh2 como uno de sus motores para gestionar conexiones SCP y SFTP cuando ha sido compilado con ese soporte. También aparece en clientes de transferencia, aplicaciones de administración, dispositivos de almacenamiento, programas de copia de seguridad, equipos de red, productos para internet de las cosas y desarrollos internos que llevan años funcionando sin que nadie revise sus componentes.

Esa distribución indirecta explica por qué una vulnerabilidad en una biblioteca relativamente desconocida puede alcanzar un ecosistema gigantesco. El fallo no afecta solo a quienes descargaron libssh2 por separado; también puede encontrarse en copias integradas estáticamente dentro de programas, dispositivos o firmware. En esos casos, actualizar el paquete del sistema operativo puede no servir de nada. La aplicación conserva su propia copia vulnerable, congelada como un insecto en ámbar.

No es OpenSSH, aunque el nombre invite al despiste

Libssh2 no es OpenSSH ni debe confundirse con libssh, otro proyecto distinto. OpenSSH incluye herramientas ampliamente conocidas como ssh, scp, sftp y el servidor sshd. Libssh2, en cambio, es un componente que los desarrolladores incorporan a sus propias aplicaciones.

Actualizar OpenSSH no corrige automáticamente estas vulnerabilidades. Un servidor puede tener su paquete OpenSSH completamente al día y mantener, al mismo tiempo, una aplicación vulnerable que utiliza libssh2. El parecido de los nombres ayuda poco; la informática también tiene estas bromas privadas, aunque luego la factura llegue al departamento de seguridad.

Cómo saber si un sistema está realmente expuesto

La versión instalada por el gestor de paquetes es el primer dato que debe revisarse, pero no el último. Los responsables técnicos necesitan comprobar qué aplicaciones dependen de libssh2, si utilizan bibliotecas compartidas del sistema o incluyen una copia propia y qué conexiones SSH pueden recibir o iniciar.

Un inventario de componentes, una lista de materiales de software o SBOM y los escáneres de dependencias pueden revelar instalaciones que no aparecen a simple vista. También conviene revisar dispositivos cerrados y productos comerciales: routers, cabinas de almacenamiento, sistemas de copias y herramientas empresariales no siempre permiten sustituir la biblioteca manualmente. En esos casos, la actualización debe proceder del fabricante.

La ausencia de un paquete llamado libssh2 tampoco demuestra que el sistema esté limpio. Una aplicación compilada estáticamente puede contener la biblioteca sin registrarla como dependencia externa. Es la parte ingrata del asunto: lo que no figura en el inventario también se rompe.

El parche está escrito; falta que llegue a todas partes

Los mantenedores de libssh2 corrigieron CVE-2026-55200 mediante el cambio identificado como 97acf3d, que introduce comprobaciones adicionales sobre la longitud de los paquetes. CVE-2026-55199 quedó reparada con el cambio 1762685, destinado a validar correctamente los valores recibidos al procesar las extensiones SSH.

La última versión oficial disponible continúa siendo libssh2 1.11.1, publicada el 16 de octubre de 2024. Por eso no basta con buscar un número de versión superior: algunas distribuciones y fabricantes pueden aplicar los parches de seguridad sobre una versión antigua y conservar su numeración habitual. Lo que importa es confirmar que el paquete incluye las dos correcciones, preferiblemente mediante un aviso del proveedor.

Cuando exista una actualización oficial del sistema operativo, la aplicación o el dispositivo, esa debe ser la vía prioritaria. Compilar directamente el código más reciente o incorporar los cambios al proyecto puede resolver el problema, aunque exige pruebas para evitar incompatibilidades. Mientras no haya parche disponible, limitar las conexiones SSH a destinos de confianza, reducir la exposición de los servicios afectados y vigilar bloqueos, reinicios o picos anómalos de CPU disminuye el riesgo, pero no elimina la vulnerabilidad.

Una pieza pequeña con acceso a demasiadas puertas

El episodio vuelve a mostrar una debilidad conocida y todavía mal resuelta: gran parte de la infraestructura digital depende de pequeñas bibliotecas de código abierto que pasan años escondidas dentro de productos mucho más visibles. Todo funciona, nadie pregunta demasiado y la pieza parece insignificante. Hasta que un número sin límite atraviesa la memoria y esa pieza diminuta se convierte en la puerta principal.