Nuova falla Linux espone chiavi SSH e dati: quarta vulnerabilità in un mese

Una nuova analisi di Qualys ha riacceso i riflettori su un rischio concreto per i server Linux: una vulnerabilità locale nel kernel può consentire la lettura di dati sensibili presenti in memoria, incluse le chiavi private SSH caricate durante sessioni attive. Il problema si inserisce in un contesto già critico.

Negli ultimi due anni i bug gravi nel kernel Linux sono aumentati in modo significativo, soprattutto nelle aree che gestiscono memoria, page cache e sottosistemi crittografici. La superficie d’attacco è cresciuta insieme alla diffusione di ambienti cloud, container e piattaforme enterprise multiutente.

Come funziona l’attacco e perché le chiavi SSH sono a rischio

La vulnerabilità sfrutta la gestione della page cache, il meccanismo che conserva in RAM copie temporanee di file e dati. Un utente locale senza privilegi amministrativi può, in determinate condizioni, leggere porzioni di memoria che dovrebbero restare isolate, recuperando chiavi private temporaneamente caricate da processi SSH attivi o da agenti come ssh-agent.

Il rischio si amplifica perché le chiavi SSH rappresentano il principale meccanismo di autenticazione in molte infrastrutture Linux. Una chiave privata sottratta consente l’accesso diretto ai sistemi senza dover forzare password o aggirare sistemi MFA. Nei server che gestiscono pipeline DevOps, CI/CD o orchestrazione container, le chiavi vengono spesso usate per connessioni machine-to-machine: un furto può compromettere intere catene operative. La situazione peggiora quando le chiavi non sono protette da passphrase o vengono mantenute attive tramite agenti SSH persistenti.

Gli ambienti più esposti includono piattaforme VPS, host Kubernetes, server CI/CD e sistemi multiutente. Configurazioni con SELinux, AppArmor o seccomp riducono alcuni vettori d’attacco ma non eliminano il rischio se il bug coinvolge direttamente il kernel.

Le contromisure consigliate da Qualys

La priorità assoluta, secondo Qualys, è aggiornare il kernel non appena i maintainer rilasciano le patch correttive. In molti ambienti server gli aggiornamenti vengono rinviati per evitare downtime, ma questa scelta allunga la finestra di esposizione in modo inaccettabile.

Tra le misure aggiuntive consigliate: ridurre al minimo gli accessi locali non necessari, attivare Kernel Lockdown e politiche LSM più severe, separare i workload sensibili su host dedicati. Sul fronte delle credenziali, gli esperti raccomandano la rotazione frequente delle chiavi SSH, l’uso obbligatorio di passphrase robuste, la limitazione della permanenza delle chiavi negli agenti e l’adozione di token FIDO2 per l’autenticazione hardware.

Il quadro generale rimane preoccupante. Dopo Dirty Flag, DirtyCred, Copy Fail e RegreSSHion, questa nuova analisi conferma che il rischio nei server Linux moderni non dipende solo dagli attacchi remoti diretti, ma dalla capacità di sfruttare accessi locali limitati per scalare privilegi e sottrarre credenziali critiche.