Une vulnérabilité dans libssh2 a suscité des alertes de sécurité concernant les systèmes et applications utilisant cette bibliothèque pour gérer les connexions SSH-2. La faille, identifiée sous le nom de CVE-2026-55200, concerne toutes les versions de libssh2 jusqu’à la 1.11.1 incluse et peut permettre à un attaquant distant de provoquer une corruption de mémoire en manipulant spécialement certains paquets SSH.
Il est important de préciser que cette vulnérabilité ne concerne pas le protocole SSH dans son ensemble ni tous les serveurs OpenSSH. La clé réside dans l’identification des produits, outils ou développements internes qui dépendent de libssh2, directement ou indirectement, et dans leur manière de traiter le trafic SSH. C’est dans ce contexte que la vulnérabilité peut devenir une menace réelle pour des serveurs, agents, scripts de déploiement, clients automatisés ou composants intégrés à d’autres applications.
Une faiblesse liée à la taille des paquets
L’origine du problème se trouve dans la fonction ssh2_transport_read(), située dans transport.c. Selon la description publiée par NVD et VulnCheck, libssh2 n’imposait pas de limite supérieure adéquate au champ packet_length lors du traitement des paquets SSH. Un paquet malicieusement manipulé pouvait entraîner une écriture hors limites sur la mémoire heap, impactant potentiellement la disponibilité, l’intégrité et la confidentialité du système.
Cette vulnérabilité est classée sous le CWE-680, une faiblesse combinant un dépassement d’entier et un dépassement de tampon. Ces erreurs sont particulièrement critiques car un problème apparemment limité à la validation des tailles peut évoluer en une corruption mémoire voire en une exécution de code à distance dans certaines conditions.
Les scores CVSS publiés diffèrent légèrement — VulnCheck la considère comme critique avec 9,2 en CVSS 4.0, tandis que le NVD lui attribue une note de 8,3 en CVSS 3.1 avec une gravité élevée. Quoi qu’il en soit, le message principal reste : il s’agit d’une vulnérabilité sérieuse dans une bibliothèque bas niveau, souvent utilisée en tant que dépendance dans des logiciels qui ne sont pas immédiatement identifiés comme vulnérables.
La correction a déjà été intégrée au code
Le correctif a été appliqué dans le commit 97acf3d du référentiel libssh2, lors de la mise en œuvre de l’amélioration « Vérifications complémentaires de la limite de longueur des paquets ». Ce patch ajoute des contrôles supplémentaires sur la taille du paquet et renvoie une erreur si packet_length dépasse la valeur de LIBSSH2_PACKET_MAXPAYLOAD, évitant ainsi un traitement qui pourrait conduire à une corruption mémoire.
Ce changement, bien que succinct, a un impact important. Avec seulement cinq lignes ajoutées et une modifiée, il permet de bloquer une voie potentielle vers la corruption mémoire, exploitée via des paquets conçus pour forcer des longueurs aberrantes. Ce type de correction souligne pourquoi la validation des limites constitue une pratique essentielle en sécurité, surtout dans des bibliothèques écrites en C.
Pour les administrateurs et équipes de sécurité, la priorité immédiate est de mettre à jour libssh2 vers une version intégrant cette correction ou d’appliquer le patch manuellement si une mise à jour packagée n’est pas encore disponible.
Il ne faut pas se limiter au simple paquet installé sur le système d’exploitation. Libssh2 peut être intégré dans des applications, appliances, outils de sauvegarde, scripts de déploiement, solutions DevOps ou produits commerciaux. Il est donc essentiel de vérifier la SBOM (software bill of materials), les analyses de dépendances, les bibliothèques dynamiques et les images de conteneurs afin d’identifier toutes les instances vulnérables.
Ce que les équipes techniques doivent vérifier
Les priorités concernent principalement les systèmes exposés à des connexions SSH depuis des réseaux non sécurisés ou ceux qui se connectent à des serveurs SSH hors du contrôle de l’organisation. Bien que le risque précis varie selon l’usage de libssh2, les environnements accessibles via Internet, les réseaux clients, les connexions automatisées ou les flux de gestion à distance doivent faire l’objet d’une attention particulière.
Sur Linux, la première étape consiste à vérifier si libssh2 est installé et quelle version est fournie par la distribution. Ensuite, il est crucial de confirmer si le fournisseur a déjà intégré le patch, car certaines distributions publient des backports de sécurité sans changer la version upstream. Se fier uniquement au numéro de version peut conduire à des erreurs d’évaluation.
Dans un conteneur, la revue doit porter sur l’image de base, celles des outils internes et les pipelines de construction logicielle utilisant des dépendances natives. Un ancien conteneur avec une version vulnérable de libssh2 peut passer inaperçu sans reconstruction avec des paquets à jour.
Il est également conseillé de renforcer la surveillance : des tentatives d’exploitation peuvent laisser des traces dans des erreurs de négociation, des coupures de connexion anormales, des crashes inattendus ou un trafic SSH avec des motifs inhabituels. Si cela ne remplace pas le patch, cette vigilance permet de détecter une activité suspecte durant la période d’exposition.
En résumé, la leçon essentielle, parfois oubliée, est que les vulnérabilités critiques ne résident pas toujours dans le service visible. Souvent, elles se cachent dans des bibliothèques partagées utilisées par d’autres programmes. Identifier où libssh2 apparaît dans la chaîne d’approvisionnement est aussi crucial que de procéder à une mise à jour sécurisée.
Questions fréquentes
Qu’est-ce que le CVE-2026-55200 ?
Il s’agit d’une vulnérabilité dans libssh2 permettant une écriture hors limites en mémoire lors du traitement de paquets SSH manipulés de façon malicieuse, avec un risque potentiel d’exécution de code à distance.
Est-ce que cela concerne tous les serveurs SSH ?
Non, uniquement ceux utilisant une version vulnérable de libssh2. Il ne faut pas confondre cette vulnérabilité avec tous les serveurs OpenSSH ou ceux disposant du port 22 ouvert par défaut.
Quelle est la première étape à effectuer ?
Mettre à jour libssh2 vers une version corrigée ou installer le paquet de la distribution comptant le patch du commit 97acf3d. Ensuite, examiner aussi les dépendances indirectes, les conteneurs et les produits intégrant cette bibliothèque.
Sources :
NVD.
VulnCheck.
GitHub – libssh2.
