Per anni la sicurezza di SSH è stata pensata soprattutto come protezione del server: l'attaccante stava là fuori, il client si fidava. La CVE-2026-55200 ribalta questa prospettiva. La falla, individuata nella libreria libssh2 e divulgata con un punteggio CVSS 4.0 di 9.2, consente a un server SSH malevolo o compromesso di corrompere la memoria del client che vi si connette, con la possibilità di arrivare all'esecuzione di codice. Nessuna credenziale, nessuna interazione dell'utente: basta che il client tenti la connessione.

Dove si annida il difetto

Il problema vive in ssh2_transport_read(), la funzione di transport.c che analizza i pacchetti SSH in arrivo durante l'handshake iniziale. La funzione non convalida correttamente il campo packet_length dei pacchetti ricevuti: mancando un controllo sul limite massimo, un server ostile può dichiarare un valore di lunghezza enorme, provocando un overflow di interi a 32 bit. Il risultato è un'allocazione di memoria troppo piccola, seguita da operazioni di scrittura che la sforano, dando luogo a una scrittura fuori dai limiti (out-of-bounds write) sull'heap. È esattamente la primitiva da cui partono molte catene di sfruttamento verso l'esecuzione di codice.

Sono interessate tutte le versioni fino alla 1.11.1 inclusa. I manutentori hanno pubblicato la 1.12.0, che reintroduce il controllo sui limiti mancante.

Perché il raggio d'azione è così ampio

libssh2 non è un programma che si avvia e si aggiorna da solo: è una libreria incorporata in una quantità sorprendente di software. Compare in curl, in Git, in PHP, negli agent di backup, negli aggiornatori di firmware e in una lunga coda di apparati e dispositivi embedded. La conseguenza pratica è che la stessa falla può presentarsi in decine di programmi diversi, ciascuno con il proprio ciclo di rilascio. Il vero lavoro di bonifica non è installare un aggiornamento, ma trovare tutte le copie della libreria — soprattutto quelle collegate staticamente dentro i binari, dove un semplice aggiornamento di sistema non basta a sostituirle.

Un PoC già in circolazione

Ad aggravare il quadro, è stato pubblicato un proof-of-concept: un archivio di codice dimostrativo contenente un'impalcatura per innescare il bug tramite un server SSH controllato e un harness di esecuzione di codice verificato localmente. Non si tratta di un exploit remoto "chiavi in mano", ma la disponibilità pubblica del codice abbassa la barriera d'ingresso e accorcia, come sempre, la distanza tra divulgazione e attacchi concreti.

Cosa fare

La prima azione è aggiornare libssh2 alla 1.12.0 ovunque sia gestibile direttamente. Subito dopo viene la parte più impegnativa: mappare le dipendenze, individuando quali applicazioni e quali immagini di container includono la libreria, comprese le versioni collegate staticamente che sfuggono ai normali aggiornamenti del sistema operativo. Sul piano operativo conviene diffidare delle connessioni SSH uscenti verso server non fidati — script automatici, processi di clonazione di repository, job di backup che dialogano con host esterni — perché in questo scenario è il client a essere esposto. Chi distribuisce software che incorpora libssh2 dovrebbe rilasciare quanto prima build aggiornate ai propri utenti.