ssh-keysign-pwn è la nuova vulnerabilità Linux che consente di rubare le chiavi SSH indisturbati

Quattro vulnerabilità del kernel Linux in meno di tre settimane. L'ultima, resa pubblica da Qualys Threat Research Unit e soprannominata "ssh-keysign-pwn" , permette a un utente locale senza privilegi di rubare le chiavi private SSH dell'host - quelle che garantiscono l'identità di un server a ogni connessione. Se gestite un server domestico, un Raspberry Pi raggiungibile via SSH o anche solo un desktop Linux con OpenSSH installato, la questione vi riguarda direttamente.

Un bug vecchio sei anni, ignorato dal 2020

La vulnerabilità è tracciata come CVE-2026-46333, soprannominata "ssh-keysign-pwn" dal nome di uno dei due exploit pubblici. Il difetto risiede nella funzione __ptrace_may_access(), la logica di controllo degli accessi di ptrace nel kernel: quando il descrittore di memoria (mm) del processo bersaglio è NULL, la funzione salta il controllo sulla proprietà "dumpable" del processo stesso. Una svista che apre una finestra di corsa (race window) sfruttabile.

Il meccanismo è sottile. Durante l'uscita di un processo, il kernel esegue exit_mm() - che rilascia la mappa di memoria - prima di exit_files(), che chiude i descrittori di file. In quell'intervallo brevissimo, un processo non privilegiato con lo stesso UID può invocare pidfd_getfd(2) per sottrarre i descrittori di file ancora aperti dal processo privilegiato morente. Nessuna escalation a root: l'attaccante ottiene semplicemente gli handle ai file che il processo privilegiato aveva aperto con i permessi di root.

La regressione è stata introdotta nel kernel v4.10-rc1 nel 2017, e l'interfaccia pidfd_getfd necessaria per l'exploit esiste da Linux 5.6. Il dettaglio più amaro: Jann Horn aveva segnalato lo stesso problema nell'ottobre 2020, proponendo una patch. Non è mai stata integrata. Sei anni di esposizione silenziosa.

Due exploit, due bersagli: chiavi SSH e hash delle password

Poche ore dopo che Linus Torvalds ha pubblicato la correzione upstream (commit 31e62c2ebbfd, 14 maggio 2026), un ricercatore con lo pseudonimo "_SiCk" ha rilasciato due exploit funzionanti su GitHub.

Il primo bersaglio è ssh-keysign, un binario setuid presente su ogni sistema Linux con OpenSSH. Questo programma apre le chiavi private dell'host - /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key, /etc/ssh/ssh_host_rsa_key - come root, prima di rilasciare i privilegi. L'exploit sfrutta la finestra di corsa durante la sua uscita per appropriarsi di quei descrittori di file. Non serve alcuna configurazione speciale del binario: la corsa si innesca durante la normale chiusura del processo.

Il secondo exploit punta a chage, un altro binario setuid, sottraendo l'handle aperto verso /etc/shadow - il file che contiene gli hash di tutte le password utente del sistema.

In termini pratici, il proof-of-concept riesce tipicamente entro 100-2.000 tentativi. Non è un attacco teorico che richiede condizioni di laboratorio: è un exploit affidabile su sistemi reali.

Perché il furto delle chiavi SSH è un problema serio

Le chiavi private dell'host SSH sono il fondamento della fiducia nelle connessioni Secure Shell. Chi le possiede può impersonare il server e condurre attacchi man-in-the-middle su qualsiasi connessione SSH diretta a quella macchina - intercettando credenziali, comandi e dati mentre entrambe le parti credono di comunicare in modo sicuro.

Il rischio non si esaurisce sulla singola macchina compromessa. Le chiavi SSH vengono spesso riutilizzate tra ambienti diversi, e un server domestico violato può diventare il punto di partenza per un movimento laterale verso altre macchine della rete. L'accesso a /etc/shadow, nel frattempo, offre agli attaccanti gli hash delle password per un attacco di forza bruta offline, senza generare alcun allarme sui sistemi di autenticazione.

C'è un ultimo elemento che vale la pena tenere a mente: le chiavi rubate restano utilizzabili fino a quando non vengono esplicitamente rigenerate e sostituite. Applicare la patch del kernel non invalida ciò che potrebbe essere già stato sottratto.

Chi è colpito e chi no

La vulnerabilità interessa la maggior parte delle distribuzioni Linux con kernel precedente alla patch del 14 maggio. Ubuntu, Debian, Arch Linux, CentOS e Raspberry Pi OS sono esplicitamente citati tra le distribuzioni coinvolte. Entrambe le versioni di AlmaLinux 9 e 10 sono vulnerabili, con gli exploit pubblici che funzionano in modo affidabile su entrambe.

La situazione è più sfumata per i kernel della famiglia 4.18. AlmaLinux 8 presenta il bug logico sottostante, ma gli attuali proof-of-concept non riescono a sfruttarlo; una patch viene comunque distribuita in via preventiva. CloudLinux 7, basato sul kernel 3.10, non è affetto - la regressione semplicemente non è presente. CloudLinux 7h e CloudLinux 8 hanno la condizione di corsa nel kernel 4.18 ma non espongono pidfd_getfd, rendendo l'attuale exploit inefficace. La comunità di sicurezza sta però preparando exploit adattati che usano metodi diretti, quindi la protezione è solo temporanea.

Un'eccezione importante: CloudLinux 8 LTS utilizza un kernel diverso che espone pidfd_getfd, rendendo il proof-of-concept pubblico direttamente funzionante. Va trattato con lo stesso livello di rischio di CloudLinux 9 e 10.

Patch disponibili e mitigazioni

I kernel corretti per AlmaLinux sono arrivati nei repository di produzione il 16 maggio alle 15:05 UTC:

• AlmaLinux 8: kernel-4.18.0-553.124.4.el8_10 (ALSA-2026:A008)
• AlmaLinux 9: kernel-5.14.0-611.54.6.el9_7 (ALSA-2026:A009)

La stessa build del kernel per AlmaLinux include anche la correzione per Fragnesia (CVE-2026-46300), la vulnerabilità del 13 maggio: un singolo dnf upgrade seguito da un riavvio copre entrambi i problemi. Per chi non può permettersi il riavvio, KernelCare offre livepatch su tutte le versioni CloudLinux interessate.

Per i sistemi non ancora aggiornati, CloudLinux raccomanda un parametro sysctl specifico come mitigazione immediata, reversibile e applicabile a livello di kernel. CageFS è indicato come ulteriore strato di protezione. Va però chiarito un punto: ciascuna delle quattro vulnerabilità di maggio ha una mitigazione diversa. La lista nera dei moduli usata per Dirty Frag, ad esempio, non ha alcun effetto su CVE-2026-46333. Non esistono scorciatoie.

Il quadro d'insieme è preoccupante

Il fatto che l'exploit pubblico sia apparso a poche ore dalla correzione upstream riduce il margine di reazione per gli amministratori a qualcosa di molto vicino a zero.

La lezione più scomoda la offre la cronologia di questo bug specifico. Jann Horn - uno dei ricercatori di sicurezza più rispettati del settore - aveva individuato il problema sei anni fa. La sua patch non è mai stata integrata. Non per disaccordo tecnico, non per incompatibilità architetturale: è semplicemente caduta nel vuoto. E per sei anni, ogni sistema Linux con kernel 4.10 o successivo e pidfd_getfd disponibile ha portato con sé questa finestra di corsa, in attesa che qualcuno la sfruttasse.

Per chi amministra server domestici o accede al proprio Raspberry Pi via SSH, il messaggio è netto: aggiornate il kernel, riavviate, e poi rigenerate le chiavi SSH dell'host. La patch chiude la porta, ma non recupera ciò che potrebbe essere già uscito.

Fonti: blog.cloudlinux.com, cybersecuritynews.com, almalinux.org