防暴筆記BREACH NOTES

LXD 與 MicroCloud CVSS 10.0 認證繞過：
只要公鑰就能冒充信任客戶端

速讀：5 分鐘掌握重點

為什麼現在很紅：CVSS 10.0 是最高嚴重性評分，意味著漏洞可以被遠端利用、不需認證、影響範圍廣泛。Canonical 的 LXD 與 MicroCloud 就有這樣一個漏洞：攻擊者只要拿到信任客戶端的公開憑證（不是秘密），就能冒充該客戶端登入 HTTPS API，取得對叢集與虛擬機的存取權限。如果被冒充的帳號有高權限，攻擊者還能取得主機的 root 權限。

一句話結論
Canonical 於 2026 年 11 月 1 日揭露 LXD 與 MicroCloud 的關鍵漏洞 CVE-2026-112816（CVSS 10.0），允許攻擊者只憑信任客戶端的公開憑證（不需私鑰）就能冒充該客戶端登入 HTTPS API。一旦冒充成功，攻擊者就能以該客戶端的身分存取叢集與虛擬機；如果被冒充的帳號有高權限，攻擊者還能取得主機的 root 權限。
他要的是什麼
我只需要一個你信任的客戶端的公開憑證，不需要私鑰。我把我自己的憑證放在前面，把那個信任客戶端的公開憑證附加在後面，組成一個 TLS 憑證鏈。當我連線到你的 LXD 或 MicroCloud HTTPS API 時，我用我自己的私鑰完成 TLS 握手，但你的伺服器會檢查整個憑證鏈，發現裡面有一個信任客戶端的憑證，就讓我以該客戶端的身分登入。如果那個客戶端有高權限，我就能存取叢集、操作虛擬機、甚至取得主機的 root 權限。
你今天做一件事
今天檢查所有 LXD 與 MicroCloud 的版本，確認是否已更新至修補版本。限制網路存取 HTTPS API 的來源，只允許信任的 IP 或網段。檢視信任客戶端清單，移除不再需要的憑證。監控 API 存取日誌，確認沒有非預期的客戶端連線。對於 LXD 獨立伺服器，確認 core.https_address 設定是否真的需要開啟網路 API；如果不需要，關閉它。對於 MicroCloud 叢集，特別注意成員加入叢集時的公開憑證是否被攔截。 直接去做 →
哪些能信
9 可證明0 推論1 缺口 每個主張都標了等級，缺口是誠實寫出來的。
破口速查
受害端一律去識別化；寫「未公開」代表公開資料查不到。
伺服器服務商
LXD 4.0.14、5.0.10、5.21.8、6.9 及之前版本；MicroCloud 3.x 與 2.x（需 snap 更新）
網路服務商
CVE-2026-112816（CVSS 10.0），mutual TLS 認證繞過，伺服器檢查 TLS 憑證鏈時比對所有憑證而非僅葉憑證
漏洞出現的地方
攻擊者需網路存取 HTTPS API（LXD 預設不開啟，MicroCloud 叢集預設開啟），並取得一個信任客戶端的公開憑證
馬上自我檢測
檢查 LXD 與 MicroCloud 版本是否已更新至修補版本 確認是否有非預期的客戶端連線或 API 存取記錄 檢查信任客戶端清單是否有非預期的憑證 確認網路存取 HTTPS API 的來源 IP 是否符合預期
漏洞修補方式
立即更新至修補版本：LXD 6.10.1、5.21.9、5.0.11、4.0.15；MicroCloud 3.4.1、2.1.5 限制網路存取 HTTPS API 的來源，只允許信任的 IP 或網段 檢視信任客戶端清單，移除不再需要的憑證 監控 API 存取日誌，確認沒有非預期的客戶端連線
有 15 分鐘再看：其餘 2 點
  1. 漏洞成因是伺服器檢查 TLS 憑證鏈時，比對了憑證鏈中的所有憑證與信任存儲清單，但 TLS 連線只能證明客戶端擁有鏈中第一個憑證（葉憑證）的私鑰，其餘憑證是客戶端自行附加的。因此攻擊者可以將信任客戶端的公開憑證附加在自己的憑證之後，伺服器就會接受攻擊者為該客戶端。利用漏洞需要兩個條件：網路存取 HTTPS API（LXD 獨立伺服器預設不開啟，需管理員設定；MicroCloud 叢集會開啟），以及信任客戶端的公開憑證（不是秘密）。
  2. Canonical 已發布修補版本：LXD 6.10.1、5.21.9、5.0.11、4.0.15（snap 通道 6/stable、5.21/stable、5.0/stable、4.0/stable）；MicroCloud 3.4.1、2.1.5（snap 通道 3/stable、2/stable）。漏洞由 Incus 專案（LXD 的社群分支）回報，Incus 7.6.0 已修補。Ubuntu 套件庫的 LXD 不受影響或未出貨，修補版本只有 snap。目前沒有公開證據顯示漏洞已在野外被利用，CISA 於 10 月 30 日評估漏洞尚未被利用，未列入 KEV 清單，也沒有公開的 exploit。Canonical 表示沒有臨時解決方法，唯一防禦是限制網路存取 HTTPS API。

Canonical 的 LXD 與 MicroCloud 存在 CVSS 10.0 關鍵漏洞 CVE-2026-112816，允許攻擊者只憑信任客戶端的公開憑證（不需私鑰）就能冒充該客戶端登入 HTTPS API。漏洞成因是伺服器檢查 TLS 憑證鏈時，比對了所有憑證而非僅檢查葉憑證，而 TLS 連線只能證明客戶端擁有葉憑證的私鑰。漏洞由 Incus 專案回報，Canonical 已發布修補版本。

LXD 與 MicroCloud 認證繞過漏洞（CVE-2026-112816）·2026-10-30（CISA 評估）至 2026-11-01（揭露）·全文 7 分鐘
本篇目錄

發生了什麼

來源：本文整理自 The Hacker News 於 2026 年 11 月 1 日發布的報導，引述 Canonical 的安全公告與 CISA 的 CVE 記錄。原文連結，原文發布日期為 2026 年 11 月 1 日。

想像你管理一個 LXD 或 MicroCloud 叢集，用來運行容器與虛擬機。你使用 mutual TLS 認證，讓遠端客戶端必須出示憑證才能存取 API。你以為只有持有私鑰的客戶端才能登入，但攻擊者只要拿到信任客戶端的公開憑證（不是秘密），就能冒充該客戶端。

2026 年 11 月 1 日，Canonical 揭露 LXD 與 MicroCloud 的關鍵漏洞 CVE-2026-112816，CVSS 評分 10.0（最高分）。攻擊者可以冒充信任客戶端登入 HTTPS API，不需要該客戶端的私鑰。

一旦冒充成功，攻擊者就能以該客戶端的身分存取叢集與虛擬機。如果被冒充的帳號有高權限，攻擊者還能取得主機的 root 權限。

Canonical 已發布修補版本。

漏洞如何運作

mutual TLS 認證的原理

LXD 與 MicroCloud 讓遠端客戶端透過 mutual TLS 存取 API。在這種設定中，客戶端必須出示憑證來證明自己的身分。

當客戶端的憑證在伺服器的信任存儲（trust store）中，也就是伺服器會接受的身分清單中，該客戶端就被視為信任的。

漏洞的成因

問題出在伺服器如何檢查憑證。

伺服器將客戶端傳送的每一個憑證都與信任存儲比對，但 TLS 連線只能證明客戶端擁有鏈中第一個憑證（葉憑證）的私鑰。鏈中其餘的憑證是客戶端自行選擇附加的。

攻擊者的做法

因此，攻擊者可以：

  1. 拿到一個信任客戶端的公開憑證（不是秘密）
  2. 將這個公開憑證附加在自己的憑證之後
  3. 伺服器就會接受攻擊者為該客戶端

誰會受影響

利用這個漏洞需要兩個條件：

  1. 網路存取 HTTPS API
  2. 信任客戶端的公開憑證

LXD 獨立伺服器

LXD 獨立伺服器預設不會暴露網路 API。它只監聽本機 socket，除非管理員透過 core.https_address 設定開啟網路 API。

MicroCloud 叢集

MicroCloud 是將多台運行 LXD 的機器綁成一個叢集的工具，有一個特定的弱點。

Canonical 表示，攻擊者如果能在成員加入叢集時攔截該成員的公開憑證，之後就能以該成員的身分登入。

受影響與修補版本

CVE 記錄列出以下受影響版本，每個版本都在隨後的修補版本之前：

  • LXD 4.0.14
  • LXD 5.0.10
  • LXD 5.21.8
  • LXD 6.9

Canonical 列出以下修補的 snap 版本：

產品Snap 通道修補版本
LXD6/stable6.10.1
LXD5.21/stable5.21.9
LXD5.0/stable5.0.11
LXD4.0/stable4.0.15
MicroCloud3/stable3.4.1
MicroCloud2/stable2.1.5

漏洞來源

這個漏洞不是從 Canonical 開始的。Incus 專案（LXD 的社群分支）回報了這個漏洞，Canonical 確認 LXD 也受影響。Incus 已在 7.6.0 版本修補同樣的漏洞。

Ubuntu 套件庫的 LXD 不受影響或未出貨，所以修補版本只有 snap。

目前沒有野外利用證據

目前沒有公開證據顯示這個漏洞已在野外被利用。

CVE 記錄包含美國 CISA 於 10 月 30 日的評估，認為漏洞尚未被利用；它不在 CISA 的 Known Exploited Vulnerabilities 清單上，也沒有公開的 exploit。

該怎麼做

立即更新

更新 LXD 與 MicroCloud 至修補版本。在 snap 安裝上，執行：

sudo snap refresh lxd
sudo snap refresh microcloud

Canonical 表示，修補的 LXD 點發布版本當時仍在從 candidate 通道推送到 stable 通道，所以更新後應該檢查實際安裝的版本，而不是假設修補已經到達。

沒有臨時解決方法

Canonical 的公告沒有提供 LXD 的臨時解決方法。

因為攻擊需要網路存取 API，限制誰能存取 API 可以在更新前降低風險。

Incus 專案在回報同樣漏洞時表示，沒有設定上的修補方法，唯一的步驟是限制網路存取監聽器。

Incus 使用者

Incus 使用者應該移至 7.6.0，該版本修補了這個漏洞以及 17 個其他安全問題。

為什麼這個漏洞是 CVSS 10.0

CVSS 10.0 的意義

CVSS 10.0 是最高嚴重性評分，意味著：

  • 可以被遠端利用：攻擊者不需要本機存取
  • 不需認證：攻擊者不需要帳號密碼（只需公開憑證）
  • 影響完整性、機密性、可用性：攻擊者可以讀取、修改、刪除資料
  • 影響範圍廣泛：攻擊可能擴及其他系統（叢集中的其他機器、虛擬機）

攻擊者能做什麼

一旦冒充成功，攻擊者就能：

  1. 以該客戶端的身分存取叢集
  2. 操作虛擬機：建立、刪除、修改虛擬機
  3. 讀取敏感資料：虛擬機中的資料、設定檔、憑證
  4. 如果客戶端有高權限，取得主機的 root 權限

公開憑證不是秘密

這個漏洞特別危險的原因是，攻擊者只需要公開憑證，而公開憑證不是秘密。

在 mutual TLS 的設計中，公開憑證本來就是公開的，因為它會在 TLS 握手中傳送。私鑰才是秘密，用來證明憑證的持有者。

但這個漏洞讓攻擊者不需要私鑰就能冒充，只要把公開憑證附加在自己的憑證之後即可。

MicroCloud 的特定風險

對於 MicroCloud，攻擊者如果能在成員加入叢集時攔截公開憑證，之後就能一直以該成員的身分登入。這在以下情境特別危險：

  • 成員透過不安全的網路加入叢集
  • 攻擊者能夠進行中間人攻擊
  • 攻擊者能夠存取網路流量記錄

你可以學到什麼

站在攻擊者的角度：我只需要一個你信任的客戶端的公開憑證，不需要私鑰。我把我自己的憑證放在前面，把那個信任客戶端的公開憑證附加在後面，組成一個 TLS 憑證鏈。當我連線到你的 LXD 或 MicroCloud HTTPS API 時，我用我自己的私鑰完成 TLS 握手，但你的伺服器會檢查整個憑證鏈,發現裡面有一個信任客戶端的憑證，就讓我以該客戶端的身分登入。如果那個客戶端有高權限，我就能存取叢集、操作虛擬機、甚至取得主機的 root 權限。

lessons本案的 7 個教訓
  1. 01
    CVSS 10.0 代表最高嚴重性：可遠端利用、不需認證、影響完整性與機密性、影響範圍廣泛。
  2. 02
    mutual TLS 認證的實作細節很重要：檢查所有憑證而非僅葉憑證，就會讓攻擊者能附加信任憑證來冒充。
  3. 03
    公開憑證不是秘密，但仍可能被濫用：在 mutual TLS 中，公開憑證會在 TLS 握手中傳送，攻擊者可以攔截或收集。
  4. 04
    預設不開啟網路 API 是好設計：LXD 獨立伺服器預設只監聽本機 socket，需要管理員明確開啟網路 API。
  5. 05
    叢集環境的攻擊面更大：MicroCloud 叢集成員加入時的公開憑證可能被攔截，之後就能一直被用來冒充。
  6. 06
    社群分支可以發現上游漏洞：Incus 專案（LXD 的分支）發現並回報這個漏洞，Canonical 確認 LXD 也受影響。
  7. 07
    限制網路存取是重要的防禦層：即使存在漏洞，限制誰能存取 API 仍能降低風險。
keywords重點學習：最需要學習的 10 個關鍵字8 個
  1. 01
    CVE-2026-112816
    LXD 與 MicroCloud 的認證繞過漏洞，CVSS 10.0。
  2. 02
    CVSS 10.0
    最高嚴重性評分，代表可遠端利用、不需認證、影響範圍廣泛。
  3. 03
    mutual TLS
    客戶端與伺服器都必須出示憑證的 TLS 認證方式，本漏洞的攻擊目標。
  4. 04
    LXD
    Canonical 的容器與虛擬機管理工具，受 CVE-2026-112816 影響。
  5. 05
    MicroCloud
    將多台運行 LXD 的機器綁成叢集的工具，受 CVE-2026-112816 影響。
  6. 06
    Incus
    LXD 的社群分支，回報了 CVE-2026-112816 漏洞，並在 7.6.0 版本修補。
  7. 07
    信任存儲（Trust Store）
    伺服器接受的身分清單，存放信任客戶端的憑證。
  8. 08
    葉憑證（Leaf Certificate）
    TLS 憑證鏈中的第一個憑證，TLS 連線只能證明客戶端擁有葉憑證的私鑰。
try today今天就可以來試試約 15 分鐘

全部唯讀，不改任何設定；做完你會知道自己有沒有同樣的破口。

  1. 檢查所有 LXD 與 MicroCloud 的版本
    snap list lxd
snap list microcloud
    看到什麼代表什麼：確認版本是否為 LXD 6.10.1、5.21.9、5.0.11、4.0.15 或更新版本；MicroCloud 3.4.1、2.1.5 或更新版本。
  2. 更新至修補版本
    sudo snap refresh lxd
sudo snap refresh microcloud
    看到什麼代表什麼：更新後再次檢查版本，確認修補已經安裝。
  3. 檢查 LXD 是否開啟網路 API
    lxc config get core.https_address
    看到什麼代表什麼：如果回傳空字串，代表只監聽本機 socket；如果回傳 IP 位址或主機名稱，代表網路 API 已開啟。評估是否真的需要網路 API。
  4. 限制網路存取 HTTPS API
    看到什麼代表什麼：使用防火牆規則，只允許信任的 IP 或網段存取 LXD/MicroCloud 的 HTTPS API 埠口（預設 8443）。
  5. 檢視信任客戶端清單
    lxc config trust list
    看到什麼代表什麼：確認清單中的憑證是否都是預期的，移除不再需要的憑證。
  6. 監控 API 存取日誌
    看到什麼代表什麼：檢查是否有非預期的客戶端連線或 API 操作。

如果你使用 LXD 或 MicroCloud

  1. 立即更新至修補版本：LXD 6.10.1、5.21.9、5.0.11、4.0.15；MicroCloud 3.4.1、2.1.5。
  2. 檢查實際安裝的版本：不要假設修補已經到達，更新後檢查版本。
  3. 評估是否需要網路 API：對於 LXD 獨立伺服器，如果不需要遠端存取，不要開啟 core.https_address。
  4. 限制網路存取：使用防火牆規則，只允許信任的 IP 或網段存取 HTTPS API。
  5. 檢視信任客戶端清單：移除不再需要的憑證。
  6. 監控 API 存取日誌：確認沒有非預期的客戶端連線。
  7. 對於 MicroCloud：特別注意成員加入叢集時的網路安全，避免公開憑證被攔截。

CVSS 10.0 是最高嚴重性評分，雖然目前沒有野外利用證據，但今天就更新，今天就限制存取。

想看全部細節？

環境背景、時間線、攻擊鏈對照 ATT&CK、關鍵證據、根因、處置與檢討都在完整版，約 7 分鐘。

來源

本文為公開報導與官方公告的整理與拆解，非第一手鑑識；證據等級依來源可信度標註。

本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。

LXDMicroCloudIncusCVE-2026-112816CVSS 10.0認證繞過mutual TLSCanonical容器管理
看完的心情
ai prompt把這篇的切入點帶回你的環境

複製下面這段，貼給你在用的 AI 工具（Claude Code、Cursor、Copilot、ChatGPT 都可以）。它會用本篇的破口位置、自我檢測與學習重點，對你的專案或環境做一次資安掃描，列出潛在問題與建議的調整或加強方式。

預設是唯讀：只發現問題、提出建議，不會改你任何檔案或設定。

§
對應課程模組

M2 弱點與修補管理 · 想在自己的環境做一次同樣的盤點，從 自我盤點 開始。

延伸閱讀
newsletter
下一篇拆解直接寄到信箱

每篇新文章一封：三點摘要、關鍵字定義、今天能做的一件事。或先 加入會員 記錄你完成的任務。

← 上一份Polymarket 遭劫持的 DebugBear 腳本攻擊：透過第三方 RUM 工具竊取 270 萬美元