LXD a MicroCloud: CVSS 10,0 za podvržený certifikát, oprava je ve snapu

Canonical 28. 10. 2026 zveřejnil advisory k CVE-2026-112816: LXD i MicroCloud při vzájemném TLS ověřování porovnávaly proti trust store celý certifikátový řetězec, jenže privátní klíč prokazuje jen první certifikát v řetězci. Stačilo přiložit veřejný certifikát důvěryhodného klienta jako mezistupeň a API přijalo útočníka jako jeho. Opravené snapy vyšly 29. 10. 2026.

Nejde o teorii. Kdo se dostane na HTTPS API a má veřejný certifikát klienta, kterému server věří, vystupuje dál jako on. U privilegovaného účtu to podle Canonicalu znamená root na hostiteli, ne jen v kontejneru.

Co je ve zdroji

• Chyba je v mTLS: server procházel všechny certifikáty, které klient poslal, a každý hledal v trust store. TLS ale prokazuje vlastnictví klíče jen u listu, zbytek řetězce si klient přiloží sám.
• Postižené verze: LXD 4.0.14, 5.0.10, 5.21.8 a 6.9; opravené 4.0.15, 5.0.11, 5.21.9 a 6.10.1, u MicroCloudu 2.1.5 a 3.4.1. Všechny vyšly 29. 10. 2026.
• MicroCloud: kdo zachytí veřejný certifikát člena při připojování do clusteru, přihlásí se pak jako ten člen.
• Chybu nahlásil Incus, který ji opravil ve verzi 7.6.0 z 30. 10. 2026 („Fix cluster certificate chain handling“). Canonical ji pak potvrdil i v LXD.
• Ubuntu balíčky LXD v archivu nejsou nebo nejsou postižené — oprava je jen ve snapu, ne v apt upgrade.
• Zneužití není známé: záznam CVE nese hodnocení CISA z 30. 10. 2026, CVE není v katalogu KEV a veřejný exploit neexistuje.

Rozpor v hodnocení

The Hacker News i záznam CVE uvádějí CVSS 10,0, Canonical dal stejné chybě v Ubuntu prioritu „Medium“. CVSS měří následek, priorita distribuce počítá i s tím, jak snadno se k němu útočník dostane.

Rozhoduje konfigurace. Samostatný LXD API do sítě neotevře, dokud správce nenastaví core.https_address; do té doby poslouchá jen na lokálním socketu. Kdo ho používá lokálně přes lxc, nemá co řešit. Kdo má API v síti nebo provozuje MicroCloud cluster, má nejvyšší prioritu dneška.

Kde je oprava

Canonical 28. 10. upozorňoval, že LXD jde do stable postupně z candidate; kdo po snap refresh dostane starou verzi, zkontroluje snap info lxd.

Jak ověřit

snap list lxd microcloud                 # verze a kanál, který skutečně běží
lxc config get core.https_address        # prázdné = API jen na lokální socket
ss -ltnp | grep lxd                      # na čem daemon poslouchá do sítě
snap refresh lxd && snap refresh microcloud

Pro správce: aktualizujte dnes každý stroj s LXD nebo MicroCloud, kde je API dostupné po síti — u clusteru všechny členy. Než snap opravu nabídne, omezte přístup k API na důvěryhodné adresy; veřejný certifikát klienta není tajemství, takže „nikdo ho nezná“ tady neplatí.