CVE-2026-123158: bypass OpenSSH su Alpine Linux con password da 257 byte

Il 5 novembre 2026 OpenSSH ha rilasciato la versione 10.6p2 correggendo una falla di autenticazione che colpisce specificamente i sistemi Linux basati su musl libc, Alpine Linux in primis. La vulnerabilità CVE-2026-123158 permette di bypassare il controllo password inviando una stringa di lunghezza insolita — tra 257 e 1024 byte — che sfrutta un comportamento anomalo della funzione crypt() di musl libc. La combinazione è rara ma letale: nessuna credenziale valida richiesta, una sola connessione SSH, e l'accesso a account configurati senza password.

Il meccanismo: perché musl libc e OpenSSH si sono scontrati

La radice della vulnerabilità non risiede in un errore di implementazione tipico, ma in un'interazione non prevista tra due componenti standard del sistema. Quando OpenSSH sshd riceve una password durante l'autenticazione, la passa alla funzione crypt() per confrontarla con l'hash memorizzato in /etc/shadow. Su sistemi con musl libc, se la password supera i 256 byte, crypt() restituisce il carattere '*' come indicatore di errore.

Il problema è che molti account configurati senza password — in particolare quelli pensati per l'uso esclusivo con chiave SSH — memorizzano proprio '*' nel campo password di /etc/shadow. Sotto queste condizioni, sshd interpreta il match tra due valori '*' come autenticazione riuscita, anche se nessuna password corretta è stata fornita.

Secondo la fonte, OpenSSH ha trattato la vulnerabilità con una correzione difensiva interna, aggiungendo validazione per impedire che valori di errore e hash brevi invalidi vengano accettati. La fonte cita esplicitamente che il progetto OpenSSH considera la causa radice esterna a sshd, ma ha implementato il workaround proprio perché la condizione è esercitabile attraverso il server SSH.

Le condizioni precise: non tutti i sistemi sono a rischio

La catena di prerequisiti è stretta e questo ha limitato la superficie di attacco, ma non l'impatto dove si verifica. Perché il bypass operi servono quattro condizioni cumulative: il sistema deve usare musl libc anziché glibc; PAM deve essere disabilitato; PasswordAuthentication deve essere impostato su yes; e l'account target deve avere '*' nel campo password di /etc/shadow.

A queste si aggiunge un quinto requisito meno intuitivo: sul sistema deve esistere almeno un altro account locale con hash password in formato SHA-256 ($5$) o SHA-512 ($6$). Senza questa presenza, il percorso vulnerabile non si attiva. Alpine Linux soddisfa queste condizioni in configurazione predefinita: il pacchetto openssh-server è compilato senza PAM e PasswordAuthentication è abilitato di default.

Le versioni confermate vulnerabili spaziano dalla 3.16 alla 3.24, incluso il branch edge. Sistemi con glibc, configurazioni PAM attive, o PasswordAuthentication no non sono interessati. PermitRootLogin prohibit-password blocca l'accesso diretto come root, ma non protegge altri account con potenziali privilegi elevati.

Account "key-only" e la trappola del campo asterisco

Una dimensione sottovalutata della vulnerabilità riguarda la diffusione di un pattern di configurazione comune ma poco compreso. Gli amministratori creano account pensati per l'autenticazione esclusiva via chiave SSH, lasciando il campo password impostato a '*' con l'intenzione di renderli inaccessibili via password. La falla dimostra che questo pattern, su musl libc, trasforma l'assenza di password in una password universale di lunghezza arbitraria.

"Alpine tiny-cloud images from 3.18.11 through 3.24.3 include this alpine account with an asterisk password field. These images become vulnerable once a compatible password hash exists on the system, such as after an administrator configures a console password."
— Field Effect [FONTE 3]

Il caso delle immagini tiny-cloud di Alpine è emblematico: l'account alpine con privilegi doas senza password, una volta autenticato tramite il bypass, permette l'escalation a root. La semplicità concettuale dell'attacco — una singola connessione SSH con payload di 257 byte — lo rende accessibile anche a operatori non sofisticati, pur nelle condizioni specifiche richieste.

La discrepanza su exploitation in-the-wild

Sul fronte della minaccia attiva, le tre fonti disponibili non concordano. Horizon3.ai afferma che "exploitation in the wild has been confirmed", senza fornire dettagli sulle circostanze o sulla portata. Socprime.com afferma esplicitamente il contrario: "do not report confirmed exploitation". Fieldeffect.com si allinea con quest'ultima posizione, non riportando segnalazioni di exploit nel mondo reale.

Questa divergenza impedisce di enunciare con certezza lo stato della minaccia attiva. Ciò che è documentato è la disponibilità di proof-of-concept pubblici, che riducono la barriera all'exploit per attori interessati. La fonte non specifica la natura di eventuali dati di rilevamento associati a horizon3.ai.

Perche e importante

Il rischio si concentra su nicchie tecniche che, però, rappresentano infrastrutture critiche spesso trascurate. Alpine Linux è largamente adottato in ambienti containerizzati, appliance di sicurezza, piattaforme embedded e sistemi cloud minimi — contesti dove la superficie di attacco è volutamente ridotta, ma dove una falla di autenticazione remota ha impatto disproporzionato. La configurazione "key-only" è standard in questi ambienti, e il pattern '*' nel campo password è diffuso senza consapevolezza del rischio specifico su musl libc.

La fonte non quantifica l'estensione della popolazione vulnerabile esposta su internet. L'assenza di dati censiti non equivale a assenza di esposizione: scanner di servizi SSH su porta 22 con banner identificabili sono routine per attori di minaccia, e la specificità della catena di condizioni non protegge i sistemi che la soddisfano. Alpine Linux ha pubblicato advisory e pacchetti patchati il 5 novembre 2026 per tutti i branch supportati.

Rilevamento: cosa guardare nei log

Per le organizzazioni che gestiscono sistemi Alpine o musl-based, la fonte indica come punto di controllo i log di autenticazione SSH. Eventi di successo su account con '*' nel campo password, preceduti da tentativi con payload di lunghezza insolita, rappresentano l'anomalia specifica da correlare. La fonte non dettaglia ulteriori signature di rete o indicatori di compromissione.

La tempistica è rilevante: la patch è disponibile dal 5 novembre 2026, ma la finestra di esposizione precedente al rilascio non è quantificata. La data di report iniziale della vulnerabilità non emerge dal materiale raccolto.

FAQ

Quali sistemi sono sicuramente non vulnerabili?

Sistemi con glibc al posto di musl libc, configurazioni con PAM abilitato, o istanze con PasswordAuthentication no non soddisfano le condizioni della falla. La fonte non segnala varianti del meccanismo su altre librerie crittografiche.

Perché la soglia è proprio 257 byte?

I 256 byte rappresentano il limite oltre cui musl libc crypt() restituisce errore. Il range efficace di 257-1024 byte è quello che produce il matching con '*' nel campo password. La fonte non chiarisce se lunghezze superiori a 1024 byte generino comportamenti differenti.

Container Alpine sono a rischio?

Solo se eseguono sshd ed espongono il servizio. La fonte non estende la vulnerabilità a container senza demone SSH attivo. Le immagini tiny-cloud con account alpine configurato rappresentano uno scenario documentato di rischio.