Il 23 giugno 2026 è stato pubblicato su GitHub un proof-of-concept funzionante per CVE-2026-55200, una vulnerabilità critica nel client SSH libssh2. Il bug permette a un server SSH malevolo di eseguire codice arbitrario su qualsiasi client che vi si connetta, senza bisogno di credenziali e prima ancora dell'autenticazione. La gravità è massima: CVSS 4.0 pari a 9.2. Ma il vero problema per i team di sicurezza non è la mancanza di patch—esiste dal 12 giugno nel repository mainline—bensì la natura invisibile delle copie statiche di libssh2, incorporate in centinaia di applicazioni e firmware che i gestori di pacchetti non rilevano.
- Il PoC pubblico sfrutta un overflow di interi nel campo packet_length di ssh2_transport_read(), causando allocazione di 19 byte e scrittura oltre confine di 4,29 miliardi di byte.
- La vulnerabilità colpisce tutte le versioni di libssh2 fino alla 1.11.1 inclusa; il fix esiste solo come commit nel mainline, senza release taggata ufficiale.
- L'attacco è client-side e pre-autenticazione: qualsiasi applicazione che usi libssh2 per connettersi a un server SSH ostile è esposta, inclusi curl, Git, PHP e tool di backup.
- CISA ha aggiornato il rating SSVC da "none" a "poc" il 24 giugno, confermando che la prova di exploitabilità è pubblica e riproducibile.
Il meccanismo: quando 0xffffffff diventa 19 byte
La falla risiede nella funzione ssh2_transport_read() del file transport.c, cuore del parser del livello trasporto SSH di libssh2. Secondo il record NVD, che classifica la vulnerabilità come CWE-680 (integer overflow to buffer overflow), la funzione non impone un limite superiore al campo packet_length prima di utilizzarlo in aritmetica a 32 bit.
Il repository GitHub "exploitarium" dell'utente bikini, pubblicato il 23 giugno, fornisce la dimostrazione aritmetica: con packet_length=0xffffffff, mac_len=0 e auth_len=16, l'espressione C vulnerabile produce una dimensione di allocazione di 19 byte. Il campo packet_length originale rimane però 0xffffffff, e la successiva scrittura nel buffer allocato supera di gran lunga i suoi confini, corrompendo l'heap adiacente.
La Hacker News descrive questo scenario come "a classic primitive for code execution". La corruzione di memoria avviene prima dell'autenticazione: il client elabora il pacchetto dannoso nel corso dell'handshake iniziale, quando ancora non ha presentato credenziali e non richiede interazione da parte dell'utente.
"A public proof-of-concept is now out for CVE-2026-55200, a critical flaw in libssh2 that lets a malicious or compromised SSH server trigger memory corruption on a connecting client, with possible code execution. No credentials, no user interaction." — Swati Khandelwal, The Hacker News
Il problema nascosto delle librerie statiche
libssh2 è una libreria client-side, non un server. Questa distinzione, sottolineata da The Hacker News, è fondamentale: l'attaccante non compromette un servizio in ascolto, ma induce un client a connettersi a un endpoint sotto suo controllo. La libreria è incorporata—spesso staticamente—in curl, Git, PHP, agenti di backup, tool di aggiornamento firmware e una lunga coda di appliance embedded.
Questa distribuzione frammentata crea una cecità operativa. Patchare il pacchetto libssh2 della distribuzione Linux non sanifica i binari che hanno incluso la propria copia della libreria al momento della compilazione. Un binario curl precompilato, un client Git distribuito come singolo eseguibile, un firmware IoT che non riceve più aggiornamenti: tutti questi possono contenere la versione vulnerabile senza che il gestore di pacchetti del sistema operativo lo segnali.
CyberSec Guru corrobora questa lettura, evidenziando come la static linking trasformi una singola vulnerabilità di libreria in un problema di supply chain diffuso e di difficile inventariazione. Nessuna delle fonti fornisce un elenco esaustivo dei software interessati; il brief non documenta criteri di ricerca sistematica per identificare le copie nascoste.
Timeline e stato della mitigazione
La vulnerabilità è stata segnalata dal ricercatore Tristan Madani. Il patch è stato integrato tramite pull request #2052 il 12 giugno 2026 con il commit 97acf3d, che aggiunge un controllo packet_length > LIBSSH2_PACKET_MAXPAYLOAD. Il record CVE è stato pubblicato da VulnCheck il 17 giugno. Il PoC è seguito il 23 giugno. Il 24 giugno, CISA ha modificato il rating SSVC nel NVD da "none" a "poc", riflettendo la disponibilità pubblica del codice di exploit.
Non esiste ancora una release libssh2 taggata che includa il fix. The Hacker News riporta esplicitamente: "There is no fixed libssh2 release yet. The patch sits in the mainline source, and a tagged release is still being prepared." Alcune distribuzioni stanno backportando la patch autonomamente: Debian ha già una build corretta in testing. NHS England Digital ha emesso un advisory che sollecita gli aggiornamenti, sebbene le fonti non chiariscano se questo si basi su intelligence specifica di minaccia o su valutazione preventiva.
Cosa fare adesso
I team di sicurezza possono agire su quattro fronti prioritari, coerentemente con quanto documentato dalle fonti:
- Inventariare tutte le copie statiche: identificare binari che incorporano libssh2, inclusi curl, Git, PHP e tool di backup, attraverso analisi delle dipendenze di compilazione e scansioni dei filesystem, poiché il gestore pacchetti non rileva le versioni bundle.
- Applicare backport dove disponibili: per le distribuzioni che hanno già integrato il patch, come Debian testing, verificare lo stato del proprio repository e pianificare l'aggiornamento; attendere la release taggata ufficiale per le configurazioni che richiedono binari upstream.
- Restringere le connessioni SSH outbound: limitare la capacità dei client di connettersi a server SSH non attendibili, dato che l'attacco richiede solo che il client inizi un handshake con un endpoint ostile.
- Monitorare il commit mainline: tracciare il repository ufficiale libssh2 per l'annuncio della release taggata, momento in cui i vendor di software con copie statiche potranno ricompilare e redistribuire.
Perché questa vulnerabilità cambia la postura di rischio
La combinazione di tre fattori—pre-autenticazione, assenza di credenziali e PoC pubblico—rimuove gli attriti tradizionali per l'attaccante. Non serve compromettere credenziali SSH, non serve ingegneria sociale verso l'utente finale, non serve nemmeno che l'utente esegua un'azione specifica. Basta che un'applicazione che usa libssh2 tenti una connessione a un server sotto controllo dell'avversario.
La static linking amplifica questa esposizione in modo non lineare. Dove una vulnerabilità in una libreria dinamica si risolve con un aggiornamento centralizzato, la stessa falla in una libreria staticamente inclusa si replica in silenzio attraverso il perimetro software di un'organizzazione, spesso in componenti che i team di sicurezza non associano immediatamente a una dipendenza SSH.
Il dossier non documenta exploit in-the-wild: il rating CISA è "poc", non "active". Tuttavia, la pubblicazione del codice di exploit abbassa significativamente la barriera per chi volesse sviluppare una variante funzionale. L'autore del repository GitHub riconosce che il PoC non è un exploit remoto pronto all'uso—richiede adattamenti target-specific—ma la struttura aritmetica e il server trigger Python forniscono un scaffold completo per la ricerca di exploit.
Domande frequenti
libssh2 è un server SSH? La vulnerabilità espone i server?
No. libssh2 è esplicitamente una libreria client-side. La vulnerabilità colpisce i client che usano la libreria per connettersi a server SSH, non il contrario. Un server SSH malevolo è il vettore di attacco, ma la vittima è il client che vi si connette.
Aggiornare libssh2 via apt/yum risolve il problema per tutto il sistema?
Le fonti indicano che no. Le copie staticamente collegate di libssh2, incorporate in binari di terze parti al momento della compilazione, non vengono aggiornate dalla gestione pacchetti della distribuzione. Ciascun vendor di software che include libssh2 deve ricompilare con la versione corretta.
Esiste una release ufficiale di libssh2 con il fix?
Non al 29 giugno 2026. Il commit 97acf3d è nel mainline del repository, ma The Hacker News conferma che "a tagged release is still being prepared". Alcune distribuzioni come Debian hanno backportato la patch indipendentemente.
Fonti
- https://thehackernews.com/2026/06/public-poc-released-for-critical.html
- https://thecybersecguru.com/news/cve-2026-55200-libssh2-remote-code-execution/
- https://cybersecuritynews.com/poc-exploit-libssh2-rce-vulnerability/
- https://nvd.nist.gov/vuln/detail/CVE-2026-55200
- https://github.com/bikini/exploitarium/tree/main/libssh2-cve-2026-55200-poc
- https://nvd.nist.gov/vuln
- https://nvd.nist.gov/vuln/search
- https://nvd.nist.gov/vuln/categories
- https://nvd.nist.gov/vuln/data-feeds
- https://nvd.nist.gov/vuln/vendor-comments
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.