Vulnerabilità critica in libssh2: milioni di dispositivi a rischio esecuzione di codice remoto

Una libreria spesso invisibile agli utenti finali può trasformarsi in un punto di ingresso ideale per attacchi su larga scala. È il caso di libssh2, componente open source utilizzato da anni per implementare funzionalità SSH, SCP e SFTP in una quantità enorme di software. Due vulnerabilità appena rese pubbliche, identificate come CVE-2026-55200 e CVE-2026-55199, riportano l’attenzione su un problema noto agli specialisti della sicurezza: quando una dipendenza è integrata in migliaia di prodotti differenti, una singola falla può propagare il rischio ben oltre il progetto originale.

La storia di libssh2 inizia nei primi anni 2000 come implementazione leggera del protocollo SSH destinata agli sviluppatori che necessitano di accesso remoto sicuro, trasferimento file e autenticazione crittografica senza dover integrare un client SSH completo. Nel tempo la libreria è diventata una dipendenza comune in strumenti di amministrazione remota, software di backup, appliance di rete, dispositivi IoT e applicazioni multipiattaforma.

Anche progetti come curl la utilizzano per supportare protocolli quali SCP e SFTP. Proprio questa diffusione rende particolarmente rilevanti le nuove vulnerabilità, soprattutto considerando che molte distribuzioni Linux e numerosi firmware incorporano ancora versioni precedenti alla 1.11.1.

libssh2: una vulnerabilità critica apre la strada all’esecuzione di codice remoto

La falla più grave è tracciata come CVE-2026-55200 e ha ricevuto un punteggio CVSS di 9,2 su 10. Il problema risiede nella funzione ssh2_transport_read(), responsabile dell’elaborazione dei pacchetti SSH ricevuti attraverso la rete.

In teoria libssh2 definisce limiti interni per la dimensione massima dei pacchetti. Nella pratica, però, il controllo non è correttamente applicato a un parametro fondamentale: il campo packet_length. Un server malevolo può quindi dichiarare una dimensione artificiosamente elevata e indurre il client a scrivere dati oltre i limiti del buffer allocato in memoria.

Si tratta di un classico caso di out-of-bounds write: quando la scrittura supera i confini previsti, la memoria adiacente può essere corrotta. A seconda dell’architettura, delle protezioni attive e della disposizione dell’heap, l’attaccante potrebbe provocare un crash oppure arrivare a eseguire codice arbitrario sul sistema bersaglio. I bollettini di sicurezza sin qui pubblicati descrivono esplicitamente uno scenario di esecuzione remota di codice ottenibile tramite pacchetti SSH appositamente costruiti.

Un elemento che preoccupa particolarmente gli analisti è la semplicità dell’attacco. Non servono credenziali valide, privilegi preesistenti o interazione dell’utente: è sufficiente che un’applicazione vulnerabile utilizzi libssh2 e comunichi con un endpoint controllato dall’attaccante oppure esponga funzionalità SSH raggiungibili dalla rete.

La seconda falla sfrutta il processo di autenticazione SSH

La vulnerabilità CVE-2026-55199 presenta una gravità inferiore ma resta comunque significativa, con un punteggio di 8,2. In questo caso l’obiettivo non è l’esecuzione di codice ma il blocco delle risorse elaborative del client.

Il difetto interessa il gestore del messaggio SSH_MSG_EXT_INFO, utilizzato durante le prime fasi della negoziazione SSH. Durante lo scambio iniziale delle chiavi crittografiche, il server può comunicare un elenco di estensioni supportate: un server ostile può dichiarare un numero assurdo di estensioni, inducendo il client a entrare in un ciclo di elaborazione estremamente oneroso dal punto di vista computazionale.

Il processo continua a consumare CPU per oltre un minuto senza svolgere alcuna attività utile. Sulle workstation moderne il fenomeno può sembrare limitato; su dispositivi embedded, appliance industriali o apparati IoT con risorse ridotte, invece, può provocare rallentamenti evidenti e interrompere operazioni critiche.

Il modello di attacco è in questo caso differente rispetto alla vulnerabilità precedente: il client deve collegarsi a un server SSH controllato dall’aggressore. Non si tratta quindi di un’esposizione passiva, ma di uno scenario comunque realistico in ambienti che effettuano connessioni automatiche verso server esterni.

Correzioni disponibili ma distribuzione ancora incompleta

I manutentori del progetto hanno già corretto entrambe le vulnerabilità attraverso commit pubblicati nel repository ufficiale.

Al momento della divulgazione non risultava ancora disponibile una nuova release stabile della libreria contenente ufficialmente tutte le correzioni. Di conseguenza molte distribuzioni Linux e numerosi fornitori software stanno procedendo con operazioni di backporting, integrando le patch direttamente nei pacchetti esistenti.

La priorità consiste nell’individuare tutte le installazioni che utilizzano libssh2 fino alla versione 1.11.1 inclusa. Una mappatura accurata delle dipendenze software permette di capire dove intervenire prima. Gli ambienti che effettuano connessioni SSH automatiche verso server esterni meritano particolare attenzione, soprattutto se gestiscono trasferimenti SFTP o SCP non strettamente controllati.

In attesa dell’aggiornamento completo, alcune misure possono limitare la superficie di attacco: ridurre le connessioni verso host non verificati, filtrare il traffico SSH attraverso regole di rete restrittive, monitorare anomalie nell’utilizzo della CPU e verificare eventuali crash anomali delle applicazioni che impiegano libssh2.