Il 5 novembre 2026 il progetto OpenSSH ha rilasciato la versione 10.6p2 per correggere la CVE-2026-123158, un bypass dell'autenticazione a password soprannominato «*sshole». Non riguarda tutte le installazioni di OpenSSH, ma una combinazione precisa di condizioni che si incontra più spesso di quanto si pensi: sistemi Linux basati sulla libreria C musl (a partire da Alpine Linux), con OpenSSH compilato senza PAM e con l'autenticazione a password attiva. Chi rientra in questo perimetro ha poco tempo: le prime prove di sfruttamento sono comparse in meno di nove ore dalla pubblicazione del CVE.

Cosa è successo

La falla è stata segnalata da Özgün Kültekin (Wakefield). Il meccanismo è insolito, perché nasce dall'incontro di tre scelte fatte in anni diversi, ciascuna ragionevole da sola. Nel 2012 musl ha stabilito che crypt() accetti password fino a 256 byte e restituisca un asterisco (*) quando il calcolo dell'hash fallisce. Nel 2016 OpenSSH ha introdotto, per contrastare l'enumerazione degli utenti, un trattamento particolare per gli account privi di hash valido. Infine, da circa Alpine 3.16, il campo password di root è impostato a * proprio per forzare l'uso delle chiavi SSH.

Il risultato è che inviando una password più lunga di 256 caratteri a un account con * in /etc/shadow, la funzione di hash di musl fallisce restituendo *, sshd confronta * con * e considera valida l'autenticazione. Non servono exploit sofisticati né conoscenza della password: basta conoscere il nome di un account con login a password disabilitato, e root esiste sempre.

Il punteggio CVSS 3.1 riportato è 8.1 (alto), assegnato da MITRE come CNA; il NVD risultava ancora in attesa di analisi il 6 novembre. I maintainer di OpenSSH classificano la correzione come critica, pur sostenendo che la causa radice sia fuori da sshd: la patch aggiunge un controllo sulla lunghezza minima dell'hash (MIN_PASSWORD_HASH_LEN) invece di fidarsi del valore * restituito da musl.

Chi è colpito e chi no

Sono interessati i sistemi con OpenSSH precedente alla 10.6p2, libreria musl, assenza di PAM e PasswordAuthentication attivo. Questo corrisponde alla configurazione predefinita del pacchetto openssh-server di Alpine. Secondo gli approfondimenti pubblicati, vale la pena verificare anche OpenWrt, Buildroot, Yocto e molte immagini Docker costruite su base Alpine.

Non sono interessate le distribuzioni basate su glibc (Debian, Ubuntu, Fedora, RHEL e derivate), i sistemi che verificano le password tramite PAM, OpenBSD e implementazioni alternative come Dropbear, molto diffusa nell'embedded.

Un aggravante riguarda le immagini cloud ufficiali di Alpine create con tiny-cloud (dalla 3.18.11 alla 3.24.3): l'utente predefinito alpine può usare doas senza password. Se un attaccante entra come alpine, la strada verso root è immediata.

Sfruttamento: i dati sono ancora parziali

Le fonti non sono del tutto allineate, ed è bene dirlo. La società Previdian ha osservato otto tentativi, tutti da un singolo indirizzo IP in Giappone, e almeno uno ha ottenuto accesso root su un honeypot con Alpine reale; l'attaccante ha eseguito comandi di ricognizione (id, uname, hostname). Secondo l'analisi di SOCRadar, invece, al 6 novembre non risultavano attacchi reali confermati ma solo proof of concept pubblici. La CISA non ha inserito la vulnerabilità nel catalogo KEV. In pratica: lo sfruttamento attivo è documentato da un solo osservatore, su scala limitata, ma le condizioni sono così semplici che è prudente trattarlo come imminente. Attenzione anche ai PoC su GitHub non verificati: possono contenere malware.

Cosa significa per le aziende italiane

Il caso è interessante perché colpisce un livello che molte organizzazioni non inventariano: le immagini container e i sistemi embedded. Alpine è la base di un gran numero di immagini Docker usate in sviluppo, CI/CD e produzione, spesso da team che non sanno nemmeno quale libc stiano usando. Il rischio concreto per una PMI italiana non è il server Debian ben gestito dal fornitore, ma il container «temporaneo» con sshd attivo per comodità, o il router industriale basato su OpenWrt installato anni fa e mai più toccato.

C'è poi una questione di filiera. Per i soggetti NIS2 (D.Lgs. 138/2024) la gestione delle vulnerabilità e la sicurezza della catena di fornitura sono misure di sicurezza obbligatorie: se un fornitore gestisce per vostro conto sistemi Alpine esposti, conviene chiedergli per iscritto se hanno applicato la 10.6p2 e riavviato sshd. Un accesso root non autorizzato a un sistema che tratta dati personali può inoltre configurare una violazione ai sensi del GDPR, con obbligo di valutare la notifica al Garante entro 72 ore; per un incidente significativo NIS2 i termini verso CSIRT Italia sono ancora più stringenti (preallarme entro 24 ore).

L'errore tipico da evitare è considerare chiusa la pratica dopo apk upgrade: installare il pacchetto non riavvia il processo sshd in esecuzione, che resta vulnerabile finché non lo si riavvia.

Cosa fare subito

  • Individuare i sistemi basati su musl: ldd --version o la presenza di /etc/alpine-release; inventariare container, immagini, router e dispositivi embedded con OpenSSH.
  • Aggiornare OpenSSH alla 10.6p2 o ai pacchetti corretti di Alpine (ad esempio apk upgrade -U -a) e riavviare sshd (rc-service sshd restart).
  • Se non si può aggiornare subito, impostare PasswordAuthentication no in sshd_config (o in un file drop-in), validare con sshd -t e verificare con sshd -T | grep -i passwordauthentication, mantenendo aperta una sessione di servizio durante il test.
  • Cercare nei log (ad esempio /var/log/messages) voci «Accepted password for» riferite a root, alpine o utenti solo-chiave; controllare uso di doas, utenti creati di recente e file authorized_keys.
  • Considerare compromesso ogni sistema esposto per cui non si possa escludere un accesso, e ricostruirlo da un'immagine pulita ruotando segreti e chiavi.
  • Ridurre l'esposizione: SSH raggiungibile solo da VPN o da indirizzi autorizzati, senza password in nessun caso.