OpenSSH sshole, falla da 8,1 punti permette di entrare nei server Alpine Linux senza password valida

📌 In sintesi

• OpenSSH presenta una vulnerabilità di autenticazione con gravità alta, CVSS 8,1. CVE-2026-123158 consente di accedere a determinati account Linux che dovrebbero rifiutare qualsiasi password.
• Il problema interessa i sistemi basati su musl senza autenticazione PAM. Alpine Linux e alcune configurazioni di OpenWrt, Buildroot e Yocto possono essere vulnerabili quando il login SSH tramite password rimane abilitato.
• La correzione è disponibile in OpenSSH 10.6p2 e nei pacchetti aggiornati di Alpine Linux. Le immagini cloud che utilizzano l’account predefinito alpine richiedono particolare attenzione per la possibilità di ottenere privilegi root.

Una vulnerabilità presente da circa dieci anni nella combinazione tra OpenSSH e la libreria musl consente di accedere a determinati account Linux configurati per non accettare password. La falla, identificata come CVE-2026-123158 e soprannominata sshole, viene divulgata il 5 novembre 2026 dal ricercatore Özgün Kültekin e riceve un punteggio CVSS 8,1, corrispondente a una gravità alta. Il problema riguarda soprattutto Alpine Linux, utilizzato nei server cloud, nei container e nelle infrastrutture leggere, ma può interessare anche altri sistemi che utilizzano la libreria musl senza PAM. L’attacco sfrutta un errore nella gestione degli hash delle password e permette, in condizioni specifiche, di trasformare un account che dovrebbe accettare esclusivamente chiavi SSH in un accesso utilizzabile attraverso l’autenticazione con password. OpenSSH ha distribuito la correzione nella versione 10.6p2, mentre Alpine Linux ha aggiornato i propri pacchetti.

OpenSSH sshole nasce da un errore nella verifica delle password

La vulnerabilità viene ricostruita nella ricerca originale di Özgün Kültekin, che individua un comportamento inatteso tra OpenSSH e la funzione crypt() della libreria musl. Nei sistemi Linux il file /etc/shadow conserva le informazioni necessarie alla verifica delle password degli account. Quando il relativo campo contiene un asterisco, significa che non è presente un hash utilizzabile per autenticarsi attraverso una password. Questa configurazione viene impiegata anche per account amministrativi o di servizio che devono essere accessibili esclusivamente attraverso chiavi crittografiche.

Il problema emerge perché musl restituisce il carattere * quando una determinata operazione crittografica fallisce. La libreria impone inoltre un limite di 256 byte alla lunghezza delle password elaborate attraverso uno specifico meccanismo di hashing. Quando riceve una password eccessivamente lunga, la funzione produce quindi un valore di errore identico al contenuto del campo che dovrebbe impedire l’autenticazione. OpenSSH può interpretare questa coincidenza come una password corretta, autorizzando un accesso che il sistema avrebbe dovuto rifiutare. Non viene compromesso l’algoritmo crittografico: il difetto nasce dall’interpretazione del valore restituito da una funzione.

Perché una correzione del 2016 ha introdotto il problema

L’origine della vulnerabilità risale al 2016, quando OpenSSH modifica il proprio comportamento per correggere CVE-2016-6210, una falla che permetteva di individuare gli account esistenti attraverso le differenze nei tempi di risposta del server. Per ridurre questa possibilità, il software introduce un controllo crittografico anche quando l’account non dispone di un hash utilizzabile. La modifica evita che il server risponda immediatamente in alcuni casi, rendendo più difficile distinguere gli utenti validi da quelli inesistenti.

La correzione produce però un effetto collaterale nelle installazioni basate su musl senza PAM. Quando OpenSSH utilizza un hash di riferimento proveniente da un altro account e riceve una password troppo lunga, il valore di errore generato dalla libreria può coincidere con l’asterisco utilizzato per bloccare l’accesso. Kültekin individua questa condizione dopo aver condotto circa 17.600 test di autenticazione, realizzati anche attraverso agenti di intelligenza artificiale e configurazioni differenti di OpenSSH, librerie C e moduli PAM. La scoperta dimostra come una correzione di sicurezza possa creare una nuova vulnerabilità quando due componenti software interpretano diversamente il significato di uno stesso valore.

Alpine Linux e cloud: quando la falla può consentire l’accesso root

La vulnerabilità non interessa indiscriminatamente tutti i server SSH. Perché lo sfruttamento sia possibile devono verificarsi contemporaneamente alcune condizioni: il sistema deve utilizzare musl, l’autenticazione PAM deve essere disabilitata, OpenSSH deve consentire l’accesso attraverso password e almeno un account deve avere il campo password impostato a *, mentre un altro account deve disporre di un hash valido. In queste configurazioni una password di lunghezza anomala può superare il controllo dell’account bloccato.

Il rischio assume particolare rilievo per Alpine Linux, il cui pacchetto OpenSSH non utilizza PAM per impostazione predefinita. Secondo il ricercatore, alcune immagini ufficiali Alpine distribuite nei marketplace AWS e Azure includono un account denominato alpine, destinato all’accesso attraverso chiavi SSH, che dispone di autorizzazioni doas senza richiesta di password. Un aggressore che riesce ad autenticarsi attraverso la vulnerabilità può quindi arrivare ai privilegi root, assumendo il controllo dell’istanza. Al contrario, Debian, Ubuntu e Fedora, che utilizzano glibc nelle configurazioni ordinarie, non risultano vulnerabili a questo specifico attacco. Il problema è distinto dalle precedenti vulnerabilità di OpenSSH, come regreSSHion, che consentiva l’esecuzione remota di codice attraverso una condizione di gara.

Leggi anche: Gravi vulnerabilità in OpenSSH: il protocollo sicuro sotto attacco

OpenSSH 10.6p2 corregge la vulnerabilità: gli aggiornamenti sono disponibili

La correzione di CVE-2026-123158 viene introdotta in OpenSSH 10.6p2, mentre Alpine Linux distribuisce versioni aggiornate dei pacchetti per le proprie release supportate e per diverse versioni precedenti. Gli amministratori devono verificare la versione effettiva del pacchetto installato, perché le distribuzioni possono integrare la patch senza modificare il numero principale della versione OpenSSH. L’aggiornamento deve inoltre essere seguito dal riavvio del servizio interessato, affinché il processo in esecuzione utilizzi il codice corretto.

Sulle installazioni Alpine, il comando di aggiornamento indicato dal ricercatore è:

apk upgrade openssh

Quando non è possibile aggiornare immediatamente, una mitigazione consiste nel disabilitare l’autenticazione SSH mediante password, impostando PasswordAuthentication no nella configurazione effettiva di sshd. È opportuno verificare anche i registri degli accessi SSH alla ricerca di autenticazioni riuscite tramite password verso account che dovrebbero accettare soltanto chiavi. Le indicazioni sono coerenti con l’avviso pubblicato da CERT-GARR il 6 novembre, che conferma la gravità della vulnerabilità e la necessità di aggiornare i sistemi interessati.

Continua con: Tor, 333 exit relay dirottati per intercettare SSH: scoperta Ebury

La sicurezza di OpenSSH dipende anche dalle librerie di sistema

Il caso sshole dimostra che la robustezza del protocollo SSH non elimina automaticamente i rischi introdotti dalle librerie e dalle configurazioni utilizzate per implementarlo. La vulnerabilità non richiede di violare la crittografia delle connessioni, ma sfrutta la gestione incoerente di un errore durante la verifica della password. Il fatto che il problema sia rimasto presente per circa dieci anni evidenzia la difficoltà di individuare difetti che emergono soltanto dall’interazione tra componenti specifici.

Per gli amministratori, la priorità è identificare le installazioni OpenSSH basate su musl, verificare l’utilizzo di PAM e disabilitare gli accessi con password quando non necessari. La disponibilità delle patch permette di risolvere il problema, ma i sistemi rimasti senza aggiornamenti possono continuare a esporre account che erano stati considerati protetti proprio perché privi di una password valida.