Alpine Linux, falla critica OpenSSH: login senza password

Il 5 novembre 2026 il team di sicurezza di Alpine Linux ha pubblicato un avviso su una falla di openssh-server, il programma che permette di collegarsi da remoto a un server con il protocollo SSH (Secure Shell). Chi raggiunge la porta SSH può autenticarsi senza conoscere la password: basta inviare una password lunga tra 257 e 1024 byte. Il problema è stato segnalato da Özgün Kültekin di Wakefield e corretto dal progetto OpenSSH. Al momento dell'avviso non era ancora stato assegnato un codice CVE.

La causa sta nell'incontro tra OpenSSH e musl, la libreria di sistema usata da Alpine. Senza PAM (il modulo che di solito gestisce i login), sshd verifica le password con la funzione crypt(). Quando la password supera i 256 byte, la versione di musl risponde con un asterisco come segnale di errore. Lo stesso asterisco è però scritto nel campo password degli account che una password non ce l'hanno. Il confronto quindi risulta valido e l'accesso viene concesso.

Chi è esposto

Servono tutte queste condizioni insieme:

• sshd senza PAM: il pacchetto openssh-server, oppure openssh-server-pam con UsePAM no;
• PasswordAuthentication yes, che è l'impostazione predefinita;
• almeno un account con * al posto della password, per esempio root nelle immagini di base recenti, utenti che entrano solo con chiave o utenti da servizi di directory;
• almeno un account locale con una password vera (hash $5$ o $6$).

Sono interessate le versioni da 3.16 a 3.24 e il ramo edge. Non sono esposti i sistemi con PasswordAuthentication no, quelli con openssh-server-pam e UsePAM yes, gli account bloccati con ! e i container senza sshd.

Attenzione alle immagini cloud ufficiali (tiny-cloud) dalla 3.18.11 alla 3.24.3: hanno un utente alpine senza password e con doas senza password, cioè la combinazione più pericolosa. Le macchine create da quelle immagini vanno aggiornate anche se sono state installate di recente.

Cosa significa per le aziende

Alpine Linux è leggero e diffuso più di quanto si pensi: lo usano molti container, firewall e appliance virtuali, piccoli server nel cloud e apparati di rete. Spesso è stato installato da un fornitore e nessuno in azienda sa che c'è. Un server raggiungibile da internet con questa falla è una porta aperta: chi entra può leggere dati, installare ransomware o usare la macchina per attaccare il resto della rete.

Cosa fare subito

1. Censite i sistemi Alpine con SSH attivo, partendo da quelli esposti su internet.
2. Aggiornate con apk upgrade -U -a e poi riavviate sshd con rc-service sshd restart: l'aggiornamento da solo non basta, il servizio in esecuzione resta quello vecchio. Le versioni corrette sono, per esempio, 10.3_p1-r2 su 3.24, 10.2_p1-r1 su 3.23, 10.0_p1-r11 su 3.22 e 9.9_p2-r1 su 3.21; sono uscite anche le versioni 3.21.10, 3.22.8, 3.23.8 e 3.24.4.
3. Se non potete aggiornare, impostate PasswordAuthentication no (dalla 3.19 basta un file in /etc/ssh/sshd_config.d/), riavviate sshd e controllate con sshd -T. Prima verificate che l'accesso con chiave funzioni e tenete aperta una sessione, per non restare chiusi fuori.
4. Controllate se qualcuno è già entrato: cercate in /var/log/messages le righe "Accepted password for" relative ad account senza password, e verificate l'uso di doas, utenti nuovi, file e chiavi SSH aggiunti. Se non potete escludere un accesso, considerate la macchina compromessa e reinstallatela.

Se non sapete quali sistemi Alpine avete in rete o volete un controllo sui server esposti, Garp Cyber Security può fare la verifica e l'aggiornamento insieme al vostro fornitore.