Falla OpenSSH sshole sfruttata poche ore dopo la pubblicazione

Un attaccante ha ottenuto accesso root su un honeypot Alpine Linux sfruttando una nuova falla di OpenSSH, meno di nove ore dopo la pubblicazione del CVE-2026-123158. L’indirizzo IP 89.116.89[.]18 ha inviato password sovradimensionate, ha bypassato l’autenticazione e ha lanciato comandi di ricognizione non interattivi come id, uname e hostname. Previdian ha contato otto tentativi, tutti dallo stesso IP geolocalizzato in Giappone, e uno è andato a segno sul loro sistema di test reale con OpenSSH su Alpine Linux^1,2.

Il bug, soprannominato sshole dal ricercatore Özgün Kültekin, consente l’accesso a account senza password su sistemi Linux che eseguono OpenSSH con la libreria C musl e con PAM disabilitato. La correzione è arrivata con OpenSSH 10.6p2, rilasciato il 5 novembre. Kültekin ha ricostruito l’origine nel modo in cui sshd gestisce gli account senza hash di password, un comportamento introdotto per mitigare la enumerazione degli utenti nel 2016, e nel modo in cui musl tratta password molto lunghe^1,2.

Alcuni account hanno nel campo password di /etc/shadow un asterisco al posto dell’hash. Dal 2016, se sshd trova un account senza hash utilizzabile, prende in prestito un sale da un altro account e prova comunque a calcolare l’hash. Musl rifiuta SHA-256 e SHA-512 oltre 256 byte e, se fallisce, restituisce un asterisco. Se arriva una password molto lunga, sshd riceve “”, lo confronta con “” in /etc/shadow e accetta il login. L’attacco funziona con password tra 257 e 1.024 byte e richiede almeno un account con “*” come hash. Non consente di saltare password valide su account con hash corretti^1,2.

Il team Alpine ha descritto l’impatto in termini netti: chi raggiunge la porta SSH può entrare senza conoscere alcuna password. Serve una sola connessione. Non richiede tentativi ripetuti. Kültekin ha elencato gli account tipici esposti: root, utenti di deploy a chiave, utenti LDAP e l’utente di default delle immagini Alpine per AWS e Azure. Ha anche raccontato i suoi test massivi e l’uso di agent swarm per esercitare il servizio. Solo il build di sshd con musl e senza PAM ha accettato login che avrebbe dovuto rifiutare¹.

Previdian ha inserito la falla nel proprio elenco di vulnerabilità sfruttate, ma CISA non l’ha ancora aggiunta al catalogo KEV. Secondo l’azienda, i tentativi sono iniziati a meno di nove ore dalla pubblicazione del CVE. Ryan Dewhurst attribuisce la velocità anche all’uso di strumenti di intelligenza artificiale da parte degli attaccanti e alla semplicità dell’exploit. La società ha osservato comandi di ricognizione eseguiti tramite sessioni SSH non interattive, dopo l’aggiramento dell’autenticazione con password troppo lunghe^1,2.

Il problema tocca sistemi con OpenSSH su musl e PAM disabilitato, inclusa la configurazione predefinita del server OpenSSH su Alpine Linux. Non interessa Dropbear, distribuzioni basate su glibc, sistemi non Linux, né host che verificano le password tramite PAM. Il punteggio CVSS comunicato è 8.1. Gli amministratori devono installare OpenSSH 10.6p2 o il pacchetto correttivo della distribuzione².

Kültekin ha coniato il nome sshole e ha pubblicato una spiegazione divulgativa, tutta in minuscolo. Ha ricostruito il filo che lega la patch del 2016 per CVE-2016-6210 al comportamento di crypt() in musl, fino all’errore di accettazione in sshd. La soluzione ufficiale è in OpenSSH 10.6p2, uscita il 5 novembre, e i tentativi di sfruttamento sono già in corso^1,2.

Safe Security avverte che un accesso non autorizzato via SSH può esporre credenziali di deploy, segreti applicativi e infrastrutture collegate, aprendo la strada a movimento laterale e interruzioni di servizio².