Segui Una vulnerabilità di alta gravità in OpenSSH può consentire ad attaccanti remoti non autenticati di aggirare l’autenticazione con password su determinati sistemi Linux inviando una password troppo lunga. Tracciata come CVE-2026-123158 e soprannominata SSHhole, la falla ha un punteggio CVSS 3.1 di 8.1 e impatta principalmente gli ambienti Linux dove sshd è collegato con musl libc e opera senza PAM. Alpine Linux è la piattaforma più colpita perché il suo pacchetto standard openssh-server utilizza questa configurazione per impostazione predefinita.
La vulnerabilità deriva da un’interazione inaspettata tra la convalida della password di OpenSSH e l’implementazione della funzione crypt() di musl libc. Quando viene fornita una password eccessivamente lunga, crypt() può restituire la stringa * per indicare un errore. Alcuni account Linux configurati senza una password convenzionale memorizzano anche * nel campo password di /etc/shadow. In condizioni vulnerabili, sshd può interpretare erroneamente i valori corrispondenti come autenticazione avvenuta con successo.
Un attaccante non ha bisogno di conoscere la password dell’utente target. Se un servizio SSH esposto soddisfa le condizioni necessarie, un attaccante che possa raggiungere il servizio può autenticarsi a determinati account usando una password nella gamma di lunghezza vulnerabile. L’impatto dipende dai privilegi assegnati all’account compromesso. L’accesso a un account di servizio privilegiato o a un account in grado di utilizzare doas o un altro meccanismo di escalation dei privilegi potrebbe portare a un compromesso completo del sistema.
OpenSSH ha affrontato il problema in Portable OpenSSH 10.6p2, rilasciato il 5 novembre 2026. Alpine Linux ha rilasciato contemporaneamente pacchetti OpenSSH corretti per tutti i rami supportati e per diversi rami più vecchi. Il team di OpenSSH descrive il rilascio come contenente una soluzione di sicurezza critica per i sistemi Linux che utilizzano musl libc con PAM disabilitato.
Sono già disponibili ambienti di riproduzione pubblici e materiale proof-of-concept. Tuttavia, a partire dal 6 novembre 2026, le fonti esaminate non riportano sfruttamenti confermati della vulnerabilità in attacchi reali, e la falla non è stata aggiunta al catalogo delle vulnerabilità note sfruttate di CISA.
Le organizzazioni possono rafforzare le difese contro le emergenti vulnerabilità di bypass dell’autenticazione con la piattaforma AI-Nativa di SOC Prime per l’Intelligence delle Rilevazioni, accelerando la caccia alle minacce e l’ingegneria delle rilevazioni su ambienti SIEM, EDR, XDR e Data Lake.
I team di sicurezza possono anche utilizzare Prime Architect per trasformare l’intelligence delle vulnerabilità in query di caccia e logiche di rilevazione personalizzate per la loro telemetria SSH, autenticazione, endpoint e di rete disponibili.
Rileva CVE-2026-123158 monitorando i login SSH basati su password riusciti verso account che normalmente utilizzano solo l’autenticazione con chiave, tentativi di autenticazione insoliti contenenti password anormalmente lunghe, accessi remoti imprevisti a account di servizio e attività post-autenticazione incoerenti con il comportamento normale dell’account.
Il contenuto di rilevazione potrebbe non essere disponibile per ogni CVE. Verifica la copertura attuale sulla Piattaforma SOC Prime. Se le rilevazioni pertinenti non sono ancora disponibili, controlla nuovamente poiché nuova intelligence sulle minacce e contenuti di rilevazione vengono continuamente aggiunti.
Analisi di CVE-2026-123158
CVE-2026-123158 colpisce OpenSSH sshd prima di Portable OpenSSH 10.6p2 quando gira su Linux con musl libc e l’autenticazione della password avviene senza PAM. Il CVE ha un punteggio CVSS 3.1 di 8.1 con il vettore AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, riflettendo lo sfruttamento remoto senza privilegi preesistenti o interazione dell’utente ma richiedendo una configurazione specifica del sistema e dell’account.
La causa principale risiede nell’interazione tra OpenSSH e la funzione di hashing delle password fornita da musl libc.
Nei sistemi dove PAM è disabilitato, sshd esegue la convalida delle password utilizzando la funzionalità crypt() del sistema. Per un account tipico, /etc/shadow contiene un hash di password crittografico e il valore generato dalla password fornita dall’utente viene confrontato con l’hash memorizzato.
musl libc si comporta diversamente quando la password fornita supera la lunghezza di input supportata. Per password più lunghe di 256 byte, crypt() restituisce * come valore di errore anziché un normale hash di password.
Il problema si verifica perché * è comunemente utilizzato anche in /etc/shadow per account che non hanno una password tradizionale configurata.
Se un sshd vulnerabile riceve una password troppo lunga per uno di questi account, il flusso di autenticazione può effettivamente confrontare il * restituito da crypt() con il * memorizzato nella voce shadow dell’account. I valori corrispondono e l’autenticazione può avere successo erroneamente.
La descrizione del CVE afferma che, per le configurazioni dell’account affette, password tra 256 e 1024 caratteri possono risultare in un’autenticazione riuscita. Riproduzioni indipendenti descrivono password che superano il normale limite di 256 byte come sufficienti per innescare la condizione vulnerabile.
La falla non è quindi una bypass universale delle password che colpisce ogni dispiegamento di OpenSSH.
Diverse condizioni specifiche devono allinearsi.
Innanzitutto, il server deve utilizzare musl libc. Alpine Linux è l’esempio principale tradizionale, sebbene altri ambienti Linux embedded o minimalisti possano anche utilizzare musl.
Secondo, sshd deve autenticare gli utenti senza PAM. Il pacchetto standard openssh-server di Alpine è costruito senza PAM, mentre la configurazione alternativa openssh-server-pam è protetta quando l’opzione UsePAM yes è abilitata.
Terzo, l’autenticazione con password deve essere abilitata. PasswordAuthentication yes è la configurazione rilevante. I sistemi configurati solo per l’autenticazione con chiave pubblica con PasswordAuthentication no non sono esposti al percorso di attacco documentato.
Infine, l’attaccante necessita di un account il cui campo password contenga *. Questi possono includere utenti con sola chiave, account creati senza password, alcune identità fornite tramite servizi directory, e certi utenti di immagini cloud.
Alpine osserva anche una condizione aggiuntiva: almeno un account locale deve contenere un hash di password in stile $5$ o $6$ affinché il percorso di autenticazione vulnerabile operi come descritto.
L’account root merita un’attenzione speciale. Alpine memorizza comunemente root:*, ma il default di OpenSSH PermitRootLogin prohibit-password impedisce l’autenticazione con password direttamente a root. Di conseguenza, un’installazione standard di Alpine non espone automaticamente il login diretto root tramite questo bug.
Quella protezione non elimina il rischio più ampio. Se un altro account con * nel suo campo password è accessibile in remoto e ha diritti amministrativi tramite doas, sudo, capacità del container, o altri meccanismi privilegiati, un’autenticazione avvenuta con successo può ancora fornire un percorso per il compromesso completo del sistema.
Le immagini ufficiali tiny-cloud di Alpine sono particolarmente rilevanti. La ricerca di sicurezza ha identificato versioni in cui l’account alpine potrebbe soddisfare le condizioni vulnerabili ed era anche in grado di utilizzare doas per ottenere privilegi elevati. Questo illustra perché i difensori dovrebbero valutare i privilegi degli account piuttosto che assumere che la vulnerabilità fornisca sia un accesso utente innocuo o un accesso root automatico in ogni ambiente.
Le distribuzioni Linux basate su glibc come Debian, Ubuntu e RHEL non sono interessate da questa specifica vulnerabilità perché il comportamento vulnerabile dipende dall’implementazione dell’hashing delle password di musl libc. I sistemi che utilizzano PAM per la convalida della password SSH sono ugualmente al di fuori della configurazione vulnerabile documentata.
I container richiedono una qualificazione simile. Alpine è ampiamente utilizzato come immagine base per i container, ma i container ordinari che non eseguono sshd non sono vulnerabili tramite questo percorso di attacco. La principale preoccupazione riguarda i container, gli appliance, gli ambienti di sviluppo o i carichi di lavoro legacy che installano ed espongono esplicitamente un server SSH.
Il panorama PoC di CVE-2026-123158 si è evoluto rapidamente. I laboratori di riproduzione pubblica sono direttamente referenziati dal registro della vulnerabilità, dimostrando che i difensori dovrebbero assumere che il bypass dell’autenticazione possa essere riprodotto senza accesso alla ricerca sugli exploit privati. Questo aumenta materialmente l’urgenza della remediation, anche se non è stata ancora segnalata un’esplorazione malevola confermata.
La vulnerabilità è stata segnalata da Özgün Kültekin di Wakefield. OpenSSH ha rilasciato pubblicamente la versione 10.6p2 con la soluzione di sicurezza il 5 novembre 2026. Le fonti primarie riviste non specificano la data esatta in cui il ricercatore ha inizialmente scoperto o segnalato privatamente il problema.
La correzione di OpenSSH aggiunge una convalida progettata per prevenire che i valori di errore e gli hash di password brevi non validi vengano accettati durante l’autenticazione della password. OpenSSH osserva che considera la causa principale sottostante come esistente al di fuori di sshd, ma poiché la condizione può essere sfruttata attraverso il server SSH, il progetto ha implementato una soluzione difensiva in OpenSSH stesso.
Alpine Linux ha applicato la correzione retrospettivamente a più rami:
| Ramo Alpine | Pacchetto OpenSSH corretto |
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
Gli amministratori dovrebbero fare affidamento sullo stato del pacchetto di distribuzione piuttosto che solo sul banner della versione SSH. Le distribuzioni Linux frequentemente applicano patch di sicurezza retrospettive senza modificare la versione upstream di OpenSSH visualizzata durante l’handshake SSH. Un server che mostra una versione stringa più vecchia potrebbe quindi già contenere la correzione del vendor.
Per la rilevazione di CVE-2026-123158, i difensori dovrebbero dare priorità alla telemetria dell’autenticazione SSH. Un segnale di caccia particolarmente forte è un login tramite password riuscito a un account che è destinato a utilizzare solo l’autenticazione con chiave pubblica o che non ha una password utilizzabile configurata.
Su sistemi Alpine, gli amministratori possono rivedere /var/log/messages, log di autenticazione centralizzati, record SIEM, o telemetrie equivalenti per eventi Accepted password che coinvolgono account di servizio imprevisti, solo chiave o amministrativi.
I difensori dovrebbero correlare l’autenticazione riuscita con gli indirizzi IP di origine, i tempi di accesso, la durata della sessione, i comandi eseguiti dopo l’accesso, l’elevazione dei privilegi, i cambiamenti ai authorized_keys, la creazione di account, i lavori pianificati, e le connessioni di rete in uscita inaspettate.
La telemetria di rete può anche aiutare a identificare i sistemi esposti. I servizi SSH raggiungibili esternamente che pubblicizzano l’autenticazione a password o interattiva tramite tastiera dovrebbero ricevere una priorità di remediation più alta, in particolare quando il sistema sottostante è Alpine o un’altra distribuzione basata su musl.
Al momento, non ci sono IOC di CVE-2026-123158 come indirizzi IP degli attaccanti confermati, domini, hash di malware o infrastrutture di comando e controllo. L’assenza di indicatori statici rende particolarmente importante il monitoraggio comportamentale dell’autenticazione SSH e dell’attività di sessione successiva.
Mitigazione di CVE-2026-123158
La principale soluzione consiste nell’installare OpenSSH 10.6p2 o il pacchetto corretto fornito dalla distribuzione Linux. Gli amministratori di Alpine dovrebbero aggiornare l’intero sistema utilizzando i repository di pacchetti correnti e riavviare sshd successivamente. L’aggiornamento del solo pacchetto non sostituisce il processo del demone SSH già in esecuzione.
Le organizzazioni che eseguono container basati su Alpine dovrebbero ricostruire e ridistribuire qualsiasi immagine che installa openssh-server. L’aggiornamento del sistema operativo host da solo non patcha i pacchetti OpenSSH vulnerabili incorporati nelle immagini dei container.
Gli amministratori dovrebbero anche identificare l’esposizione prima di assumere che ogni host Alpine sia vulnerabile. I controlli chiave includono:
- Determinare se l’host utilizza musl libc.
- Verificare se sshd è in esecuzione con PAM disabilitato.
- Controllare se l’autenticazione con password è abilitata.
- Identificare gli account abilitati al login il cui campo password in /etc/shadow è *.
- Rivedere i privilegi assegnati a tali account.
- Confermare il pacchetto OpenSSH installato rispetto alla versione corretta del pacchetto della distribuzione.
Se la patch immediata è impossibile, le organizzazioni dovrebbero disabilitare l’autenticazione con password SSH.
Configurare:
PasswordAuthentication no
e, dove applicabile:
KbdInteractiveAuthentication no
Gli amministratori dovrebbero confermare che l’autenticazione con chiave pubblica funziona prima di applicare questa configurazione per evitare di perdere l’accesso amministrativo legittimo.
La configurazione SSH dovrebbe quindi essere convalidata e il demone ricaricato o riavviato. Successivamente, la verifica esterna dovrebbe confermare che il server offre solo l’autenticazione con chiave pubblica.
Limitare l’accessibilità della rete fornisce una difesa in profondità aggiuntiva. SSH dovrebbe generalmente essere raggiungibile solo da reti amministrative fidate, infrastrutture VPN, hosts bastioni, o liste di permesso IP di origine esplicite piuttosto che essere esposto universalmente a Internet.
Le organizzazioni dovrebbero anche considerare se SSH sia necessario all’interno dei container. Gli ambienti di orchestrazione moderni in genere forniscono alternative come docker exec o kubectl exec, eliminando un servizio di autenticazione raggiungibile a distanza non necessario.
Per i sistemi potenzialmente esposti, rivedere gli accessi di successo tramite password storici avvenuti prima della remediation. Prestare particolare attenzione agli account configurati senza password e alle identità normalmente attese a autenticarsi esclusivamente con chiavi SSH.
Se viene identificato un accesso tramite password riuscito inaspettato, trattare l’account come potenzialmente compromesso. Revisionare la cronologia della shell dove disponibile, l’esecuzione dei processi, l’elevazione dei privilegi, le nuove o modificate voci del file authorized_keys, le modifiche agli utenti e ai gruppi, i lavori cron, gli script di avvio, l’installazione di pacchetti e le connessioni di rete in uscita.
Credenziali e chiavi accessibili all’account compromesso dovrebbero essere considerate potenzialmente esposte e ruotate in base ai risultati dell’indagine. Se l’account aveva privilegi amministrativi, i difensori dovrebbero espandere l’indagine all’intero host e ai sistemi raggiungibili utilizzando le credenziali memorizzate lì.
Il materiale proof-of-concept pubblico significa che le organizzazioni non dovrebbero aspettare prove di attacchi diffusi prima di applicare la correzione. I prerequisiti di sfruttamento riducono la popolazione vulnerabile, ma i sistemi che soddisfano quelle condizioni possono essere accessibili a distanza senza conoscenza di una password valida.
FAQ
Cos’è CVE-2026-123158 e come funziona?
CVE-2026-123158 è un bypass dell’autenticazione con password che interessa OpenSSH sshd su sistemi Linux che utilizzano musl libc senza PAM. Quando una password eccessivamente lunga viene passata alla funzione crypt() di musl, essa può restituire * come valore di errore. Se anche l’account di destinazione ha * memorizzato in /etc/shadow, le configurazioni vulnerabili di sshd possono trattare erroneamente i valori come corrispondenti e consentire l’autenticazione.
Quando è stato scoperto per la prima volta CVE-2026-123158?
La vulnerabilità è stata segnalata da Özgün Kültekin di Wakefield. OpenSSH ha pubblicato la correzione di sicurezza in Portable OpenSSH 10.6p2 il 5 novembre 2026 e il CVE è diventato pubblico lo stesso giorno. Gli attuali avvisi primari esaminati non divulgano la data esatta della scoperta privata originale del ricercatore.
Qual è l’impatto di CVE-2026-123158 sui sistemi?
Lo sfruttamento riuscito consente a un attaccante remoto non autenticato di accedere a un account qualificante senza conoscere la sua password. L’impatto risultante dipende dai permessi di quell’account. Il compromesso di un account di servizio o standard può esporre dati e risorse applicative, mentre l’accesso a un account con privilegi doas, sudo, o equivalenti può potenzialmente portare a un compromesso completo del sistema.
CVE-2026-123158 può ancora influenzarmi nel 2026?
Sì. Le installazioni OpenSSH vulnerabili rimangono esposte fino a quando non vengono patchate o l’autenticazione con password è disabilitata. I sistemi a più alto rischio sono ambienti Linux basati su musl come Alpine Linux che eseguono sshd senza PAM e contengono account senza password qualificanti. Esistono materiali di riproduzione pubblica, sebbene non sia stato segnalato uno sfruttamento confermato in natura fino al 6 novembre 2026.
Come posso proteggermi da CVE-2026-123158?
Aggiorna a OpenSSH 10.6p2 o al pacchetto corretto della tua distribuzione e riavvia sshd. Se la patch non può essere completata immediatamente, disabilita l’autenticazione con password e interattiva tramite tastiera, restringi l’esposizione SSH a reti fidate, e rivedi gli accessi tramite password riusciti per attività sospette. Gli amministratori dovrebbero continuare a monitorare gli avvisi dei vendor per dettagli aggiornati su CVE-2026-123158 man mano che l’intelligence sullo sfruttamento evolve.
