Ci sono vulnerabilità che si scoprono in laboratorio e vulnerabilità che si scoprono leggendo le richieste di aiuto di chi è già stato colpito. Questa appartiene alla seconda categoria. Il 1° settembre 2026 Proxmox ha pubblicato l'advisory PSA-2026-00043-1, e nel testo ammette che il problema è emerso da «numerose segnalazioni indipendenti nelle ultime due giornate, che riportano anche sfruttamento in rete». Tradotto: la falla è diventata nota perché le intrusioni erano già avvenute.

Cosa è successo

Il bug è un bypass di autenticazione pre-autenticazione nel pacchetto libpve-access-control, quello che governa il login all'API di Proxmox Virtual Environment. È tracciato dai database di vulnerabilità come CVE-2023-54391 (punteggio CVSS 9.8 in versione 3.1, 9.3 in versione 4.0), anche se — trattandosi di un caso ancora molto fresco — non è escluso che l'identificativo venga rinumerato.

Il meccanismo è tanto semplice quanto imbarazzante. Il login passa da una chiamata POST /api2/json/access/ticket. Se l'account non ha un secondo fattore, il server verifica la password e rilascia subito il ticket di autenticazione. Se invece il secondo fattore c'è, il server restituisce un ticket intermedio e il client deve rigiocare la chiamata aggiungendo il parametro tfa-challenge, che porta con sé quel ticket intermedio e la risposta al secondo fattore.

Nelle versioni vulnerabili, il codice decide se si trova al primo o al secondo passaggio guardando soltanto se il parametro tfa-challenge è presente. Non appena compare, il software dà per scontato di essere alla verifica del secondo fattore e salta del tutto il controllo della password, dando per acquisito che sia stata verificata al giro precedente. Il problema è che il ticket intermedio, che avrebbe dovuto garantire proprio quel giro precedente, non viene validato per un utente che il secondo fattore non ce l'ha. Il codice cerca una risposta 2FA da controllare, non trova nulla, e invece di rifiutare la richiesta la lascia passare.

Il risultato è una richiesta anonima in cui manca il campo password e che restituisce un ticket valido per qualunque account privo di 2FA. Compreso, per impostazione predefinita, root@pam.

Da ticket root a controllo totale

Un ticket per root@pam non è «accesso in lettura alla dashboard». È l'account legato al root Unix reale dell'host, e l'API di Proxmox è per progettazione un telecomando completo della macchina. L'esecuzione di codice non richiede una seconda vulnerabilità: è una funzionalità. La console del nodo (termproxy più WebSocket) apre una shell di root sull'hypervisor; il qemu-guest-agent permette di eseguire comandi dentro le macchine virtuali; gli hook script su avvio o backup garantiscono persistenza che sopravvive al riavvio. Root sull'host significa controllo di ogni VM e ogni container che ci gira sopra.

Non è uno zero-day, è un n-day

Il dettaglio che rende questo caso istruttivo è la cronologia. Il bug è stato corretto a luglio 2023, nella versione libpve-access-control 8.0.4, come effetto collaterale di una riscrittura del login a due fattori. Nessuno lo riconobbe come correzione di sicurezza: niente CVE, niente advisory, niente backport sul ramo 7.x, che all'epoca era ancora supportato. La falla è rimasta aperta lì per oltre tre anni, mentre risultava chiusa in tutte le versioni successive.

Proxmox VE 7.x è end-of-life da luglio 2024. A fine agosto 2026 qualcuno ha ritrovato quella correzione silenziosa nel codice sorgente, l'ha letta al contrario, ne ha ricavato un metodo di attacco e l'ha scatenato sul parco installato rimasto indietro. Non è uno zero-day: è un n-day, una falla vecchia trasformata in arma contro macchine che hanno smesso di ricevere aggiornamenti.

Chi è vulnerabile

La linea di demarcazione è netta:

  • libpve-access-control da 7.0-7 fino a (esclusa) 8.0.4 — vulnerabile. Copre Proxmox VE da 7.0 a 7.4 e le primissime installazioni 8.0 mai aggiornate.
  • 8.0 aggiornata, 8.1-8.4, 9.x — non vulnerabili.

Due precondizioni devono valere contemporaneamente, e ciascuna delle due è un'occasione di difesa: l'interfaccia di gestione sulla porta 8006 deve essere raggiungibile dall'attaccante, e l'account bersaglio deve essere privo di secondo fattore.

Cosa fanno gli attaccanti

Lo sfruttamento non è opera di un solo gruppo. Ne risultano attivi almeno due profili: uno che distribuisce ransomware — storage cifrato e richiesta di riscatto — e uno che installa cryptominer per monetizzare in silenzio la CPU dell'hypervisor. Entrambi condividono una cura particolare nel cancellare le tracce, ed è proprio l'attività anti-forense a fornire gli indicatori di compromissione migliori: file di log sostituiti da collegamenti simbolici a /dev/null (auth.log, wtmp, btmp, lastlog, secure), distruzione di /var/lib/dpkg/status, cancellazione integrale dei log preesistenti. Fra gli artefatti riportati dagli utenti colpiti: il file /var/lib/systemd/PVE-1 e il servizio PVE-1.service, con connessioni in uscita verso il mining pool gulf.moneroocean.stream sulla porta 20004.

Cosa significa per le aziende italiane

Il primo punto è che Proxmox in Italia è molto più diffuso di quanto suggeriscano le statistiche di mercato. È la scelta naturale di chi ha bisogno di virtualizzare senza pagare le licenze VMware — e la migrazione di massa da VMware degli ultimi due anni ha allargato ulteriormente questa platea. Piccole e medie imprese, studi professionali, software house, scuole, comuni, laboratori interni di enti pubblici: ovunque ci sia un reparto IT ridotto all'osso e un budget che non prevede rinnovi, c'è una probabilità concreta che ci sia anche un host Proxmox installato anni fa e mai più toccato. Nel nostro tessuto produttivo il rapporto tra numero di server e numero di persone che li amministrano è particolarmente sfavorevole, ed è esattamente in quel rapporto che nascono gli host dimenticati.

Il secondo punto, ed è quello che rende questo incidente diverso da una normale patch da applicare: qui il bersaglio non sono i sistemi aggiornati, sono quelli di cui nessuno ricorda l'esistenza. Un'azienda con un processo di patching funzionante è già protetta e probabilmente non se ne è nemmeno accorta. Il rischio è concentrato altrove: sull'hypervisor di test diventato produzione, sulla macchina lasciata dal consulente che se n'è andato tre anni fa, sul nodo secondario che «serviva solo per i backup». La domanda giusta da porsi oggi non è «ho applicato la patch?» ma «che cosa, dal lato Internet, risponde a mio nome senza che io l'abbia deciso?».

Il terzo punto riguarda il moltiplicatore di danno. Un hypervisor compromesso non è un server compromesso: è tutto il parco macchine che ci gira sopra. Il gestionale, il file server, il domain controller, il backup — se il repository di backup è una VM sullo stesso nodo, cosa tutt'altro che rara nelle installazioni piccole, l'attaccante cifra i dati e la loro unica copia con lo stesso comando. È la differenza tra un incidente e la chiusura dell'azienda per settimane.

Il quarto punto è una lezione che vale ben oltre Proxmox: una correzione rilasciata senza etichetta di sicurezza protegge meno di una correzione annunciata. Chi applica tutti gli aggiornamenti è coperto senza saperlo; chi decide, in assenza di annunci, che «questo mese non c'è nulla di urgente», resta vulnerabile credendo il contrario. Il silenzio del 2023 è parte integrante della storia del 2026. Per chi valuta i fornitori software, è un criterio da aggiungere alla lista: come comunica le vulnerabilità che corregge?

Il quinto punto, infine, riguarda le password. Nel caso archetipico raccontato sul forum, l'utente colpito aveva una password di root di trenta caratteri. Non è servita a nulla: la falla la password non la sbaglia, la salta. Vale come promemoria sul perché il secondo fattore sugli account amministrativi non è una raffinatezza da grandi organizzazioni. Qui è letteralmente la contromisura specifica: un account con TOTP o WebAuthn attivo non è aggirabile con questa vulnerabilità.

Il contesto normativo

Per un soggetto in perimetro NIS2, la compromissione dell'hypervisor che ospita i sistemi a supporto del servizio è un candidato molto solido a incidente significativo: scattano il pre-allarme al CSIRT Italia entro 24 ore e la notifica entro 72 ore. Vale la pena ricordare che la gestione delle vulnerabilità e la manutenzione dei sistemi rientrano fra le misure minime richieste dall'articolo 24 del D.lgs. 138/2024: mantenere in produzione un hypervisor end-of-life da oltre due anni è una carenza difficile da giustificare in sede ispettiva, a prescindere dall'esito dell'incidente.

Sul piano GDPR, se sull'host girano macchine che trattano dati personali — e nella pratica ne girano quasi sempre — un accesso root non autorizzato con cifratura dei dati configura una violazione con impatto su riservatezza e disponibilità. La valutazione ai sensi dell'articolo 33 va fatta subito, con l'orologio delle 72 ore che parte dal momento in cui si acquisisce consapevolezza del fatto. Un elemento pratico da tenere presente: se l'attaccante ha cancellato i log, ricostruire quali dati siano stati effettivamente esfiltrati diventa molto difficile, e questo si riflette sul contenuto della notifica al Garante e sulla valutazione del rischio per gli interessati.

Per le entità finanziarie soggette a DORA, un hypervisor è per definizione un asset ICT a supporto di funzioni aziendali: l'incidente va classificato secondo i criteri del regolamento e, se grave, segnalato all'autorità competente.

Cosa fare subito

  • Togliere la porta 8006 da Internet, adesso. È la misura che interrompe l'attacco a prescindere dalla versione installata. L'accesso al piano di gestione deve passare da VPN, bastion host o allowlist di indirizzi IP. Se doveste fare una cosa sola, è questa.
  • Verificare la versione del pacchetto sull'host, che è l'arbitro più affidabile del numero mostrato dall'interfaccia: dpkg-query -W -f '${Version}\n' libpve-access-control. Sotto la 8.0.4, il sistema è vulnerabile.
  • Attivare il secondo fattore su root@pam e su tutti gli account amministrativi. Non è solo buona igiene: è la contromisura diretta a questa specifica falla.
  • Applicare la correzione. Sui rami supportati basta aggiornare. Proxmox ha reso disponibile anche una patch tampone che ripristina la validazione del challenge, per gli ambienti che non possono migrare in tempi brevi — è un cerotto, non un aggiornamento.
  • Pianificare l'uscita da Proxmox VE 7.x verso un ramo supportato (8.4.x o 9.x). È l'unica risposta duratura: questa falla è un sintomo, il prossimo n-day troverà la stessa macchina altrettanto indifesa.
  • Cercare le tracce di intrusione: grep 'POST /api2/json/access/ticket' /var/log/pveproxy/access.log* incrociando con gli IP legittimi; find /var/log -maxdepth 3 -type l -ls per individuare log trasformati in symlink; verificare l'integrità di /var/lib/dpkg/status; controllare crontab -l, /etc/cron.*, /root/.ssh/authorized_keys, processi che consumano CPU in modo anomalo, utenti sconosciuti nella gestione permessi di Proxmox, VM o container non riconosciuti.
  • Attenzione a un punto scomodo: se l'attaccante ha fatto il suo lavoro, i log non ci sono più. Su un host vulnerabile ed esposto, l'assenza di tracce non è prova di innocenza.
  • Se la compromissione è confermata, non ripulire: ricostruire. Isolare la macchina dalla rete, preservare quel che si può per l'analisi, ripristinare i guest da backup verificati e precedenti all'intrusione, reinstallare l'host da zero e ruotare tutti i segreti che vi siano transitati: password, chiavi API, token, chiavi SSH, credenziali dei guest.

Un'ultima osservazione che va oltre il caso specifico. Una console di amministrazione esposta su Internet è una bomba a orologeria qualunque sia la marca: vSphere, un IPMI di scheda madre, un controller di storage, un pannello di gestione. Sono superfici ad altissimo valore, dove la minima falla di autenticazione non regala un piede nella porta, ma l'intera casa. Delle due condizioni necessarie a questo attacco, l'esposizione della 8006 è quella che l'organizzazione controlla interamente — mentre sull'esistenza del bug non ha alcuna voce in capitolo.