Alpine: una password lunga apre account senza password

Cosa è successo

Il ricercatore Ozgun Kultekin (Wakefield) ha scoperto che OpenSSH, il programma che permette di collegarsi da remoto ai server, su questi sistemi accetta una password sbagliata se è troppo lunga, ma solo per gli account senza password utilizzabile; gli account con una password valida non si aprono così. Per trovarla ha fatto fare a degli agenti di intelligenza artificiale circa 17.600 prove di accesso.

Gli account con accesso a password disattivato hanno un asterisco (*) al posto della password cifrata. La funzione crypt() della libreria musl restituisce anch'essa «*» quando fallisce, ad esempio con una password oltre i 256 byte. I due asterischi risultano uguali e il login riesce.

La causa di fondo risale al 2016, a una correzione di CVE-2016-6210 pensata contro l'enumerazione degli utenti. La falla ha avuto un identificativo ufficiale solo il 5 novembre 2026, lo stesso giorno della notizia: è CVE-2026-123158, con gravità 8,1 su 10 (alta) secondo il punteggio CVSS 3.1. OpenSSH l'ha corretta nella versione 10.6p2, uscita il 5 novembre 2026 insieme alla segnalazione.

Chi è colpito

Le condizioni che seguono vengono dall'avviso ufficiale di Alpine Linux, incrociato con la pagina del ricercatore per i dettagli che l'avviso non copre (gli altri sistemi musl). Servono tutte insieme:

1. sistema basato su musl senza PAM: è il caso di Alpine Linux (impostazione predefinita del suo pacchetto openssh-server). Secondo il ricercatore, in generale anche di OpenWrt, Buildroot e Yocto — ma su OpenWrt il server SSH preinstallato è Dropbear, non colpito: conta solo chi ci ha installato OpenSSH al suo posto;
2. accesso SSH con password attivo (non basta avere il demone acceso: serve che l'accesso con password non sia disabilitato);
3. almeno un account locale con il campo password a «*» (tipico degli account che usano solo chiavi, o LDAP, o root su alcune immagini Alpine — root resta comunque protetto dall'impostazione predefinita PermitRootLogin prohibit-password, a meno che non sia stata cambiata);
4. almeno un altro account locale con un hash di password valido ($5$ o $6$);
5. l'attaccante invia una password fra 257 e 1024 byte (il record CVE la descrive come «fra 256 e 1024»). Il record CVE classifica comunque la complessità dell'attacco come alta: non è detto che basti un solo tentativo.

Chi non è colpito, e le eccezioni da conoscere

Secondo l'avviso ufficiale di Alpine Linux, non sono colpiti: i sistemi con PAM attivo (openssh-server-pam con UsePAM yes — con UsePAM no resta invece esposto); i container Docker che non eseguono sshd; chi ha già PasswordAuthentication no; gli account bloccati (campo password «!», diverso da «*»); i sistemi senza alcun hash «$»; le immagini cloud con cloud-init che disattiva la password di default. Le immagini già aggiornate (3.21.10, 3.22.8, 3.23.8, 3.24.4 e successive) hanno già il pacchetto corretto.

Questo invece lo dicono il ricercatore e BleepingComputer, non l'avviso di Alpine (che non li nomina): i sistemi basati su glibc — Debian, Ubuntu, Fedora — non sono colpiti, perché la loro implementazione di crypt() non ha lo stesso comportamento in caso di errore.

Un'eccezione da conoscere: le immagini tiny-cloud di Alpine dalla 3.18.11 alla 3.24.3 hanno un utente «alpine» con doas senza password. Se sulla stessa macchina esiste un hash «$6$», diventano sfruttabili: sia Alpine sia il ricercatore dicono che l'accesso equivale a root.

Cosa fare

La correzione è in OpenSSH 10.6p2. Alpine ha pubblicato i numeri esatti dei pacchetti corretti per ogni ramo:

1. Aggiorna con apk upgrade -U -a (l'opzione -U aggiorna anche l'indice dei pacchetti, non serve lanciare apk update a parte).
2. Riavvia sshd con rc-service sshd restart: aggiornare il pacchetto non basta, il demone già in esecuzione resta vulnerabile finché non riparte.
3. Se non puoi aggiornare subito, disattiva l'accesso con password. Dalla versione 3.19 in poi crea il file /etc/ssh/sshd_config.d/00-no-passwords.conf (sshd legge solo i file che finiscono in .conf in quella cartella, e solo da questa versione in su) con dentro PasswordAuthentication no. Sulle versioni precedenti (3.16, 3.17, 3.18), quella cartella non viene letta: secondo l'avviso Alpine bisogna modificare direttamente /etc/ssh/sshd_config (facendone prima una copia, ad esempio cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak). In entrambi i casi verifica con sshd -t, riavvia sshd e controlla con sshd -T | grep -i passwordauthentication. Prima di farlo assicurati che il login con chiave funzioni e tieni aperta una sessione di prova.
4. Sulle immagini tiny-cloud (AWS, Azure) aggiorna o disattiva la password su ogni istanza già avviata: il pacchetto nuovo non si applica da solo a una macchina già accesa.
5. Per controllare accessi sospetti cerca Accepted password for in /var/log/messages per account con «*» in /etc/shadow (come «alpine», «root» o utenti solo-chiave), e controlla anche l'uso di doas, utenti creati di recente e chiavi autorizzate aggiunte. Se non puoi escludere un accesso, considera la macchina compromessa.

Da dove vengono questi dati

Fonti ufficiali lette per intero: il record CVE-2026-123158 (CVE Program/MITRE), l'avviso di sicurezza di Alpine Linux del 5 novembre 2026, le note di rilascio di OpenSSH 10.6p2 e il commit di correzione, e la pagina del ricercatore Ozgun Kultekin su sshhole.com. BleepingComputer (5 novembre 2026) resta citata come resoconto giornalistico, utile per il contesto ma non più l'unica fonte.

Non risulta da nessuna fonte: dati su attacchi reali già avvenuti, quanti sistemi nel mondo sono esposti, rilevanza specifica per utenti o aziende italiane.