Meno di nove ore dopo la pubblicazione della vulnerabilità CVE-2026-123158, Previdian ha rilevato il primo tentativo di sfruttamento. L’azienda ha confermato che uno degli attacchi è riuscito a ottenere l’accesso root in un honeypot con Alpine Linux e OpenSSH. La falla, battezzata SSHole, consente di aggirare l’autenticazione con password in alcune configurazioni Linux basate su musl.
Previdian ha registrato otto tentativi, tutti provenienti dall’indirizzo IP 89.116.89[.]18, geolocalizzato in Giappone e rilevato dallo stesso sensore. Secondo Ryan Dewhurst, fondatore e CEO dell’azienda, l’aggressore ha inviato password troppo lunghe e, dopo essere entrato in sessioni SSH non interattive, ha eseguito comandi di ricognizione come id, uname e hostname.
La vulnerabilità è identificata come CVE-2026-123158 e ha un punteggio CVSS di 8,1. Interessa OpenSSH sui sistemi Linux che utilizzano la libreria C musl e non verificano le password tramite PAM; Alpine Linux include questa combinazione nella configurazione predefinita del proprio server OpenSSH. Il problema è stato corretto in OpenSSH 10.6p2.
Una catena di condizioni consente di accedere senza password
SSHole non apre qualsiasi account protetto da password. Perché l’attacco funzioni, la macchina deve avere almeno un account il cui campo password contenga un asterisco (*), usato per gli account senza una password utilizzabile, e un altro account locale con un hash della password. Devono inoltre essere abilitati gli accessi tramite password e verificarsi le specifiche condizioni di compilazione e autenticazione.
L’aggressore, che non ha bisogno di credenziali né di chiavi SSH, invia una password compresa tra 257 e 1.024 byte. Nella configurazione interessata, il tentativo provoca un errore durante il calcolo dell’hash. La libreria musl restituisce quindi un asterisco, che corrisponde al valore memorizzato per l’account senza password. OpenSSH interpreta la corrispondenza come un’autenticazione valida.
Alpine spiega che è sufficiente che esista un utente locale con un hash che inizi con $5$ o $6$ perché gli account senza password possano essere esposti. Al contrario, gli account bloccati il cui campo inizia con ! non possono accedere né con password né con chiave e non rientrano tra gli obiettivi descritti nell’avviso.
L’accesso ottenuto mantiene i privilegi dell’account compromesso. Safe Security ha avvertito che le conseguenze dipendono da tali privilegi e che, oltre a consentire una connessione SSH non autorizzata, l’intrusione potrebbe esporre credenziali di distribuzione, segreti delle applicazioni e infrastrutture collegate, con possibilità di movimento laterale o interruzione dei servizi.
L’origine risale a una modifica di OpenSSH del 2016
Özgün Kültekin, ricercatore di Wakefield che ha scoperto la falla, ne ha individuato l’origine in una modifica di OpenSSH introdotta nel 2016 per correggere CVE-2016-6210, un problema che consentiva di dedurre quali nomi utente esistessero su un server. La modifica faceva sì che sshd calcolasse un hash anche quando l’account non aveva un hash utilizzabile, prendendo il salt da un altro account.
Il secondo elemento è in musl. Secondo l’analisi pubblicata da Alpine, la sua funzione crypt() restituisce * quando riceve una chiave di oltre 256 byte. Lo stesso carattere occupa il campo password degli account che non hanno una password configurata. Confrontando il risultato del calcolo con il valore memorizzato, il server può accettare l’accesso.
Help Net Security riferisce che Kültekin ha testato compilazioni di sshd con diverse combinazioni ed eseguito circa 17.600 tentativi di accesso insoliti. Solo la compilazione con musl e senza PAM ha accettato accessi che avrebbe dovuto rifiutare. Il ricercatore ha inoltre attribuito parte di questo lavoro ad agenti automatizzati: “oh did i say “i”? sorry. i had agent swarms. a lot of them. let’s not get into it”.
Alpine indica che il problema interessa le versioni della distribuzione dalla 3.16 alla 3.24 e la versione edge, purché siano soddisfatte le altre condizioni. L’account root compare con * nell’immagine di base da circa Alpine 3.16, ma la configurazione predefinita di OpenSSH, PermitRootLogin prohibit-password, impedisce l’accesso diretto a root tramite password. Il rischio può ripresentarsi se viene consentito l’accesso diretto o se un account accessibile può elevare i privilegi con doas.
Le immagini tiny-cloud possono trasformare l’accesso in root
L’avviso di Alpine individua un caso specifico nelle sue immagini ufficiali tiny-cloud: gli artefatti qcow2, VHD e AMI delle versioni dalla 3.18.11 alla 3.24.3 includono un utente alpine senza password e con accesso a doas senza password. Sono al sicuro al primo avvio, ma diventano vulnerabili quando sulla macchina è presente un hash $6$, ad esempio se un amministratore imposta una password per la console o i dati utente creano un account con hashed_passwd.
In questa situazione, un aggressore potrebbe accedere come alpine e usare doas per diventare root. Alpine chiarisce che le immagini create con le versioni 3.21.10, 3.22.8, 3.23.8, 3.24.4 e successive includono il pacchetto corretto. Le istanze già in esecuzione devono aggiornare OpenSSH o disattivare l’autenticazione tramite password.
La falla non interessa i sistemi basati su glibc, come Debian, Ubuntu e Fedora, né i sistemi che utilizzano PAM per verificare le password. Non interessa neppure Dropbear o i sistemi che non eseguono sshd nei propri container. Red Hat afferma che i suoi prodotti non sono interessati: le sue compilazioni di OpenSSH usano glibc e PAM per impostazione predefinita.
Previdian ha aggiunto SSHole al proprio elenco di vulnerabilità sfruttate. CISA non l’ha inclusa nel proprio catalogo KEV, secondo Help Net Security. Dewhurst ha sostenuto che gli aggressori stanno accelerando i tempi grazie all’intelligenza artificiale e ha descritto questa falla come particolarmente facile da sfruttare. Tuttavia, le osservazioni pubblicate da Previdian si limitano agli otto tentativi provenienti da un unico indirizzo.
Aggiornare non basta se sshd è ancora in esecuzione
La correzione è disponibile in OpenSSH 10.6p2. Alpine ha pubblicato pacchetti aggiornati per i propri rami e specifica che installare il pacchetto non sostituisce il processo sshd già in esecuzione: è necessario riavviare il servizio. Per i rami stabili, le versioni corrette di OpenSSH sono 10.3_p1-r2 in Alpine 3.24, 10.2_p1-r1 in 3.23, 10.0_p1-r11 in 3.22 e 9.9_p2-r1 in 3.21. Sono disponibili pacchetti anche per i rami precedenti: 9.7_p1-r6 in 3.20, 9.6_p1-r3 in 3.19, 9.3_p2-r4 in 3.18, 9.1_p1-r7 in 3.17 e 9.0_p1-r6 in 3.16. Il ramo edge include 10.6_p2-r0.
Alpine consiglia di aggiornare OpenSSH e riavviare il servizio. Se non è ancora possibile applicare l’aggiornamento, raccomanda di disattivare l’autenticazione tramite password nella configurazione SSH e riavviare sshd. Il team di OpenSSH, tramite Damien Miller, ha chiesto a chi usa Linux con musl e senza PAM di disabilitare immediatamente l’autenticazione tramite password o SSH su questi sistemi.
Per cercare indizi di accesso, Alpine consiglia di controllare /var/log/messages alla ricerca di righe di sshd contenenti il testo “Accepted password for” e associate ad account che non dovrebbero accettare password, come alpine, root o utenti che dovrebbero accedere solo con una chiave. Chiede inoltre di controllare l’uso di doas, gli account creati di recente, i file e le chiavi autorizzate. Se non è possibile escludere un accesso, consiglia di considerare la macchina compromessa.
L’analisi di Help Net Security menziona proof of concept pubblicate su GitHub, ma Previdian avverte che non sono verificate e potrebbero contenere malware. Nel frattempo, Alpine ha pubblicato pacchetti corretti anche per le versioni meno recenti: il ramo 3.21 ha raggiunto la fine del supporto il 1° novembre 2026, ma il team afferma di aver pubblicato correzioni per ogni versione fino alla 3.16.
Fonti: The Hacker News, Help Net Security, teapawt, Alpine Linux, Red Hat Customer Portal
