OpenSSH: l’autenticazione con password può essere aggirata sui sistemi Linux con musl senza PAM, avverte il CERT-FR

Monitoraggio cyber di Top-Secured: analisi indipendente basata sulle fonti citate più in basso. Top-Secured non è affiliato alle aziende menzionate e non le chiederà mai le sue credenziali bancarie né le sue password.

Il 5 novembre 2026 OpenSSH ha rilasciato la versione 10.6p2 per chiudere un aggiramento dell’autenticazione con password in sshd che riguarda i sistemi Linux basati sulla libreria C musl senza PAM, come molti server e container Alpine. Lo stesso giorno il CERT-FR ha emesso un’allerta, giudicando lo sfruttamento banale quando le condizioni sono soddisfatte.

Cosa è successo

Il 5 novembre 2026 il progetto OpenSSH ha pubblicato la versione portable OpenSSH 10.6p2, che corregge un aggiramento dell’autenticazione con password sfruttabile tramite sshd. Secondo le note di rilascio, la causa di fondo si trova al di fuori di OpenSSH, ma sshd è stato modificato per evitarla. Lo stesso giorno il CERT-FR ha pubblicato l’allerta CERTFR-2026-ALE-015: sono interessate tutte le versioni precedenti alla 10.6p2 e lo sfruttamento è definito banale se le condizioni sono presenti. Non è indicato alcun identificativo CVE e nessuna delle due fonti segnala finora attacchi.

Chi è interessato

Sono coinvolti solo i sistemi Linux che usano la libreria C musl ed eseguono sshd senza PAM. Secondo il ricercatore che ha scoperto la falla, la funzione crypt() di musl fallisce con password oltre i 256 byte e restituisce *, proprio il valore che in /etc/shadow indica un account senza password utilizzabile. Un attaccante può quindi accedere a un account di questo tipo (utenti che usano solo chiavi, o root sulle versioni recenti di Alpine, secondo il ricercatore) con una password smisurata, se l’autenticazione con password è attiva. Il ricercatore cita Alpine, OpenWrt, Buildroot, Yocto e le immagini Docker che ne derivano. Le distribuzioni basate su glibc, le configurazioni con PAM e Dropbear non sono colpiti, secondo la stessa analisi.

Cosa fare ora

1. Individuate i sistemi esposti: ldd --version mostra musl sulle piattaforme interessate; controllate sshd -T | grep -Ei 'usepam|passwordauthentication'.
2. Aggiornate: apk upgrade openssh, poi verificate che ssh -V riporti 10.6p2. Ricostruite e ridistribuite le immagini container che includono sshd.
3. Se l’aggiornamento deve attendere, disattivate gli accessi con password con PasswordAuthentication no in un file di /etc/ssh/sshd_config.d/ e riavviate sshd (rc-service sshd restart). In alternativa, il CERT-FR consiglia di fermare il servizio SSH.
4. Cercate tracce: elencate gli account con * nel campo password (grep -E '^[^:]+:\*:' /etc/shadow | cut -d: -f1) e cercate righe Accepted password for che li riguardano in /var/log/messages, come suggerisce il CERT-FR.

Il nostro parere

Le immagini leggere sono ovunque, nei container come negli apparati, ed ereditano le impostazioni predefinite del sistema di base, compreso un SSH senza PAM. L’autenticazione solo con chiave va imposta esplicitamente nella configurazione, non data per scontata: con PasswordAuthentication no questa falla sarebbe stata innocua.

Fonti

• CERT-FR — CERTFR-2026-ALE-015 : Vulnérabilité dans OpenSSH
• OpenSSH — Release notes for OpenSSH 10.6p2
• sshhole — OpenSSH password bypass on musl libc (researcher write-up)

Come scegliamo, verifichiamo e scriviamo le nostre analisi →