CVE-2026-112816: Grave Bypass dell’Autenticazione in LXD e MicroCloud Consente il Controllo del Cluster

Canonical ha rilasciato aggiornamenti di sicurezza per affrontare CVE-2026-112816, una vulnerabilità critica di bypass dell’autenticazione che interessa LXD e MicroCloud. Il difetto ha un punteggio CVSS massimo di 10,0 e può consentire a un attaccante remoto non autenticato di impersonare un client TLS fidato senza possedere la chiave privata di quel client.

Lo sfruttamento riuscito può fornire accesso all’API LXD o MicroCloud con i privilegi assegnati all’identità impersonata. Quando l’identità fidata ha permessi sufficienti, un aggressore può ottenere pieno accesso al cluster, alle macchine virtuali gestite e potenzialmente accesso a livello root all’host sottostante.

La vulnerabilità deriva da una convalida impropria delle catene di certificati client utilizzate per l’autenticazione TLS reciproca. Invece di autenticare solo il certificato foglia per cui il client dimostra il possesso della chiave privata corrispondente, le implementazioni vulnerabili confrontano ogni certificato fornito nella catena controllata dal client con quelli di fiducia.

Un aggressore che può raggiungere l’API HTTPS e ottenere il certificato pubblico di un client già fidato può quindi aggiungere quel certificato dietro un certificato foglia controllato dall’attaccante e essere accettato come identità fidata.

Canonical ha divulgato il problema alla fine di ottobre 2026 dopo che la vulnerabilità è stata segnalata dal progetto Incus. Sono ora disponibili versioni corrette di LXD e MicroCloud, e si consiglia vivamente agli amministratori di aggiornare immediatamente.

La falla è particolarmente significativa negli ambienti infrastrutturali perché LXD gestisce container di sistema e macchine virtuali, mentre MicroCloud coordina l’infrastruttura clusterizzata. Il compromesso di un’identità amministrativa può quindi estendersi oltre un singolo servizio e fornire controllo sui workload o sull’host stesso.

Per il rilevamento del CVE-2026-112816, i team di sicurezza dovrebbero prioritizzare l’identificazione delle API HTTPS di LXD e MicroCloud accessibili via Internet o rete, rivedere i certificati client di fiducia e correlare l’autenticazione basata su certificato riuscita con sistemi sorgente inaspettati o operazioni amministrative insolite.

La piattaforma AI-Native Detection Intelligence di SOC Prime consente ai team di sicurezza di rafforzare la copertura per lo sfruttamento e il comportamento post-compromissione su rete, Linux, cloud, container e telemetria dell’identità.

Contatta le vendite

Fai clic su Esplora Rilevamenti per accedere ai contenuti di rilevamento pertinenti e alla logica di caccia. Per rilevare CVE-2026-112816, i difensori dovrebbero combinare l’inventario delle versioni vulnerabili con il monitoraggio dell’accesso API, la telemetria di autenticazione dei certificati e l’attività amministrativa sospetta che coinvolge container, macchine virtuali o configurazione del cluster.

Analisi CVE-2026-112816

CVE-2026-112816 è una vulnerabilità di convalida impropria dei certificati nel listener HTTPS utilizzato da Canonical LXD e MicroCloud.

Entrambi i prodotti possono utilizzare il TLS reciproco per autenticare i client remoti. Nel normale comportamento mTLS, il client che si collega presenta un certificato e dimostra la proprietà della chiave privata associata al certificato usato come foglia della catena TLS.

Il problema sorge perché le implementazioni vulnerabili di LXD e MicroCloud ispezionano più di quel solo certificato foglia autenticato.

Secondo Canonical, la logica di autenticazione remota dell’API confrontava tutti i certificati presentati da un client con le voci nel negozio di certificati fidati. Tuttavia, TLS dimostra il possesso della chiave privata solo per il certificato foglia. I certificati aggiuntivi nella catena presentata sono forniti dal client e non dimostrano indipendentemente la proprietà delle loro chiavi private corrispondenti.

Questo crea un divario nell’autenticazione.

Un attaccante può generare un certificato e una chiave privata che controllano, usare quel certificato come foglia e aggiungere il certificato pubblico di un client fidato altrove nella catena presentata. Il server vulnerabile potrebbe trovare il certificato fidato e associare la connessione a quell’identità fidata anche se l’attaccante non possiede la sua chiave privata.

I dettagli per CVE-2026-112816 mostrano quindi che lo sfruttamento dipende principalmente da due prerequisiti:

• L’attaccante può raggiungere l’API HTTPS di LXD o MicroCloud.
• L’attaccante possiede il certificato pubblico di un’identità già fidata dal target.

La chiave privata del client fidato non è richiesta.

Questa distinzione spiega la gravità critica della vulnerabilità. Si prevede che l’autenticazione basata su certificato dimostri il possesso di una chiave privata segreta, ma la logica coinvolta consente effettivamente al solo possesso del certificato pubblico di soddisfare parte della decisione di fiducia.

Un’installazione standalone di LXD non espone per impostazione predefinita la sua API HTTPS remota. The Hacker News osserva che LXD normalmente ascolta solo sul suo socket Unix locale a meno che un amministratore non abiliti l’accesso alla rete, ad esempio tramite la configurazione core.https_address.

Ciò significa che non tutte le installazioni vulnerabili di LXD sono sfruttabili in remoto da un altro host.

L’esposizione diventa significativamente più alta quando gli amministratori abilitano l’API su una rete di gestione o la espongono a Internet.

MicroCloud presenta un altro scenario di attacco rilevante. Canonical afferma che un attaccante che può intercettare il certificato TLS pubblico di una macchina che si unisce a un cluster MicroCloud può successivamente autenticarsi come quel membro unito.

CVE-2026-112816 colpisce le versioni vulnerabili di Canonical LXD tra cui 4.0.14, 5.0.10, 5.21.8 e 6.9 prima delle loro corrispondenti versioni correttive.

Canonical elenca queste versioni patchate di LXD:

• LXD 6.10.1 per il canale 6/stable
• LXD 5.21.9 per 5.21/stable
• LXD 5.0.11 per 5.0/stable
• LXD 4.0.15 per 4.0/stable

Per MicroCloud, le versioni corrette sono:

• MicroCloud 3.4.1 per 3/stable
• MicroCloud 2.1.5 per 2/stable

La registrazione CVE di Ubuntu descrive lo sfruttamento riuscito come consentendo a un attaccante non autenticato di autenticarsi come un client fidato e ottenere pieno accesso al cluster e alle macchine virtuali gestite tramite una catena di certificati elaborata.

Il punteggio CVSS massimo di 10,0 riflette l’accessibilità di rete, la bassa complessità dell’attacco, nessun privilegio richiesto e nessuna interazione dell’utente richiesta, combinati con un potenziale impatto elevato su riservatezza, integrità e disponibilità.

L’impatto dipende in ultima analisi dai privilegi dell’identità impersonata.

Un’identità ristretta può fornire capacità API limitate. Un client altamente privilegiato o un’identità di cluster possono fornire un accesso sostanzialmente maggiore.

Canonical avverte esplicitamente che l’impersonazione di un utente fidato privilegiato può portare all’accesso root alla macchina host.

Ciò può potenzialmente consentire a un attaccante di:

• Gestire o modificare container e macchine virtuali.
• Accedere ai workload gestiti attraverso l’ambiente LXD compromesso.
• Modificare la configurazione dell’infrastruttura.
• Creare nuovi workload o modificarne di esistenti.
• Interferire con la disponibilità.
• Accedere ai dati disponibili all’identità impersonata.
• Potenzialmente raggiungere l’host con privilegi a livello root quando sono disponibili sufficienti permessi.

La falla è stata originariamente identificata nel progetto Incus correlato e poi segnalata a Canonical, che ha confermato che lo stesso problema di autenticazione della catena di certificati ha influenzato LXD.

Incus descrive il problema sottostante in modo simile: il server richiedeva certificati client senza verificare l’intera catena presentata, mentre i controlli di fiducia iteravano su ogni certificato peer fornito anziché limitare l’autenticazione al certificato foglia effettivo. Incus ha risolto il problema nella versione 7.6.0.

La vulnerabilità sembra essere esistita per un periodo esteso. Incus afferma che la corrispondente logica di autenticazione era presente sin dal rilascio iniziale. La comunicazione pubblica di Canonical non fornisce una data esatta per quando il comportamento vulnerabile di LXD è stato introdotto per la prima volta.

A partire dal 2 novembre 2026, un PoC CVE-2026-112816 indipendente e una riproduzione in laboratorio sono stati pubblicati pubblicamente. Ciò rappresenta un cambiamento rispetto al rapporto di The Hacker News pubblicato il 1 novembre, che riportava che non era stato ancora rilasciato nessun exploit funzionante. La riproduzione pubblica è apparsa dopo la divulgazione e non è la ricerca originale della vulnerabilità.

Canonical e i rapporti di riferimento non hanno indicato che la vulnerabilità sia stata sfruttata in attacchi reali.

The Hacker News riporta che il problema non era noto essere sfruttato alla data della valutazione U.S. CISA del 30 ottobre e non era incluso nel catalogo delle Vulnerabilità Sfruttate Note di CISA in quel momento.

Non ci sono quindi IOC CVE-2026-112816 specifici della campagna come indirizzi IP maligni confermati, domini, hash di malware o infrastrutture di attaccanti note associate allo sfruttamento.

I difensori dovrebbero invece concentrarsi sull’esposizione alle vulnerabilità e sul comportamento.

Le potenziali opportunità di caccia includono:

• Connessioni remote alle API HTTPS di LXD o MicroCloud da sistemi inaspettati.
• Autenticazione API riuscita proveniente da reti non normalmente utilizzate da amministratori fidati.
• Un’identità di certificato fidata che appare da più sistemi sorgente non correlati.
• Attività amministrativa API che non corrisponde al proprietario previsto di un certificato.
• Creazione, eliminazione o modifica inaspettata di container e macchine virtuali.
• Cambiamenti nelle voci di certificato fidato.
• Nuovi membri del cluster o modificati.
• Modifiche inaspettate allo storage, networking, profili, progetti o configurazione delle istanze.
• Operazioni privilegiate che si verificano subito dopo un’autenticazione insolita basata su certificato.
• Connessioni API a interfacce di gestione che non erano destinate ad essere remotamente accessibili.

Le organizzazioni dovrebbero anche inventariare i certificati fidati associati a ex amministratori, host ritirati, sistemi di automazione e membri del cluster.

Poiché lo sfruttamento richiede il certificato pubblico anziché la chiave privata, i difensori non dovrebbero trattare la riservatezza delle sole chiavi private come protezione sufficiente contro questa specifica vulnerabilità.

Il monitoraggio dovrebbe anche tenere conto delle reti di gestione condivise.

Un’API che non è esposta direttamente a Internet pubblico può ancora essere sfruttabile da un attaccante che ha già ottenuto un punto d’appoggio su un altro sistema in grado di raggiungere l’interfaccia di gestione.

Ciò rende particolarmente rilevante il movimento laterale. Una workstation compromessa, un server, un runner CI/CD, un host di gestione o un workload cloud con accesso di rete all’API LXD potrebbe fornire la posizione necessaria per sfruttare un sistema altrimenti esposto internamente.

Mitigazione CVE-2026-112816

Canonical raccomanda di aggiornare immediatamente le implementazioni LXD e MicroCloud affette alle ultime versioni corrette.

Per le distribuzioni basate su Snap, gli amministratori possono aggiornare usando:

sudo snap refresh lxd

e:

sudo snap refresh microcloud

Dopo il refresh, verificare la versione effettivamente installata anziché presumere che l’aggiornamento sia stato applicato correttamente.

Canonical ha notato durante la divulgazione che alcuni rilasci puntuali di LXD stavano progredendo dai canali candidate agli stable. Gli amministratori dovrebbero quindi confermare esplicitamente che il loro sistema sta eseguendo una delle versioni corrette.

La mitigazione primaria per CVE-2026-112816 è l’aggiornamento a:

Prodotto	Versione corretta
LXD 6.x	6.10.1
LXD 5.21	5.21.9
LXD 5.0	5.0.11
LXD 4.0	4.0.15
MicroCloud 3.x	3.4.1
MicroCloud 2.x	2.1.5

Canonical non ha pubblicato una soluzione alternativa basata sulla configurazione che elimini completamente il difetto di autenticazione sottostante.

Se l’aggiornamento immediato è impossibile, restringere l’accesso di rete all’API HTTPS il più aggressivamente possibile in base ai requisiti operativi.

Solo gli host di gestione autorizzati e l’infrastruttura di fiducia dovrebbe essere in grado di stabilire connessioni al listener.

Per le installazioni di LXD che non richiedono gestione remota, gli amministratori devono valutare se l’API di rete deve rimanere abilitata.

Per gli ambienti che richiedono l’accesso remoto:

• Limitare l’API utilizzando firewall host o di rete.
• Consentire connessioni solo da reti di gestione dedicate.
• Evitare di esporre l’API direttamente a Internet pubblico.
• Utilizzare l’accesso amministrativo tramite VPN o bastion, se appropriato.
• Segmentare l’infrastruttura di gestione dei container e della virtualizzazione da reti utente.
• Monitorare tutte le richieste API amministrative riuscite.
• Rivedere i certificati fidati e rimuovere voci che non sono più necessarie.

Questi controlli riducono l’esposizione ma non correggono la logica di validazione dei certificati vulnerabile.

Le organizzazioni che eseguono MicroCloud dovrebbero prioritizzare l’aggiornamento di tutti i membri del cluster rilevanti e rivedere l’attività recente di adesione per sistemi o identità di certificati inaspettati.

Gli amministratori dovrebbero anche rivedere i loro archivi di certificati fidati.

Rimuovere i certificati appartenenti a host dismessi, ex amministratori, sistemi di automazione inutilizzati o identità che non necessitano più di accesso.

Quando viene scoperta un’attività sospetta, investigare l’host e il cluster colpiti prima di ruotare le credenziali o modificare le prove.

Fonti rilevanti di telemetria possono includere:

• Log di servizio LXD e MicroCloud
• Log di sistema Linux
• Registri del flusso di rete e firewall
• Telemetria del proxy inverso, se applicabile
• Dati EDR dell’host
• Log di rete cloud
• Configurazione del cluster e cronologia dei membri
• Registrazioni dei cambiamenti amministrativi

Cercare creazione, modifica, eliminazione inaspettata di istanze, attività di snapshot, operazioni di storage, cambiamenti di rete e aggiornamenti di configurazione.

Se si sospetta lo sfruttamento e un’identità di certificato privilegiata è stata impersonata, i difensori dovrebbero trattare la potenziale compromissione a livello di host con serietà, poiché Canonical conferma che l’accesso a root può essere possibile a seconda dei permessi dell’identità della vittima.

I responsabili degli incidenti dovrebbero preservare le prove rilevanti e ispezionare il sistema per persistenza, account o certificati non autorizzati, servizi modificati, nuovi workload, processi sospetti e comunicazioni di rete anormali in uscita.

Le organizzazioni che utilizzano Incus anziché Canonical LXD dovrebbero aggiornare separatamente a Incus 7.6.0 o alla versione correttiva supportata pertinente, poiché il progetto correlato è stato affetto dallo stesso problema di fiducia della catena di certificati.

Ubuntu nota anche che le sue versioni LXD archiviate elencate attualmente per le release di Ubuntu non vengono inviati tramite il percorso di pacchetto interessato o non sono interessate, mentre la guida alla sicurezza di Canonical si concentra sulle release Snap. Gli amministratori dovrebbero comunque verificare la reale distribuzione e versione di LXD in esecuzione nel loro ambiente anziché presumere l’esposizione basandosi solo sulla release di Ubuntu.

Disclaimer: I contenuti di rilevamento potrebbero non essere disponibili per ogni CVE. Controlla la piattaforma SOC Prime per la copertura attuale. Se i rilevamenti pertinenti non sono ancora disponibili, verifica di nuovo poiché nuove intelligence sulle minacce e contenuti di rilevamento vengono continuamente aggiunti.