Una libreria che la maggior parte degli utenti non vedrà mai può diventare la porta d’ingresso perfetta per attacchi su vasta scala. È esattamente quello che succede con libssh2, il componente open source che da anni gestisce funzioni SSH, SCP e SFTP dentro una quantità impressionante di software. Due nuove vulnerabilità appena rese pubbliche, catalogate come CVE-2026-55200 e CVE-2026-55199, riportano sotto i riflettori un problema che chi si occupa di sicurezza conosce fin troppo bene. Quando una dipendenza finisce dentro migliaia di prodotti diversi, basta una singola falla per far viaggiare il rischio molto oltre il progetto originale.
La storia di libssh2 parte agli inizi degli anni 2000, pensata come implementazione leggera del protocollo SSH per chi serviva accesso remoto sicuro, trasferimento file e autenticazione crittografica senza dover montare un client SSH completo. Col tempo è diventata un mattone ricorrente in strumenti di amministrazione remota, software di backup, appliance di rete, dispositivi IoT e applicazioni multipiattaforma. Persino progetti come curl la sfruttano per gestire protocolli come SCP e SFTP. Ed è proprio questa diffusione a rendere pesanti le nuove falle, considerando che parecchie distribuzioni Linux e tanti firmware continuano a incorporare versioni precedenti alla 1.11.1.
Una falla critica che spalanca la porta all’esecuzione di codice remoto
La più seria delle due è la CVE-2026-55200, con un punteggio CVSS di 9,2 su 10. Il guaio sta nella funzione ssh2transportread(), quella che si occupa di elaborare i pacchetti SSH che arrivano dalla rete. Sulla carta libssh2 fissa dei limiti interni per la dimensione massima dei pacchetti. Nella pratica, però, quel controllo non viene applicato come dovrebbe a un parametro chiave, il campo packetlength. Un server malevolo può così dichiarare una dimensione gonfiata ad arte e spingere il client a scrivere dati oltre i confini del buffer riservato in memoria.
Siamo davanti a un classico caso di out-of-bounds write. Quando la scrittura sfora i limiti previsti, la memoria vicina rischia di corrompersi. A seconda dell’architettura, delle protezioni attive e di come è organizzato l’heap, l’attaccante può provocare un crash oppure arrivare a far girare codice arbitrario sul sistema bersaglio. I bollettini pubblicati finora parlano apertamente di uno scenario di esecuzione remota di codice ottenibile con pacchetti SSH costruiti su misura.
Quello che fa storcere il naso agli analisti è la semplicità dell’attacco. Niente credenziali valide, niente privilegi già acquisiti, nessuna interazione richiesta all’utente. Basta che un’applicazione vulnerabile usi libssh2 e dialoghi con un endpoint controllato dall’attaccante, oppure che esponga funzioni SSH raggiungibili via rete.
La seconda falla colpisce il processo di autenticazione
La CVE-2026-55199 ha una gravità più contenuta ma resta comunque pesante, con un punteggio di 8,2. Qui l’obiettivo non è eseguire codice, ma mandare in stallo le risorse di calcolo del client. Il difetto riguarda il gestore del messaggio SSHMSGEXTINFO, usato nelle prime fasi della negoziazione SSH. Durante lo scambio iniziale delle chiavi, il server può comunicare l’elenco delle estensioni supportate. Un server ostile può dichiararne un numero assurdo, costringendo il client a entrare in un ciclo di elaborazione pesantissimo dal punto di vista computazionale.
Il processo continua a divorare CPU per oltre un minuto senza combinare nulla di utile. Sulle workstation moderne il fenomeno può sembrare poca cosa. Su dispositivi embedded, appliance industriali o apparati IoT con risorse limitate, invece, può tradursi in rallentamenti evidenti e bloccare operazioni critiche. Il modello di attacco qui cambia rispetto alla falla precedente, perché il client deve collegarsi a un server SSH controllato dall’aggressore. Non è un’esposizione passiva, ma resta uno scenario realistico negli ambienti che fanno connessioni automatiche verso server esterni.
Le correzioni ci sono, ma la distribuzione arranca
I manutentori del progetto hanno già sistemato entrambe le vulnerabilità con commit pubblicati nel repository ufficiale. Al momento della divulgazione, però, non risultava ancora pronta una nuova release stabile della libreria con tutte le correzioni ufficiali. Per questo molte distribuzioni Linux e diversi fornitori stanno procedendo con il backporting, integrando le patch direttamente nei pacchetti già esistenti.
La priorità è individuare tutte le installazioni che usano libssh2 fino alla versione 1.11.1 inclusa. Una mappatura precisa delle dipendenze software aiuta a capire dove mettere mano per primi. Gli ambienti che fanno connessioni SSH automatiche verso server esterni meritano un occhio di riguardo, soprattutto se gestiscono trasferimenti SFTP o SCP non rigidamente controllati.
Nell’attesa dell’aggiornamento completo, qualche accorgimento può ridurre la superficie di attacco. Limitare le connessioni verso host non verificati, filtrare il traffico SSH con regole di rete più restrittive, tenere d’occhio i picchi anomali di CPU e controllare eventuali crash strani nelle applicazioni che si appoggiano a libssh2.
