Il progetto OpenSSH ha pubblicato il 5 novembre 2026 la versione portabile 10.6p2, che corregge una falla di sshd sui sistemi Linux basati sulla libreria C musl con PAM disabilitato: un attaccante che raggiunge la porta SSH può entrare in un account senza conoscerne la password. Il caso più esposto è Alpine Linux, che ha corretto tutti i rami dalla 3.16 a edge. Alle 20:36 lo CSIRT Italia dell’Agenzia per la cybersicurezza nazionale (ACN) ha emesso l’allerta AL08/261105/CSIRT-ITA, con gravità «critica» e impatto sistemico «Alto» (71,53).
In breve
- Chi è colpito: server SSH su Linux con musl e senza PAM, come il pacchetto openssh-server di Alpine, con l’accesso via password attivo (è il valore predefinito di OpenSSH).
- Come: una password lunga tra 257 e 1.024 byte apre gli account che non hanno una password, se sulla macchina esiste almeno un altro account con hash
$5$o$6$. - Chi non è colpito: Debian, Ubuntu, Fedora e le altre distribuzioni con glibc, i sistemi con PAM attivo, i container senza sshd.
- Cosa fare: aggiornare openssh e riavviare sshd; in alternativa, disattivare l’accesso via password.
Un asterisco di troppo
Molti account senza password hanno in /etc/shadow un asterisco al posto dell’hash: è il caso degli utenti che entrano solo con chiave SSH e, su Alpine, di root nell’immagine base. Senza PAM, sshd verifica la password calcolandone l’hash con crypt() e confrontandolo con quello salvato; per gli account senza hash prende in prestito il “sale” di un altro utente. Secondo BleepingComputer questo comportamento risale a una correzione del 2016 per la falla CVE-2016-6210, che permetteva di indovinare i nomi utente misurando i tempi di risposta.
Il problema è che la crypt() di musl, quando riceve una chiave più lunga di 256 byte, segnala l’errore restituendo proprio un asterisco. Il confronto tra l’asterisco “calcolato” e quello salvato riesce e l’accesso viene concesso. Secondo Alpine basta una connessione e l’attacco riesce ogni volta.
Il team di OpenSSH scrive di considerare la causa esterna a sshd, ma ha scelto di aggirarla nel demone. La segnalazione è di Özgün Kültekin, della società Wakefield, che secondo BleepingComputer ha trovato il problema con agenti AI in circa 17.600 prove di autenticazione. Al momento della pubblicazione non è stato assegnato un identificativo CVE.
Attenzione: le immagini cloud ufficiali “tiny-cloud” di Alpine (qcow2, VHD e AMI) dalla 3.18.11 alla 3.24.3 hanno un utente alpine senza password e con doas senza password. Sono sicure al primo avvio, ma diventano attaccabili appena sulla macchina compare un hash $6$, per esempio se l’amministratore imposta una password per la console. In quel caso un attaccante può ottenere i privilegi di root. Le immagini configurate con cloud-init non sono interessate, perché cloud-init imposta PasswordAuthentication no.
Le versioni corrette, ramo per ramo
Alpine ha corretto anche i rami non più supportati, compresa la 3.21, uscita dal supporto il 1° novembre 2026.
| Ramo Alpine | Versione di openssh corretta | Point release con la correzione |
|---|---|---|
| edge | 10.6_p2-r0 | – |
| 3.24 | 10.3_p1-r2 | 3.24.4 |
| 3.23 | 10.2_p1-r1 | 3.23.8 |
| 3.22 | 10.0_p1-r11 | 3.22.8 |
| 3.21 (fuori supporto) | 9.9_p2-r1 | 3.21.10 |
| 3.20 | 9.7_p1-r6 | – |
| 3.19 | 9.6_p1-r3 | – |
| 3.18 | 9.3_p2-r4 | – |
| 3.17 | 9.1_p1-r7 | – |
| 3.16 | 9.0_p1-r6 | – |
BleepingComputer, riportando il ricercatore, cita tra i sistemi musl potenzialmente coinvolti anche OpenWrt, Buildroot e Yocto. Su OpenWrt, però, il server SSH incluso di serie è Dropbear, che non è OpenSSH: OpenSSH è un pacchetto da installare a parte. Chi lo ha installato farà bene a controllarne versione e configurazione.
Cosa fare
La procedura segue l’avviso ufficiale di Alpine e l’allerta di ACN, verificati il 5 novembre 2026. I comandi vanno eseguiti come root.
- Aggiornate e riavviate sshd. L’aggiornamento del pacchetto non sostituisce il demone già in esecuzione, quindi il riavvio è indispensabile:
apk upgrade -U -a rc-service sshd restart - Se non potete aggiornare subito, disattivate l’accesso via password. Prima controllate che l’accesso con chiave funzioni e tenete aperta la sessione corrente finché non ne avete provata una nuova. La sequenza indicata da Alpine crea un file in
sshd_config.d(letto dalla 3.19 in poi) e, consed, impostanoanche nel file principale, salvandone una copia in/etc/ssh/sshd_config.bak:mkdir -p /etc/ssh/sshd_config.d echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf sed -i.bak -e '1i PasswordAuthentication no' -e 's/^(s*PasswordAuthentication[^y#]*)yes/1no/i' /etc/ssh/sshd_config sshd -t && rc-service sshd restart - Riducete l’esposizione. ACN raccomanda anche
KbdInteractiveAuthentication nodove non serve e di limitare l’accesso SSH alle sole reti autorizzate. Per la configurazione di un server con sole chiavi, firewall e fail2ban trovate la nostra guida https://hardwarfare.it/guide-tecniche/guide-server-self-hosting/proteggere-server-linux-ssh-fail2ban-ufw/. - Controllate i log. In
/var/log/messagescercate le righe di sshd con «Accepted password» relative ad account che una password non ce l’hanno, comealpine, root o gli utenti con sola chiave. Se non potete escludere un accesso del genere, Alpine consiglia di considerare la macchina compromessa.
Verifica: il comando sshd -T | grep -i passwordauthentication mostra la configurazione effettivamente in uso. Se avete scelto la strada della mitigazione deve restituire passwordauthentication no.
La nostra lettura
La gravità è alta, ma il perimetro è stretto: servono musl, PAM spento, password attive e la giusta combinazione di account, e i server Debian e Ubuntu, con glibc, non sono toccati. Il rischio vero sta nelle macchine “dimenticate”: piccole VM Alpine nate da un’immagine cloud, a cui qualcuno ha aggiunto una password per la console. Il caso conferma una regola che vale ovunque: un server esposto su Internet non dovrebbe accettare password via SSH, solo chiavi. Gli altri avvisi della settimana sono in https://hardwarfare.it/category/sicurezza-informatica/vulnerabilita-patch/, le guide per chi gestisce un server in https://hardwarfare.it/category/guide-tecniche/guide-server-self-hosting/.
Fonti
Immagine di copertina: Wikimedia Foundation Servers-8055 02.jpg di Victorgrigas, licenza CC BY-SA 3.0, via Wikimedia Commons; elaborazione grafica HardWarfare.
Articolo redatto con il supporto di strumenti di intelligenza artificiale e verificato dalla redazione. Come usiamo l'AI · Come lavoriamo
