SSHole, la falla che permette agli hacker di entrare nei server Linux senza password. Gli attacchi sono già iniziati
Si chiama SSHole ed è identificata come CVE-2026-123158. La vulnerabilità interessa specifici sistemi Linux, soprattutto quelli basati su Alpine, e può permettere agli aggressori di superare l'autenticazione SSH. GreyNoise e altri ricercatori hanno confermato attività malevole. Ecco cosa sta succedendo e quali sistemi rischiano davvero.
Una vulnerabilità presente da anni in particolari configurazioni di OpenSSH può consentire l'accesso non autorizzato ad account che dovrebbero rifiutare le password. I ricercatori hanno documentato intrusioni reali e gli aggiornamenti di sicurezza sono già disponibili.
Una porta che doveva rimanere chiusa
Immaginiamo un server configurato per impedire l'accesso tramite password a determinati utenti.
Chi deve collegarsi utilizza una chiave digitale autorizzata. Chi non la possiede dovrebbe rimanere fuori.
È uno dei sistemi utilizzati per proteggere l'accesso remoto a computer, server e infrastrutture informatiche.
Eppure, in alcune configurazioni Linux, proprio un account che non dovrebbe accettare alcuna password può diventare accessibile attraverso una richiesta di autenticazione appositamente costruita.
La vulnerabilità è stata soprannominata SSHole e identificata con il codice CVE-2026-123158.
Il problema riguarda l'interazione tra OpenSSH, uno dei software più utilizzati per amministrare sistemi informatici a distanza, e musl, una libreria software impiegata da alcune distribuzioni Linux.
La scoperta è stata resa pubblica il 5 novembre 2026, dopo che il ricercatore Özgün Kültekin, di Wakefield, aveva segnalato il problema agli sviluppatori.
OpenSSH ha distribuito una correzione nello stesso giorno.
Ma la disponibilità di un aggiornamento non ha impedito agli aggressori di cominciare a sfruttare la falla.
Il 9 novembre, diversi gruppi di ricerca sulla sicurezza informatica avevano già documentato tentativi di intrusione e, in alcuni casi, accessi effettivamente riusciti.
Il rischio, quindi, non è soltanto teorico.
Come funziona una vulnerabilità così particolare?
Per comprenderla bisogna conoscere, almeno nelle sue linee essenziali, il funzionamento di SSH.
SSH, abbreviazione di Secure Shell, è un protocollo che permette di collegarsi a un computer remoto attraverso una connessione protetta.
Viene utilizzato quotidianamente dagli amministratori di sistema per gestire server, installare software, effettuare manutenzioni e controllare infrastrutture informatiche.
Normalmente, per ottenere l'accesso, bisogna dimostrare la propria identità attraverso una password oppure una chiave crittografica autorizzata.
Alcuni account vengono configurati affinché l'autenticazione tramite password sia impossibile.
Nei sistemi Linux, questa condizione può essere rappresentata da un particolare valore nel file che conserva le informazioni relative alle password degli utenti.
Il problema nasce quando OpenSSH viene utilizzato insieme alla libreria musl, senza il sistema di autenticazione PAM e in presenza di ulteriori condizioni.
In questi casi, una password insolitamente lunga può provocare un errore nella funzione utilizzata per verificarla.
Il valore restituito dall'errore può coincidere con quello presente nell'account che dovrebbe rifiutare le password.
Il risultato è paradossale.
Il sistema può interpretare un errore di autenticazione come una conferma valida e autorizzare l'accesso.
Non serve conoscere la vera password dell'account, perché quell'account non dovrebbe nemmeno consentire questo tipo di accesso.
Secondo la documentazione pubblicata da Wakefield, il comportamento vulnerabile esiste almeno dal 2016.
Questo non significa che sia stato sfruttato per tutti questi anni, ma che il problema è rimasto presente nel software fino alla recente scoperta.
Gli hacker hanno già cominciato a sfruttarla
La conferma più importante arriva dalle osservazioni effettuate dai ricercatori di sicurezza.
GreyNoise, società specializzata nel monitoraggio delle attività malevole su Internet, ha documentato compromissioni riuscite di sistemi di rilevamento configurati per osservare gli attacchi.
Nel rapporto aggiornato il 9 novembre, l'azienda registra 17 attività confermate successive allo sfruttamento della vulnerabilità nei propri sistemi di monitoraggio.
Non si tratta di una stima del numero complessivo di computer compromessi nel mondo.
È il risultato delle osservazioni effettuate direttamente dalla società sulle proprie infrastrutture di ricerca.
GreyNoise ha inoltre individuato un gruppo di attività ostili denominato GT10.
Durante le intrusioni, gli aggressori hanno eseguito comandi sui sistemi raggiunti, effettuato operazioni di ricognizione e tentato di ottenere informazioni sensibili.
In alcuni casi è stato osservato il tentativo di installare un software malevolo chiamato TAC Agent, realizzato in Python e progettato per consentire il controllo remoto della macchina.
L'analisi del programma ha individuato commenti e messaggi in lingua cinese e caratteristiche compatibili con un possibile impiego di strumenti di intelligenza artificiale durante il suo sviluppo.
Questi elementi non dimostrano però la nazionalità degli aggressori né permettono di attribuire gli attacchi a un governo.
Anche Previdian, società di sicurezza informatica, ha pubblicato osservazioni indipendenti.
I suoi sensori hanno registrato, tra il 6 e l'8 novembre, 20 tentativi di sfruttamento della vulnerabilità provenienti da 13 indirizzi IP, geolocalizzati in nove Paesi.
Sono dati circoscritti alle rispettive reti di osservazione, non una misura globale degli attacchi.
La loro importanza consiste nel confermare che SSHole è già entrata nelle attività operative degli aggressori.
Quali computer sono realmente vulnerabili?
È probabilmente la domanda più importante.
Il fatto che una vulnerabilità coinvolga Linux non significa che tutti i computer Linux siano automaticamente esposti.
SSHole richiede una combinazione specifica di condizioni.
Il sistema deve utilizzare OpenSSH insieme alla libreria musl, senza l'autenticazione PAM attiva, e deve presentare determinate configurazioni degli account e delle password.
Una delle distribuzioni maggiormente interessate è Alpine Linux.
Alpine è conosciuta per essere particolarmente leggera e viene utilizzata in ambienti server, sistemi cloud, container e dispositivi specializzati.
Non tutte queste installazioni sono vulnerabili.
Alpine Linux ha chiarito, per esempio, che i container che non eseguono un server SSH non sono interessati da questa specifica modalità di attacco.
Anche le installazioni che hanno disabilitato l'autenticazione SSH tramite password non sono esposte a questo meccanismo.
Red Hat ha confermato che i propri prodotti non risultano interessati, perché utilizzano configurazioni e librerie differenti, basate su glibc e PAM.
Il rischio riguarda dunque una parte precisa dell'ecosistema Linux, non l'intero sistema operativo.
Tuttavia, negli ambienti aziendali è necessario verificare anche server secondari, macchine virtuali e dispositivi che potrebbero utilizzare configurazioni diverse da quelle comunemente adottate.
Perché il problema riguarda anche le piccole aziende
Quando si parla di vulnerabilità informatiche, l'attenzione si concentra spesso sulle grandi organizzazioni.
Ma un accesso remoto non autorizzato può rappresentare un problema anche per una piccola impresa.
Un server può gestire il sito Internet di un'attività commerciale, conservare documenti, ospitare un gestionale oppure permettere il collegamento a sistemi utilizzati quotidianamente.
Se un aggressore riesce a entrare con privilegi elevati, le possibili conseguenze comprendono la modifica di file, il furto di informazioni, l'installazione di software malevolo e l'utilizzo del sistema compromesso per ulteriori operazioni.
Non significa che questi eventi si verifichino automaticamente.
Le conseguenze dipendono dai privilegi ottenuti e dalla configurazione dell'infrastruttura.
Il problema diventa particolarmente delicato quando i dispositivi vengono installati e poi utilizzati per anni senza un controllo regolare degli aggiornamenti.
È una situazione che può riguardare qualsiasi territorio, Sicilia compresa.
Un piccolo server collocato a Catania non è meno esposto di uno installato a Milano o all'estero soltanto perché gestisce un'attività locale.
Internet non distingue le dimensioni economiche di chi utilizza un sistema.
La sicurezza dipende dalle configurazioni e dalla manutenzione, non dall'importanza dell'azienda che possiede il dispositivo.
La correzione esiste già. Il problema è applicarla
OpenSSH ha pubblicato la versione 10.6p2 il 5 novembre 2026.
La distribuzione Alpine ha reso disponibili pacchetti corretti anche per diverse versioni precedenti del sistema operativo.
Questo significa che non è necessariamente richiesto installare l'ultima versione generale di OpenSSH.
Per chi utilizza pacchetti distribuiti e mantenuti da Alpine, è necessario verificare la versione corretta prevista per il proprio ramo del sistema operativo.
C'è però un dettaglio fondamentale.
Aggiornare il pacchetto non basta se il servizio SSH continua a funzionare con il vecchio software già caricato in memoria.
Gli sviluppatori di Alpine hanno infatti specificato che, dopo l'aggiornamento, è necessario riavviare il servizio SSH.
In alternativa, quando l'aggiornamento immediato non è possibile, la documentazione ufficiale consiglia di disabilitare temporaneamente l'autenticazione tramite password.
Questa operazione deve essere eseguita con attenzione, verificando prima che l'accesso attraverso le chiavi SSH funzioni correttamente.
Altrimenti si rischia di perdere l'accesso legittimo al proprio server.
Gli amministratori dovrebbero inoltre controllare i registri degli accessi e verificare l'eventuale presenza di account, chiavi autorizzate o servizi sconosciuti.
Un aggiornamento impedisce nuovi attacchi attraverso la vulnerabilità corretta, ma non elimina necessariamente le conseguenze di una compromissione già avvenuta.
Una vulnerabilità che racconta un problema più grande
SSHole evidenzia una caratteristica importante della sicurezza informatica moderna.
Un sistema può essere composto da programmi considerati affidabili e presentare comunque una vulnerabilità quando questi componenti interagiscono tra loro.
In questo caso, il problema emerge dal rapporto tra il software che gestisce l'accesso remoto e una libreria utilizzata per verificare le password.
La scoperta non dimostra che Linux sia intrinsecamente insicuro.
Dimostra piuttosto che la sicurezza di un'infrastruttura dipende anche dai dettagli meno visibili della sua configurazione.
Il ricercatore che ha individuato il problema lo ha comunicato agli sviluppatori prima della divulgazione pubblica.
La correzione è stata distribuita rapidamente.
Eppure, nel giro di pochi giorni, sono comparsi attacchi reali.
È questo l'aspetto più significativo della vicenda.
Oggi il tempo che separa la pubblicazione di una vulnerabilità dal suo sfruttamento può essere estremamente breve.
Per questo gli aggiornamenti di sicurezza non possono essere considerati soltanto interventi da rimandare al momento più comodo.
La lezione riguarda amministratori di sistema, aziende, professionisti e chiunque affidi parte della propria attività a un'infrastruttura informatica.
Una porta digitale può sembrare chiusa.
Ma sapere che dovrebbe esserlo non equivale ad aver verificato che lo sia davvero.
---
FONTE · OpenSSH — Note ufficiali della versione 10.6p2, 5 novembre 2026
FONTE · Alpine Linux — Avviso ufficiale sulla vulnerabilità SSH e aggiornamenti disponibili
FONTE · Wakefield — Ricerca originale di Özgün Kültekin sulla vulnerabilità OpenSSH e musl
FONTE · GreyNoise — SSHole CVE-2026-123158, monitoraggio degli attacchi e delle intrusioni
FONTE · Previdian — Tentativi di sfruttamento della vulnerabilità CVE-2026-123158
FONTE · SANS Internet Storm Center — Scansioni e tentativi di attacco SSHole, 8 novembre 2026
FONTE · Red Hat — Bollettino di sicurezza CVE-2026-123158 e sistemi interessati