OpenSSH su Alpine: bypass critico dell’autenticazione password, cosa verificare su VPS e container

Il 5 novembre 2026 è stata rilasciata Portable OpenSSH 10.6p2 con una mitigazione critica: un bypass dell’autenticazione password sfruttabile tramite sshd su sistemi Linux basati su musl e con PAM disabilitato. È il profilo tipico di Alpine Linux, usato spesso in container e immagini cloud leggere. Lo stesso giorno Alpine ha pubblicato un’advisory dedicata.

Per una PMI ticinese la domanda pratica non è «siamo Alpine o Ubuntu?», ma: dove gira un sshd raggiungibile, con quale sistema e con quale metodo di login? Molti uffici usano VPS Ubuntu o hosting Infomaniak (glibc + PAM): lì non siete nel perimetro indicato. Il rischio sale se avete (o un fornitore ha) container o VM Alpine con SSH esposto e login a password attivo.

Cosa dicono OpenSSH e Alpine

Nelle note di rilascio, il team OpenSSH spiega che la root cause è considerata esterna a sshd, ma è sfruttabile tramite sshd e può essere evitata lì. La segnalazione è di Özgün Kültekin (Wakefield). Alpine riassume così l’impatto operativo: chi può raggiungere la porta SSH, in determinate condizioni di configurazione tipiche delle installazioni Alpine senza PAM, può autenticarsi senza conoscere una password valida. Al momento della advisory Alpine non era ancora stato assegnato un CVE.

Damien Miller (OpenSSH), nel comunicato sulla release ripreso anche da LWN, ha chiarito tre punti utili per chi gestisce server:

• il problema riguarda Linux con musl e senza PAM (Alpine è l’esempio tipico);
• non riguarda sistemi non-Linux, Linux con glibc, né Linux che usano PAM per l’autenticazione password;
• il rilascio è stato accelerato perché, con agenti AI che riscoprono bug già noti in poche ore, embarghi lunghi rischiano di aiutare soprattutto gli attaccanti.

Conferma anche che una build con PAM disponibile ma con UsePAM no resta nel perimetro. Alpine precisa che il pacchetto openssh-server-pam con UsePAM yes non è interessato; lo è invece openssh-server (senza PAM) oppure PAM con UsePAM no, se PasswordAuthentication è yes.

Chi è fuori e chi dentro, in pratica

Fuori dal perimetro tipico (secondo OpenSSH e Alpine): server Debian/Ubuntu e simili con glibc e autenticazione password via PAM; sistemi con PasswordAuthentication no; container che non eseguono affatto sshd; immagini cloud già configurate (spesso via cloud-init) per accettare solo chiavi SSH.

Dentro il perimetro da verificare subito: host Alpine (release supportate e anche rami più vecchi) con sshd in ascolto, pacchetto OpenSSH senza PAM o con PAM spento, e login a password ancora abilitato. Vale anche per piccoli VPS, bastion, CI runner e appliance basati su Alpine che qualcuno ha lasciato raggiungibili da Internet «solo per un accesso di emergenza».

Cosa verificare in ufficio

1. Inventario SSH. Elencare ogni macchina, VM e container dove gira sshd e da dove è raggiungibile (solo rete interna, VPN, Internet). Se la porta 22 (o un’altra porta SSH) è aperta verso Internet, ha priorità massima. Lo stesso inventario serve quando si controllano i servizi esposti: ne abbiamo parlato per NAS e inoltro delle porte nel articolo del 4 novembre.
2. Sistema operativo e libc. Su Ubuntu/Debian/Infomaniak tipici siete fuori dal caso musl+no-PAM. Su Alpine, immagini «slim» o appliance basate su musl, trattate l’host come potenzialmente interessato finché non avete verificato pacchetto e configurazione.
3. Metodo di login. Preferire chiavi SSH e disabilitare il login a password dove non serve. I livelli di sicurezza degli accessi (password, SMS, passkey) sono spiegati nel nostro articolo sui cinque livelli UFCS.
4. Versione OpenSSH e riavvio del demone. Alpine sottolinea che aggiornare il pacchetto non sostituisce da solo il demone in esecuzione: dopo l’upgrade va riavviato sshd. Le branch Alpine indicate nell’advisory (da edge alle 3.16 e successive) hanno pacchetti corretti; OpenSSH upstream indica 10.6p2 come release con la mitigazione.
5. Fornitori e container. Chiedere a chi gestisce hosting, Kubernetes o CI se esistono nodi o immagini Alpine con SSH esposto. Un container senza sshd non è nel perimetro; uno con SSH e password sì.

Mitigazioni difensive

Due strade chiudono il buco, come indica Alpine:

1. Aggiornare il pacchetto OpenSSH/Alpine alla versione corretta per la propria branch e riavviare sshd.
2. Se non potete aggiornare subito: impostare PasswordAuthentication no (login solo a chiave), verificare prima che l’accesso con chiave funzioni e tenere aperta la sessione corrente finché non avete testato un nuovo login; poi riavviare sshd.

Non pubblichiamo passaggi di sfruttamento né payload: l’obiettivo è chiudere l’esposizione, non riprodurla. Per il quadro delle altre falle recenti su stack web e server, vedi il riepilogo di fine ottobre.

Domande frequenti

Il nostro VPS è Ubuntu su Infomaniak: dobbiamo intervenire oggi?

Secondo OpenSSH, Linux con glibc e autenticazione password tramite PAM non rientra in questa vulnerabilità. Resta buona pratica tenere OpenSSH aggiornato e preferire chiavi SSH, ma non è lo stesso scenario Alpine/musl senza PAM.

Usiamo solo container Docker basati su Alpine, senza SSH dentro: siamo a rischio?

Alpine indica che chi non esegue sshd nel container non è interessato. Il rischio riguarda gli ambienti in cui SSH è in ascolto e raggiungibile.

Abbiamo aggiornato il pacchetto ma non abbiamo riavviato sshd: basta?

No. Alpine avverte esplicitamente che l’upgrade del pacchetto non sostituisce il demone già in esecuzione: serve il riavvio di sshd.

Esiste già un CVE?

Alla data dell’advisory Alpine (5 novembre 2026) non era ancora stato assegnato un identificatore CVE. Conviene seguire le note OpenSSH 10.6p2 e l’advisory Alpine, non un numero CVE inventato.

Il nostro approccio

ElaraTeq Sagl supporta PMI e studi in Ticino nell’inventario degli accessi SSH, nella scelta tra chiavi e password e nella pianificazione degli aggiornamenti su VPS, container e hosting in Svizzera (hosting, consulenza). Per una verifica della vostra esposizione potete contattarci.

Fonti

• OpenSSH, Portable OpenSSH 10.6p2 release notes, 5 novembre 2026
• Alpine Linux, Security advisory: openssh-server password authentication bypass, 5 novembre 2026
• Damien Miller, annuncio OpenSSH 10.6p2, 5 novembre 2026
• LWN.net, Critical security vulnerability affects OpenSSH on Alpine Linux systems, 5 novembre 2026