plaincve:~$

// 威脅簡報

CVE-2026-108863

Katanemo Plano 的 Envoy 管理介面未設認證:連得到管理埠(9901,或用 plano up 時主機的 19901)就能讀出設定的明文 LLM API 金鑰

CVSS
7.5 HIGH
CISA KEV
未列入
弱點類型
CWE-306 · CWE-522 · CWE-200
主題
AI 安全 · 基礎設施

PlainCVE 團隊 · 發布 2026-10-18 · AI 輔助 · 媒體簡報 ↓

AI 審稿 2026-10-18(未經人工)指令測試:未提供漏洞重現:未進行驗證紀錄 ↓

Plano 內建的 Envoy 管理介面對所有網路介面開放、不需登入,能連到它的人就能讀出明文的 LLM API 金鑰;目前沒有已知的修補版本。

誰會中使用 Katanemo Plano(PyPI 套件 planoai)0.4.37 及以前版本、設定裡有真實 LLM 供應商金鑰,而且 Envoy 管理埠(容器內 9901,用 plano up 或開發用 Compose 啟動時是主機的 19901)可被不受信任網路連到的人。
後果攻擊者不需帳號就能讀出你設定的 LLM 供應商 API 金鑰。有第三方(AI 產生的)分析指出,金鑰外洩後可能被未授權使用 LLM 服務,實際影響取決於金鑰權限。
現在該做什麼目前沒有已知的修補版。先把管理埠改成只發布到本機(例如 127.0.0.1:19901:9901)或移除這個埠的發布;Docker 發布的埠會繞過 ufw/iptables 的 INPUT 規則,只靠主機防火牆可能擋不住(依 Docker 官方文件)。確認曾經暴露的話,輪替 LLM 供應商金鑰(PlainCVE 建議)。
受影響版本0.4.37 及以前的所有版本(CNA 範圍從版本 0 起算;研究者只以靜態程式碼審查確認 0.4.37(commit 72002a62),沒有實際執行驗證)
修好的版本未知:沒有一手來源指出修補版本(CVE 紀錄未列修補版本、PyPI 最新版仍是 0.4.37);OSV 把 commit 72002a62(0.4.37)標為 fixed,但 CNA 記錄 0.4.37 仍受影響
CVSS 向量
顯示完整向量CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
時間點
  • 首次公開 2026-10-11

藍隊應對手冊

確認、修補 / 緩解、應變、強化。版本符合受影響條件不等於已被入侵;檢查沒有結果也不等於安全,每一項都有能證明與不能證明的範圍。標記的步驟對應下方攻擊流程裡可以擋下攻擊的那一步。

DETECT確認我受影響嗎?有沒有入侵跡象?
  1. 01確認版本

    在安裝 planoai CLI 的主機或 Python 虛擬環境中執行(要先啟用該虛擬環境)。planoai 0.4.37 及以前都在 CNA 的受影響範圍內。目前沒有已知的修補版本,所以版本號只能告訴你「受影響」,不能告訴你「安全」。如果是用 pipx 安裝,pip show 會找不到套件,請改用 pipx list 查看 planoai 的版本;用 uv tool 等其他工具安裝的,也請用該工具的列表功能查,查不到不代表沒裝。

    唯讀查詢
    pip show planoai | grep -i '^version'
  2. 02確認管理埠是否對外開放

    看主機上是否有程式在 9901 或 19901 埠監聽,以及容器是否把這兩個埠發布到主機。如果監聽位址是 0.0.0.0 而不是 127.0.0.1,就代表其他機器也可能連得到。

    唯讀查詢
    ss -ltnp | grep -E ':(9901|19901)\b'; docker ps --format '{{.Names}} {{.Ports}}' | grep -E '9901|19901'
    步驟 1步驟 2
MITIGATE修補 / 緩解先修補;還不能修補時先擋住
  1. 01管理埠只發布到本機,或不要發布

    用 plano up 或開發用 Compose 啟動的環境,容器的 9901 會發布成主機的 19901。把發布改成只綁 127.0.0.1(例如 127.0.0.1:19901:9901),或移除這個發布。依 Docker 官方文件,發布的容器埠在 nat 表就被轉走,不會經過 ufw 使用的 INPUT/OUTPUT 鏈,所以只用 ufw/iptables INPUT 規則限制 19901 可能無效;加上 127.0.0.1 才會只有 Docker 主機本身連得到(Docker 文件也提醒,28.0.0 以前的版本,同一個 L2 網段的主機仍可能連到發布在 localhost 的埠)。這是 PlainCVE 依 Docker 文件整理的建議,不是廠商修補。

    步驟 1
  2. 02管理介面只允許本機存取

    Envoy 自己的文件建議只從 localhost 或安全網路存取管理介面,並可用 allow_paths 限制可用的管理路徑。這是 Envoy 元件的通用建議,不是 Plano 廠商針對此漏洞的修補。

    步驟 2步驟 3
RESPOND應變發現入侵跡象時
  1. 01輪替曾暴露的 LLM 供應商金鑰

    如果管理埠曾被不受信任的網路連到,假設金鑰已外洩,到各 LLM 供應商後台撤銷並重發金鑰,並檢查是否有異常用量。這是 PlainCVE 的建議;沒有來源報告過實際遭利用。

    步驟 4步驟 5
HARDEN強化長期避免同類問題
  1. 01不要在對外主機上用開發用啟動方式

    研究者指出 plano up 與附帶的開發用 Compose 檔會把管理埠發布到主機的 19901。對外服務的主機應另行檢查埠的發布設定。

    步驟 1
  2. 02金鑰最小權限與用量上限

    就算金鑰外洩,有權限與用量上限也能限制損害(PlainCVE 建議)。

    步驟 5
完整修復步驟與說明

目前沒有一手來源指出廠商修補或廠商安全公告(OSV 把 0.4.37 的 commit 標為 fixed,但 CNA 記錄 0.4.37 仍受影響;GitHub 上的通報是未審核的資料庫條目,沒有連到維護者自己的公告)。以下的順序很重要:

  1. 先關門,再換鎖。 先把管理埠改成只發布到本機(例如 127.0.0.1:19901:9901)或移除這個埠的發布,讓管理埠只剩本機能連,之後才輪替金鑰。順序反過來的話,新金鑰也可能立刻被讀走。(PlainCVE 建議)
  2. 兩個埠都要檢查,不要只靠主機防火牆。 主機上實際開的埠(9901 或 19901)取決於部署方式。依 Docker 官方文件,Docker 發布的容器埠在 nat 表就被轉走,會繞過 ufw/iptables 的 INPUT 規則,所以只在主機防火牆擋 19901 可能無效;要改的是埠的發布方式(只綁 127.0.0.1,或不發布)。Docker 文件另外提醒,28.0.0 以前的版本,同一個 L2 網段的主機仍可能連到發布在 localhost 的埠。
  3. 輪替金鑰。 若管理埠曾對不受信任的網路開放,到各 LLM 供應商後台撤銷並重發金鑰,並檢查異常用量。(PlainCVE 建議)
  4. 追蹤修補。 留意 Plano 是否發布 0.4.37 以後的版本,以及版本說明是否提到管理介面。

攻擊流程

從左到右是攻擊發生的順序。藍色盾牌代表這一步可以被擋下,越早擋下越好。點圖示可看細節。

由上到下是攻擊發生的順序。藍色盾牌代表這一步可以被擋下,越早擋下越好。點圖示可看細節。

Katanemo Plano 的 Envoy 管理介面未設認證:連得到管理埠(9901,或用 plano up 時主機的 19901)就能讀出設定的明文 LLM API 金鑰: 1. 攻擊者連到主機上的 Envoy 管理埠 → 2. 管理介面沒有任何登入檢查 → 3. 攻擊者讀取設定匯出(config dump) → 4. 設定裡含有明文的 LLM 供應商金鑰 → 5. 偷到的金鑰可能被拿去使用 LLM 服務CVE-2026-108863 · Katanemo Plano 的 Envoy 管理介面未設認證:連得到管理埠(9901,或用 plano up 時主機的 19901)就能讀出設定的明文 LLM API 金鑰攻擊者你的系統外部攻擊者連到主機上的 Envoy 管理埠 — CNA 描述的是 9901 埠;研究者指出用 plano up 或附帶的開發用 Compose 檔啟動時,會對外發布成主機的 19901 埠。不需要任何 Plano 帳號或角色。 1攻擊者連到主機上的Envoy 管理埠管理介面沒有任何登入檢查 — Plano 0.4.37 的 Envoy 範本把管理介面綁在 0.0.0.0(所有網路介面),而這個介面本身不要求認證。 2管理介面沒有任何登入檢查攻擊者讀取設定匯出(config dump) — 管理介面提供 /config_dump 功能,會把 Envoy 目前的完整設定吐出來。 3攻擊者讀取設定匯出(config dump)設定裡含有明文的 LLM 供應商金鑰 — 金鑰存在 WASM 過濾器的設定中,沒有遮蔽。前提是 Plano 設定至少有一個供應商的 access_key 對應到真實金鑰。 4設定裡含有明文的 LLM供應商金鑰偷到的金鑰可能被拿去使用 LLM 服務 — 這是第三方(AI 產生的)分析的推論:可能造成未授權使用,影響取決於金鑰權限。5偷到的金鑰可能被拿去使用 LLM 服務攻擊路徑可在此擋下PlainCVE · plaincve.date/vulns/cve-2026-108863-plano-envoy-admin-key-exposure · CC BY 4.0
Katanemo Plano 的 Envoy 管理介面未設認證:連得到管理埠(9901,或用 plano up 時主機的 19901)就能讀出設定的明文 LLM API 金鑰: 1. 攻擊者連到主機上的 Envoy 管理埠 → 2. 管理介面沒有任何登入檢查 → 3. 攻擊者讀取設定匯出(config dump) → 4. 設定裡含有明文的 LLM 供應商金鑰 → 5. 偷到的金鑰可能被拿去使用 LLM 服務CVE-2026-108863 · Katanemo Plano 的Envoy 管理介面未設認證:連得到管理埠(9901,或用 plano up 時主機的 19901)就能讀出設定的明文 LLM API 金鑰攻擊者連到主機上的 Envoy 管理埠 — CNA 描述的是 9901 埠;研究者指出用 plano up 或附帶的開發用 Compose 檔啟動時,會對外發布成主機的 19901 埠。不需要任何 Plano 帳號或角色。 1攻擊者攻擊者連到主機上的 Envoy 管理埠管理介面沒有任何登入檢查 — Plano 0.4.37 的 Envoy 範本把管理介面綁在 0.0.0.0(所有網路介面),而這個介面本身不要求認證。 2你的系統管理介面沒有任何登入檢查攻擊者讀取設定匯出(config dump) — 管理介面提供 /config_dump 功能,會把 Envoy 目前的完整設定吐出來。 3攻擊者攻擊者讀取設定匯出(configdump)設定裡含有明文的 LLM 供應商金鑰 — 金鑰存在 WASM 過濾器的設定中,沒有遮蔽。前提是 Plano 設定至少有一個供應商的 access_key 對應到真實金鑰。 4你的系統設定裡含有明文的 LLM 供應商金鑰偷到的金鑰可能被拿去使用 LLM 服務 — 這是第三方(AI 產生的)分析的推論:可能造成未授權使用,影響取決於金鑰權限。5外部偷到的金鑰可能被拿去使用LLM 服務攻擊路徑可在此擋下PlainCVE · CC BY 4.0plaincve.date/vulns/cve-2026-108863-plano-envoy-admin-key-exposure
圖片可自由用於報導與教學,採 CC BY 4.0,圖上已附出處。
  1. 攻擊者

    攻擊者連到主機上的 Envoy 管理埠

    CNA 描述的是 9901 埠;研究者指出用 plano up 或附帶的開發用 Compose 檔啟動時,會對外發布成主機的 19901 埠。不需要任何 Plano 帳號或角色。

    防禦: 把埠只發布到 127.0.0.1(例如 127.0.0.1:19901:9901)或移除這個發布。Docker 發布的埠會在 ufw/iptables 的 INPUT 規則之前被轉走,主機防火牆可能擋不住(依 Docker 官方文件)。

  2. 你的系統

    管理介面沒有任何登入檢查

    Plano 0.4.37 的 Envoy 範本把管理介面綁在 0.0.0.0(所有網路介面),而這個介面本身不要求認證。

    防禦: 依 Envoy 文件,管理介面最好只允許從 localhost 存取。

  3. 攻擊者

    攻擊者讀取設定匯出(config dump)

    管理介面提供 /config_dump 功能,會把 Envoy 目前的完整設定吐出來。

    防禦: Envoy 文件提到可用 allow_paths 限制能存取哪些管理路徑。

  4. 你的系統

    設定裡含有明文的 LLM 供應商金鑰

    金鑰存在 WASM 過濾器的設定中,沒有遮蔽。前提是 Plano 設定至少有一個供應商的 access_key 對應到真實金鑰。

  5. 外部

    偷到的金鑰可能被拿去使用 LLM 服務

    這是第三方(AI 產生的)分析的推論:可能造成未授權使用,影響取決於金鑰權限。

    防禦: 輪替曾暴露的金鑰,並給每把金鑰最小權限與用量上限(PlainCVE 建議)。

影響範圍

Plano 是 Katanemo 的開源工具,放在應用程式與 LLM(大型語言模型)服務之間轉送請求;它內部用一個叫 Envoy 的代理程式處理網路流量。受影響的套件是 PyPI 上的 planoai。

條件是否受影響
Plano 0.4.37 及以前 + 設定裡有真實的 LLM 供應商金鑰 + 管理埠可被不受信任的網路連到受影響
Plano 0.4.37 及以前,但管理埠只有本機或信任主機連得到程式碼仍有問題,但攻擊者需要先連到這個埠
0.4.37 以後的版本未知:沒有一手來源指出修補版本(PyPI 上還沒有 0.4.37 以後的版本)

幾個細節:

  • 版本範圍。 CNA(負責發 CVE 編號的單位,這裡是 VulnCheck)的範圍從版本 0 起算,OSV 把 0.1.0 以來的版本都列為受影響。研究者 hieuPenguinnn 的文章(該頁含攻擊程式,本站不連結)只以靜態程式碼審查確認 0.4.37(commit 72002a62,Envoy v1.37.0 基底映像檔),沒有實際執行驗證:研究者寫明沒有啟動 Plano、沒有連線管理介面,也沒有取得 /config_dump 的回應;/config_dump 不遮蔽金鑰這一點是研究者依 Envoy 文件推論的。舊版是否受影響來自 CNA 的範圍,不是實測結果。
  • 埠號。 CNA 描述的是 9901 埠。研究者指出,用 plano up 或附帶的開發用 Compose 檔啟動時,容器的 9901 會對外發布成主機的 19901。所以主機上實際開出來的埠取決於你怎麼部署。
  • 目前沒有已知的修補版本。 PlainCVE 的判斷:廠商發布頁在 2026-10-12 擷取時,最新版仍是 9 月 28 日的 0.4.37,也就是最後一個受影響版本,看起來還沒有修補版;PyPI 上 planoai 的最新版同樣是 2026-09-28 發布的 0.4.37。CVE 紀錄(CNA)沒有列修補版本,GitHub 的通報也沒有連到維護者公告。第三方 CVE 追蹤網站也回報沒有修補。要注意的是,OSV 從 2026-10-15 起把 commit 72002a62(也就是 0.4.37)標為 fixed,但 CNA 記錄 0.4.37 仍受影響,這不是官方修補。

原理

Envoy 有一個內建的管理介面,讓維運人員查看狀態、匯出設定。這個介面本身沒有登入機制,Envoy 的文件也因此建議只讓本機或安全的網路存取它。

Plano 0.4.37 的 Envoy 設定範本(廠商自己的檔案)卻把管理介面綁在 0.0.0.0 的 9901 埠。0.0.0.0 代表「所有網路介面」,所以其他機器也可能連得到。

管理介面中有一項 /config_dump 功能,會把 Envoy 的完整設定吐出來。Plano 把 LLM 供應商的 API 金鑰(讓程式向 AI 服務證明身分的密碼)寫在 WASM 過濾器(一種掛在 Envoy 上的外掛程式)的設定裡,而且是明文。CVE 紀錄(CNA)指出的結果是:連得到管理埠的人,不需要帳號,就能讀出你的金鑰。(研究者是用靜態程式碼審查和 Envoy 文件推出這一點,沒有在實際環境中觀察到。) 前提是 Plano 設定至少有一個供應商的 access_key 對應到真實金鑰。

CNA 把這歸類為 CWE-306(關鍵功能缺少認證);研究者另外列出 CWE-200(敏感資訊外洩)與 CWE-522(憑證保護不足)。CVSS 向量只評了機密性(高),完整性與可用性都是無影響。

有問題的設定思路(概念示意,不是 Plano 的完整原始檔):

展開程式碼範例(yaml)
admin:
  address:
    # 所有網路介面都能連到管理介面,而且沒有認證
    socket_address: { address: 0.0.0.0, port_value: 9901 }

較安全的設定思路(依 Envoy 文件的通用建議,不是廠商的修補):

展開程式碼範例(yaml)
admin:
  address:
    # 只有本機能連到管理介面
    socket_address: { address: 127.0.0.1, port_value: 9901 }

時間軸

日期事件
2026-10-11VulnCheck 保留並公開 CVE-2026-108863
2026-10-11NVD 收到紀錄,狀態為「Received」,尚未分析
2026-10-11GitHub 發布未審核的通報 GHSA-54m9-qc5w-93rc
2026-10-12尚未列入 CISA 已知遭利用漏洞清單(KEV)
2026-10-13CISA ADP(Vulnrichment)在 CVE 紀錄加上 SSVC 評估:Exploitation 為 poc、Automatable 為 yes、Technical Impact 為 partial
2026-10-15OSV 更新條目,把 commit 72002a62(0.4.37)標為 fixed;CNA 的 CVE 紀錄仍把 0.4.37 列為受影響、沒有修補版本

延伸閱讀

  • 評分差異。 CNA 的 CVSS 4.0 為 8.7、CVSS 3.1 為 7.5,兩者都屬「高」;本頁顯示 3.1 分數。研究者的文章(該頁含攻擊程式,本站不連結)則把嚴重度標為「中」,兩方說法不一致。NVD 尚未給出自己的評分。
  • 是否遭利用。 截至 2026-10-12 不在 KEV 上;沒有任何來源回報實際遭利用,也沒有證據顯示是零時差攻擊。不在 KEV 不代表沒有被利用。CVE 紀錄中 CISA ADP(Vulnrichment)2026-10-13 的 SSVC 評估把 Exploitation 標為 poc,也就是已有公開的概念驗證(PoC),並把研究者的文章標為 exploit(該頁含攻擊程式,本站不連結)。SSVC 的 poc 不代表已遭實際利用;是否遭實際利用仍是未知。
  • 金鑰外洩的後果。 有第三方(AI 產生的)分析指出,金鑰外洩可能導致 LLM 服務被未授權使用,影響取決於金鑰權限;這不是廠商的說法。
  • 發現者。 CVE 紀錄把發現者記為 hieuPenguinnn。
  • 相關弱點類型:CWE-306、CWE-200、CWE-522。

驗證紀錄 AI 依審稿規則逐項核對來源,全部通過;未經人工審稿,也尚未在我們的環境重現

AI 審稿2026-10-18 · 審稿規則

驗證紀錄只寫環境與結果,不公開重現步驟或可攻擊他人系統的程式。詳見 政策.

來源

  1. CVE / NVD / OSVCVE-2026-108863 record (CVE Services API) · CVE Program / VulnCheck (CNA), 2026-10-11 · 查閱 2026-10-12
  2. CVE / NVD / OSVNVD API - CVE-2026-108863 · NIST, 2026-10-11 · 查閱 2026-10-12
  3. 安全公告Katanemo Plano through 0.4.37 Missing Authentication on Envoy Admin Interface · VulnCheck, 2026-10-11 · 查閱 2026-10-12
  4. 安全公告GitHub Advisory Database - GHSA-54m9-qc5w-93rc (unreviewed) · GitHub, 2026-10-11 · 查閱 2026-10-12
  5. 其他OSV - CVE-2026-108863 · OSV · 查閱 2026-10-18
  6. 其他PyPI - planoai release history (JSON API) · PyPI · 查閱 2026-10-18
  7. 廠商說明plano 0.4.37 config/envoy.template.yaml · Katanemo (GitHub) · 查閱 2026-10-12
  8. 其他Envoy documentation: Administration interface · Envoy Proxy · 查閱 2026-10-12
  9. 其他Docker documentation: Packet filtering and firewalls · Docker · 查閱 2026-10-17
  10. 其他Docker documentation: Port publishing and mapping · Docker · 查閱 2026-10-17
  11. 其他CVE-2026-108863 (OffSeq Threat Radar) · OffSeq · 查閱 2026-10-12
  12. 其他CVE-2026-108863 (HOL Guard) · HOL · 查閱 2026-10-12
  13. 新聞報導CVE-2026-108863 (The Hacker Wire) · The Hacker Wire · 查閱 2026-10-12

媒體簡報

一句話

Plano 是 Katanemo 開發、用來串接 AI 模型服務的開源工具,內部使用名為 Envoy 的代理程式。CVE-2026-108863 指出,Plano 0.4.37 及以前版本把 Envoy 的管理介面開放在所有網路介面上且不需登入,能連到它的人就能讀出設定好的 AI 服務 API 金鑰。這個 CVE 由 VulnCheck 在 2026 年 10 月 11 日公開,目前沒有一手來源(CVE 紀錄、PyPI 發布紀錄)指出修補版本。

關鍵數字

嚴重度(CNA)
CVSS 4.0 8.7;CVSS 3.1 7.5 cveawg.mitre.org
受影響版本
0.4.37 及以前 cveawg.mitre.org
CVE 公開
2026-10-11(VulnCheck) cveawg.mitre.org
管理介面綁定位址
0.0.0.0:9901(廠商範本,0.4.37) github.com
發現者
hieuPenguinnn cveawg.mitre.org

已確認

  • CVE 紀錄(CNA,VulnCheck)指出,Plano 0.4.37 及以前的 Envoy 管理介面不需認證,可經由 /config_dump 讀出明文 LLM 供應商金鑰。
  • 廠商 0.4.37 的 Envoy 範本把管理介面綁在 0.0.0.0 的 9901 埠。
  • 截至 2026-10-12,它不在 CISA 已知遭利用漏洞清單上。
  • CVE 紀錄中 CISA ADP(Vulnrichment)2026-10-13 的 SSVC 評估把 Exploitation 標為 poc(已有公開 PoC)。

尚未確認 / 說法不一

  • 沒有一手來源指出修補版本(CVE 紀錄未列修補版本、PyPI 最新版仍是 0.4.37),也沒有廠商安全公告;OSV 把 commit 72002a62(0.4.37)標為 fixed,但 CNA 記錄 0.4.37 仍受影響。
  • 嚴重度說法不一:CNA(VulnCheck)評為高,研究者的文章標為中。
  • 是否已遭實際利用未知;不在 KEV 不代表沒有被利用。
  • 0.4.37 以前的版本是否受影響來自 CNA 的範圍,沒有人回報實測。

可引用的一句話

金鑰本身沒有被破解,只是被放在一扇沒上鎖、還面向街道的管理門後面。

圖片

下載分享圖(PNG) · 攻擊流程圖(可下載)

引用時請標示「PlainCVE」並附上本頁連結。 完整引用格式見下方「如何引用本頁」。有事實錯誤請回報.

如何引用本頁

本文採 CC BY 4.0,轉載請保留署名與連結。

PlainCVE 團隊(2026)。《Katanemo Plano 的 Envoy 管理介面未設認證:連得到管理埠(9901,或用 plano up 時主機的 19901)就能讀出設定的明文 LLM API 金鑰》。PlainCVE。https://plaincve.date/vulns/cve-2026-108863-plano-envoy-admin-key-exposure(查閱日期:YYYY-MM-DD)
BibTeX
@misc{cve2026108863planoenvoyadminkeyexposure2026,
  title  = {Katanemo Plano 的 Envoy 管理介面未設認證:連得到管理埠(9901,或用 plano up 時主機的 19901)就能讀出設定的明文 LLM API 金鑰},
  author = {PlainCVE 團隊},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/vulns/cve-2026-108863-plano-envoy-admin-key-exposure},
  note   = {更新於 2026-10-18}
}