O vulnerabilitate cu scorul maxim CVSS 10.0 le-ar fi permis atacatorilor să se autentifice în LXD și MicroCloud ca un client de încredere, fără să dețină cheia privată a acestuia. Pentru atac era nevoie de acces la API-ul HTTPS și de certificatul public al unui client deja autorizat; odată intrați, atacatorii puteau accesa clusterul și mașinile virtuale, iar un cont privilegiat putea deschide calea către acces root pe gazdă, avertizează Canonical.
Verificarea certificatelor a confundat identitatea clientului
LXD și MicroCloud permit clienților aflați la distanță să folosească API-urile prin TLS mutual, mecanism în care clientul prezintă un certificat pentru a-și demonstra identitatea. Serverul consideră de încredere certificatele înscrise în depozitul său de încredere, adică lista identităților pe care le acceptă.
Problema era în felul în care serverul verifica certificatele primite: le compara pe toate cu depozitul de încredere. Însă conexiunea TLS demonstrează că solicitantul deține cheia privată doar pentru primul certificat din lanț, certificatul final, numit leaf; certificatele suplimentare sunt alese și trimise de client.
Astfel, atacatorul putea atașa certificatul public al unui client de încredere în spatele propriului certificat, iar serverul îl putea accepta drept acel client. Certificatul public nu este secret; cheia privată, pe care atacatorul nu trebuia să o dețină, este cea care dovedește controlul asupra certificatului final.
Sursă foto: blogger.googleusercontent.com
API-ul expus și clusterele MicroCloud măreau riscul
Exploatarea necesita două condiții: atacatorul să poată ajunge prin rețea la API-ul HTTPS și să obțină certificatul public al unui client pe care serverul îl considera deja de încredere. În cazul unui server LXD instalat separat, API-ul nu este expus implicit: serverul ascultă doar pe un socket local, dacă administratorul nu activează accesul prin rețea cu setarea core.https_address.
MicroCloud, care reunește într-un cluster mai multe mașini ce rulează LXD, are un scenariu de risc specific. Potrivit Canonical, un atacator care poate captura certificatul public al unui membru în timp ce acesta se alătură clusterului îl poate folosi ulterior pentru a se autentifica în numele acelui membru.
Înregistrarea CVE indică drept afectate versiunile LXD 4.0.14, 5.0.10, 5.21.8 și 6.9, fiecare înaintea versiunii corectate care îi urmează. Canonical a publicat remedieri pentru LXD și MicroCloud; pachetele LXD din arhiva Ubuntu sunt marcate ca neafectate sau neincluse, iar versiunile remediate sunt distribuite ca snap-uri.
Incus a semnalat problema, iar Canonical a confirmat-o
Vulnerabilitatea, identificată drept CVE-2026-112816, nu a fost descoperită inițial de Canonical. Proiectul Incus, apărut ca o bifurcație comunitară a LXD, a raportat problema, după care Canonical a confirmat că și produsele sale sunt afectate; Incus a remediat aceeași vulnerabilitate în versiunea 7.6.0.
La momentul avertismentului Canonical, versiunile punctuale LXD corectate erau încă în curs de promovare din canalul candidate în canalul stable. De aceea, simpla rulare a actualizării nu garantează că remedierea a ajuns deja la instalare: administratorii trebuie să verifice versiunea efectiv instalată.
Până acum nu există indicii publice că vulnerabilitatea ar fi fost exploatată. Evaluarea CISA din 30 octombrie consemnează că exploatarea nu este cunoscută; CVE-ul nu apare în catalogul Known Exploited Vulnerabilities, iar un exploit funcțional nu a fost publicat.
Actualizarea este remediul, iar limitarea accesului reduce expunerea
Pe instalările snap, comenzile recomandate sunt sudo snap refresh lxd și sudo snap refresh microcloud. După actualizare, echipele trebuie să confirme versiunile instalate și să se asigure că au ajuns la edițiile remediate, ținând cont de distribuirea graduală din candidate în stable.
Canonical nu a indicat o soluție temporară de configurare pentru LXD. Deoarece atacul presupune acces la API, restricționarea sistemelor și utilizatorilor care pot ajunge la listener reduce riscul până la instalarea remedierii; proiectul Incus a transmis, la rândul său, că nu există o corecție de configurare și că măsura disponibilă este limitarea accesului la rețea.
Utilizatorii Incus ar trebui să treacă la versiunea 7.6.0, care remediază această problemă și alte 17 vulnerabilități de securitate. Pentru administratorii LXD și MicroCloud, prioritățile sunt verificarea expunerii API-ului, restricționarea accesului la acesta și confirmarea instalării versiunilor corectate.
