LXD e MicroCloud, falla CVSS 10: Entra ID accelera l’addio agli SMS

🛡️ Executive Summary

• LXD e MicroCloud, CVSS 10.0: CVE-2026-112816 permette di impersonare un client attendibile attraverso il suo certificato TLS pubblico, senza possedere la chiave privata.
• Canonical pubblica le patch: corrette le principali serie LXD e MicroCloud. Le API HTTPS esposte devono essere aggiornate e protette; non risultano sfruttamenti confermati.
• Microsoft Entra ID cambia autenticazione: SMS e chiamate gestiti da Microsoft saranno ritirati dal 1° febbraio 2027, con scadenza differita al 1° luglio per Global Administrator e utenti esterni.

CVE-2026-112816 espone le infrastrutture basate su Canonical LXD e MicroCloud a una vulnerabilità critica di autenticazione, classificata CVSS 10.0, che permette a un aggressore di impersonare un client considerato attendibile senza possederne la chiave privata. Il problema riguarda la verifica delle catene di certificati TLS e può consentire, quando l’identità impersonata dispone dei privilegi necessari, di ottenere persino l’accesso root all’host. Canonical ha distribuito versioni corrette, mentre non risultano evidenze pubbliche di sfruttamento attivo. Sul fronte della gestione delle identità aziendali, Microsoft rinnova invece l’avvertimento agli amministratori di Entra ID: dal 1° febbraio 2027 inizierà la dismissione dell’autenticazione tramite SMS e chiamate vocali fornite direttamente dalla società, imponendo il passaggio a metodi alternativi oppure a operatori telefonici esterni supportati. Due sviluppi differenti che evidenziano la centralità dell’identità digitale nella sicurezza delle infrastrutture.

CVE-2026-112816 aggira l’autenticazione TLS di LXD e MicroCloud

Secondo il bollettino ufficiale di Canonical, CVE-2026-112816 interessa la verifica dei certificati client utilizzati dalle API HTTPS di LXD e MicroCloud. I due prodotti consentono a sistemi e amministratori remoti di autenticarsi attraverso mutual TLS, meccanismo nel quale il server confronta l’identità del client con quelle registrate nel proprio archivio delle identità attendibili. La vulnerabilità nasce da un errore nella valutazione della catena presentata durante l’handshake: il server considera anche i certificati intermedi, mentre la connessione dimostra il possesso della chiave privata soltanto del primo certificato, denominato leaf certificate. Un aggressore può quindi presentare un proprio certificato e aggiungere successivamente quello pubblico di un client attendibile, inducendo il server ad attribuirgli l’identità di quest’ultimo. Non è necessario sottrarre la chiave privata della vittima, ma occorrono il suo certificato pubblico e la possibilità di raggiungere l’API HTTPS. Il difetto compromette così il controllo dell’identità sul quale si basano le autorizzazioni amministrative del sistema.

Il certificato pubblico diventa una credenziale sufficiente per l’impersonificazione

La gravità della vulnerabilità dipende soprattutto dalle autorizzazioni dell’identità impersonata. Chi riesce ad autenticarsi come client attendibile eredita i relativi privilegi e può interagire con le risorse gestite da LXD o MicroCloud, comprese macchine virtuali, container e componenti del cluster. Se l’account impersonato dispone di privilegi amministrativi, l’attacco può arrivare al controllo root dell’host, trasformando un errore nell’autenticazione API in un problema che interessa l’intera infrastruttura. Non tutte le installazioni presentano però la stessa esposizione. Un server LXD autonomo utilizza normalmente un socket locale e non rende raggiungibile l’API HTTPS sulla rete finché l’amministratore non configura esplicitamente core.https_address. MicroCloud introduce uno scenario più delicato perché collega più host attraverso un’infrastruttura distribuita: durante l’ingresso di un nuovo membro nel cluster, l’intercettazione del suo certificato pubblico potrebbe permetterne successivamente l’impersonificazione. L’origine della segnalazione è collegata a Incus, fork comunitario di LXD, che ha corretto la stessa vulnerabilità nella versione 7.6.0. La vicenda richiama l’importanza dell’isolamento già affrontata nell’approfondimento su Ubuntu Workshop e gli ambienti di sviluppo basati su LXD.

Canonical corregge sei rami software e invita ad aggiornare gli snap

Le versioni corrette indicate da Canonical comprendono LXD 6.10.1 per il canale 6/stable, 5.21.9 per 5.21/stable, 5.0.11 per 5.0/stable e 4.0.15 per 4.0/stable. MicroCloud richiede invece 3.4.1 sul canale 3/stable oppure 2.1.5 sul canale 2/stable. Gli aggiornamenti vengono distribuiti attraverso il sistema snap e possono essere richiesti con sudo snap refresh lxd e sudo snap refresh microcloud, verificando successivamente che la versione installata corrisponda effettivamente a quella corretta.

Canonical segnala infatti un rilascio progressivo dai canali candidate a stable, circostanza che rende insufficiente presumere l’avvenuta correzione dopo il semplice aggiornamento. Non è stato pubblicato un workaround capace di risolvere la validazione difettosa dei certificati: limitare l’accesso di rete all’API HTTPS riduce la superficie d’attacco, ma non sostituisce la patch. La valutazione CISA del 30 ottobre non segnala sfruttamenti conosciuti e la vulnerabilità non risulta inclusa nel catalogo KEV. La priorità riguarda quindi la prevenzione di una compromissione potenzialmente molto grave, non la risposta a una campagna offensiva già confermata.

Microsoft Entra ID ritira SMS e chiamate dal febbraio 2027

La seconda novità riguarda Microsoft Entra ID e una trasformazione già annunciata durante l’estate, sulla quale Microsoft è tornata con una comunicazione agli amministratori il 27 ottobre 2026. La documentazione ufficiale sulla dismissione di SMS e chiamate vocali conferma che dal 1° settembre 2026 le passkey sono diventate l’esperienza di autenticazione predefinita per gli utenti precedentemente abilitati a SMS e chiamate. Dal 1° febbraio 2027 Microsoft interromperà l’erogazione diretta di questi servizi telefonici per la maggior parte degli utenti dei tenant aziendali, mentre Global Administrator e utenti esterni seguiranno una scadenza differita al 1° luglio 2027.

Gli utenti guest interni rientrano invece nella scadenza di febbraio. Il cambiamento non riguarda allo stesso modo Azure AD B2C e gli scenari customer di Microsoft Entra External ID, per i quali sono previste comunicazioni separate. Non si tratta di eliminare ogni forma di autenticazione multifattore, ma di sostituire i canali telefonici gestiti da Microsoft con metodi più resistenti al phishing oppure, dove necessario, con fornitori telefonici esterni. La transizione era stata già anticipata nel precedente approfondimento sulle passkey Entra ID e la dismissione degli SMS nel 2027.

Le passkey sostituiscono codici intercettabili e autenticazione telefonica

La scelta di Microsoft nasce dalla vulnerabilità strutturale dei codici inviati tramite SMS o comunicati attraverso una chiamata. Questi metodi possono essere compromessi attraverso phishing, SIM swapping e ingegneria sociale, mentre le passkey basate su FIDO2 e WebAuthn utilizzano coppie di chiavi crittografiche associate al servizio e non richiedono di comunicare un codice riutilizzabile all’utente. Microsoft supporta credenziali sincronizzate attraverso gestori compatibili, passkey legate al dispositivo, Windows Hello for Business e chiavi hardware FIDO2. Gli amministratori possono individuare gli utenti ancora dipendenti dalla telefonia mediante lo script PowerShell Entra SMS/Voice Policy Scanner, eseguibile con ruoli autorizzati come Global Reader, Authentication Policy Administrator o Security Reader. Chi non avrà predisposto un metodo alternativo potrebbe ricevere, alla scadenza applicabile, una richiesta obbligatoria di registrazione della passkey prima di poter completare l’accesso. Il passaggio deve però essere accompagnato da comunicazioni aziendali verificabili: le campagne criminali che utilizzano false richieste di registrazione delle passkey per sottrarre sessioni Microsoft 365 dimostrano che anche una misura di sicurezza può diventare il pretesto di un attacco di ingegneria sociale.

Microsoft Security Store permette di mantenere SMS e voce con operatori esterni

Le organizzazioni che hanno esigenze normative, contrattuali o operative legate all’autenticazione telefonica potranno continuare a utilizzare SMS e chiamate attraverso un provider gestito dal cliente, selezionato nel Microsoft Security Store. La soluzione viene identificata come Choose Your Own Telephony Provider e comporta la scelta di un fornitore supportato, la configurazione del servizio e la verifica del funzionamento prima delle scadenze. Microsoft indica costi variabili in funzione del provider, del volume dei messaggi e dell’area geografica, mentre la migrazione degli utenti alle passkey non introduce un costo aggiuntivo per il solo trasferimento del metodo di autenticazione. La documentazione distingue inoltre tra autenticazione resistente al phishing e alternative che permettono semplicemente di evitare il canale telefonico: i codici TOTP, ad esempio, rimangono supportati ma non offrono le stesse garanzie delle passkey contro il phishing. Per gli amministratori il percorso operativo consiste nell’individuare gli account ancora legati a SMS e voce, pianificare la registrazione delle credenziali sostitutive, verificare eventuali dipendenze applicative e predisporre una gestione delle emergenze che non si fondi esclusivamente sul vecchio metodo. Il rischio immediato è l’interruzione degli accessi aziendali, non un blocco indiscriminato di tutti i tenant Entra ID.

Cloud e identità digitale richiedono controlli sui meccanismi di fiducia

Le due vicende intervengono su livelli diversi della sicurezza, ma evidenziano un elemento architetturale comune: l’affidabilità di un sistema dipende da come verifica l’identità di chi richiede accesso. Nel caso LXD e MicroCloud, il problema è una verifica incompleta della catena di certificati che può trasformare un documento pubblico in uno strumento di impersonificazione. Nel caso Microsoft Entra ID, la debolezza è invece quella di canali telefonici che non garantiscono una resistenza sufficiente al phishing moderno. Per le organizzazioni che gestiscono infrastrutture cloud e identità aziendali, le priorità sono quindi complementari: applicare le patch ai servizi esposti, limitare le API amministrative, verificare effettivamente le versioni installate e migrare gli account verso fattori di autenticazione resistenti al phishing. Nessuna delle due notizie dimostra che le tecnologie basate sui certificati o sulle passkey siano intrinsecamente insicure. Mostrano piuttosto quanto sia decisivo implementare correttamente la verifica crittografica e non affidare la protezione di sistemi critici a procedure di autenticazione ormai insufficienti.