Vulnerabilitate CVSS 10 în LXD și MicroCloud permite uzurparea clienților de încredere

Canonical a publicat corecții pentru o vulnerabilitate critică de autentificare în LXD și MicroCloud, prin care un atacator poate fi acceptat drept client API de încredere fără să dețină vreodată cheia privată a acelui client. Identificată ca CVE-2026-112816, problema are scorul CVSS maxim de 10,0.

Ce s-a întâmplat

LXD și MicroCloud autentifică clienții de la distanță prin TLS mutual: clientul prezintă un certificat, iar serverul îl acceptă dacă acel certificat se află în lista sa de încredere (trust store).

Problema ținea de ce certificat verifica serverul. În timpul negocierii TLS, clientul dovedește că deține cheia privată doar pentru primul certificat (leaf) din lanțul trimis. Restul lanțului conține pur și simplu ce alege clientul să atașeze. Codul vulnerabil compara fiecare certificat din lanț cu lista de încredere — așa că un atacator putea prezenta propriul certificat leaf, atașa în spatele lui certificatul public al unui client de încredere și era tratat drept acel client.

Certificatele publice nu sunt secrete, iar asta face problema atât de gravă: singurele condiții reale sunt acces în rețea la API-ul HTTPS și o copie a certificatului unui client de încredere.

De ce contează

Odată acceptat, atacatorul preia drepturile clientului uzurpat asupra clusterului, a instanțelor și a mașinilor virtuale. Dacă identitatea respectivă este privilegiată, Canonical avertizează că rezultatul poate fi acces root pe mașina gazdă.

Expunerea depinde de configurare:

• LXD de sine stătător ascultă implicit doar pe un socket Unix local. Devine accesibil din rețea numai dacă un administrator setează core.https_address.
• MicroCloud, care unește mai multe mașini LXD într-un singur cluster, are un punct slab suplimentar: un atacator care interceptează certificatul public al unui membru în momentul în care acesta se alătură clusterului se poate autentifica ulterior în locul lui.

Sunt afectate LXD 4.0.14, 5.0.10, 5.21.8 și 6.9, precum și versiunile anterioare corecțiilor respective. Aceeași vulnerabilitate exista și în Incus, fork-ul comunitar al LXD, unde a fost remediată în versiunea 7.6.0. Pachetele LXD din arhiva Ubuntu sunt listate ca neafectate sau nedistribuite, deci corecțiile vin prin pachetele snap.

Deocamdată nu există dovezi publice de exploatare. O evaluare CISA (SUA) din 30 octombrie o marchează ca neexploatată cunoscut, nu figurează în catalogul CISA Known Exploited Vulnerabilities și nu a fost publicat niciun exploit funcțional. Având în vedere cât de simplă este tehnica, nu ne așteptăm ca această fereastră să rămână deschisă mult timp.

Ce trebuie făcut

1. Actualizați acum. Pe instalările snap, rulați sudo snap refresh lxd și sudo snap refresh microcloud. Versiuni corectate:

2. Verificați versiunea instalată efectiv. La momentul publicării avizului, versiunile LXD corectate erau încă în curs de promovare din canalul candidate în stable — confirmați cu snap list în loc să presupuneți că actualizarea a adus corecția.
3. Restricționați accesul la API. Nu există o soluție prin configurare. Până la actualizare, limitați cine poate ajunge la portul HTTPS LXD/MicroCloud (implicit 8443) prin reguli de firewall, VPN sau o rețea de management — și nu îl expuneți niciodată pe internet.
4. Utilizatorii Incus ar trebui să treacă la 7.6.0, care închide această problemă împreună cu alte 17 corecții de securitate.
5. Revizuiți lista de încredere și eliminați certificatele de client de care nu mai aveți nevoie; fiecare certificat de încredere este o identitate care poate fi uzurpată.

Astfel de vulnerabilități pot fi exploatate doar dacă API-ul este accesibil, așa că a ști exact ce interfețe de administrare expuneți reprezintă jumătate din apărare. Serviciul nostru de Attack Surface Management cartografiază continuu gazdele și serviciile expuse pe internet și semnalează API-urile de administrare și orchestrare expuse, precum cel al LXD, înainte să le descopere un atacator.