MaxKB 為每個已啟用工具的助理附加了 Shell 工具，卻從未加以管控

MaxKB 是由 GitHub 組織 1Panel-dev 發布的開源企業助理平台，其聊天代理建立在一個框架上：只要傳入具備 shell 能力的後端，該框架就會默默加入一個 shell 工具——而 MaxKB 從未移除該工具，也從未要求任何人核准其使用。這個漏洞是 CVE-2026-77521，以 GitHub 安全公告 GHSA-f36j-f34j-h3rx於 2026 年 9 月 2 日發布，且在公開或嵌入式助理的情境下，依 CVSS 3.1 獲評 10.0 分（滿分 10 分）。 Lasso Security，該公司發現並通報了此漏洞，並證明一則聊天訊息——或助理僅透過檢索或上傳文件而攝入的文字——可驅使模型執行命令：在裸機部署上直接於主機執行，以及在官方容器中透過研究人員指出可用分號繞過的包裝程式執行。沒有引用來源記載此漏洞曾在實際環境中遭到利用。該記錄本身的嚴重性等級、信心評估與來源清單位於 AI 事件檔案庫，與同一批揭露中相鄰的 MaxKB 與代理工具相關條目並列。

MaxKB 是一款自架式產品，用於建構檢索增強型助理：操作人員建立助理、為其附加能力——工具、Model Context Protocol 伺服器、技能、子應用程式——連接由已上傳文件或爬取網站所建立的知識庫，然後透過需驗證的主控台或公開、可嵌入的聊天小工具來開放助理。這種靈活性正是曝險所在。該公告的觸發條件並非特殊設定，而是尋常設定：任何附加至少一項能力的助理，其聊天都會經過受影響的代理路徑，而未附加任何能力的聊天則不會。Lasso 的報導形容該專案是其類別中較廣泛採用的專案之一，並指出 MaxKB 通常以多租戶服務形式部署——這使得以應用程式使用者身分執行的命令位於租戶模式之下，而非位於某一租戶的區塊之內。

shell 工具是隨框架附帶而來的，而非產品本身

MaxKB 使用 LangChain 的 deepagents 函式庫來建構這些代理，並在專案的 pyproject.toml 中，無論是有漏洞的標籤或目前的標籤，都將版本固定為 0.6.11。在 apps/application/flow/tools.py 中，於 v2.10.3-lts 標籤的第 467 行，專案呼叫 create_deep_agent 並將 backend 設為 SandboxShellBackend，這是一個在主機上執行命令的 MaxKB 子類別。根據該公告，只要以這種方式傳入 shell 後端，deepagents 就會自動注入一組工具：execute、ls、read_file、write_file、edit_file、glob 與 grep。這些工具並不屬於 tools=list 引數的一部分，該引數僅包含操作者自己的工具、MCP 工具與技能工具。它們無法從介面中移除，也無法透過設定移除。

MaxKB 也同樣沒有傳入 excluded_tools，這個函式庫參數原本可以將其剔除。此安全公告在說明補救措施時，也審慎闡明了這件事為何重要：excluded_tools「會把工具從模型被告知的內容中移除，而不是從執行器中移除」。模型不知情的工具，與無法執行的工具，兩者之間的區別，正是這個漏洞的縮影。

一道列出三項工具、卻省略第四項的關卡

同一個呼叫中的人在迴路控制只有一行，而且它列舉了三項操作：interrupt_on={"write_file": False, "read_file": False, "edit_file": False}。寫入檔案、讀取檔案和編輯檔案都被明確列出。命令執行完全不是該字典中的鍵。依該諮詢文件的解讀，這表示執行（execute）不會尋求核准——這三個檔案系統操作被列出，並明確設定為不中斷，而 shell 工具則完全未被提及。

綜合來看，這條路徑是：不受信任的文字送達模型，模型呼叫 execute，然後命令執行。該安全公告指出，不受信任的文字有兩種送達方式。直接的方式是聊天——公開或內嵌的小工具，或另一個租戶的對話。間接的方式則是助理所攝取的內容：RAG 文件、上傳的檔案，或平台爬取至知識庫的網頁。Lasso 的文章讓第二條路徑具體化，指出「能把文字放到模型面前的人，比能和它聊天的人更多」。

在裸機安裝環境中，指令就只是指令。

MaxKB 在隔離方面所做的任何處理，都發生在 apps/application/flow/backend/sandbox_shell.py，而在 v2.10.3-lts 中，這始於一個預設值。第 9 行寫著 _enable_sandbox = bool(int(CONFIG.get("SANDBOX", 0)))，而 SANDBOX 並未出現在 apps/maxkb/conf.py 的 Config.defaults 中。若沒有明確的 MAXKB_SANDBOX 設定，該值即為零，第 65 行的包裝分支會被略過，execute 便會直接在主機上以 shell=True 到達 subprocess.run，並以執行該服務的使用者身分執行——用安全公告的說法，如果服務以 root 執行，那就是 root。

那就是研究人員用於主機端概念驗證的組態。他們在未設定 MAXKB_SANDBOX 的情況下，從原始碼執行 MaxKB 的實際程式碼，建立一個附掛單一工具的助理，並在單一聊天訊息中要求它執行系統資訊命令。execute 工具被觸發，並寫入一個檔案，其內容是主機本身的 uname、id 與 sw_vers 輸出——該公告指出，已確認這些輸出不存在於任何容器內。Lasso 也記錄了阻止它的機制有何限度：名稱露骨的證明檔案被模型拒絕，而看似無害的作業性措辭則沒有被拒絕。用他們的話來說，模型對齊是「部分的減速帶，而非一種控制措施」。

在官方映像上，沙箱雖然有運行，卻仍然外洩。

官方容器在基礎映像中設定了 MAXKB_SANDBOX=1，位置在 installer/Dockerfile-base 第 48 行，因此包裝程式在那裡是啟用的——而這個包裝程式正是第二個缺陷。它只組出一條字串：env -i LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so，後面接著 gosu sandbox，再接上模型提供的命令，然後交給一個以 root 身分執行的 shell。由於命令是以文字形式插值進去的，只有它的第一個 token 落在 gosu 之下。模型輸出中任何的分號、管線、重導向或命令替換，都會在沙箱看到它之前，先被外層的 root shell 求值。

Lasso 的報告說明了其實際運作形態：一份承載指令為 env -i LD_PRELOAD=... PATH="$PATH" gosu sandbox ls; whoami; id 的內容，其中 ls 受到限制，whoami 則不受限制，而它之後的所有指令都能自由執行。在測試中，研究人員在沙箱內的內部命令遭到封鎖時，透過重新導向寫入了一個由 root 擁有的檔案。更糟的是，installer/Dockerfile 與 installer/Dockerfile-base 都沒有包含 USER 指示，因此應用程式映像檔以 UID 0 執行——公告指出已確認執行時為 root。因此，容器無論如何都會執行命令，而沙箱只決定哪些命令在表面上被歸因於低權限使用者。

Lasso 所描述的完整攻擊流程完全不需要存取目標。攻擊者將命令放在網頁上，等待受害者的代理程式將其爬取進知識庫，接著受害者提出一個普通問題。回傳的答案正確且合法；注入的 curl 早已向攻擊者的伺服器發出請求。該公告指出，研究人員只測試了他們自己的部署，並未測試任何第三方或託管的 MaxKB 執行個體。

來源確立了什麼，以及哪些根本沒有被測量

機制、兩種部署模式、致謝與已修復版本在四份文件中說法一致：GitHub 公告、2026 年 9 月 21 日發布的 NVD 記錄、Lasso 於 2026 年 9 月 10 日自行發布的技術說明，以及 GBHackers 於 2026 年 9 月 22 日的報導；其中最後者，是針對此 CVE 所找到的唯一獨立媒體報導。沒有任何來源對該發現的任何部分提出異議，而檔案庫以最高信心等級將該條目記錄為無爭議。

這些來源完全沒有提供任何曝險程度的衡量。沒有 MaxKB 部署數量，沒有面向網際網路或內嵌式助理的數量，沒有掃描結果，沒有遙測資料，也沒有具名的受害者。紀錄中沒有任何內容顯示該漏洞曾被用來攻擊任何人，而 CISA 自身的利用評估也持相同看法：2026 年 9 月 22 日附加於 NVD 紀錄的 SSVC 區塊，將利用狀態評為「poc」、可自動化評為「yes」、技術影響評為「total」。FIRST 的 EPSS 模型於 2026 年 10 月 27 日將未來 30 天內遭利用的機率估為 1.05%，即第 64 百分位，且該 CVE 未出現在日期為 2026 年 10 月 27 日的 CISA Known Exploited Vulnerabilities 目錄中。該檔案庫自身的評級也反映相同證據：嚴重性為高，實際危害為否。

10.0 這個分數值得明確說明其適用範圍，因為它最可能被斷章取義地引用。這是公開或嵌入式助理情境的分數，其 CVSS 向量為 AV:N/AC:L/PR:N/UI:N/S:C——可從網路觸及、無需權限、無需使用者互動，且因助理內部的命令會越界進入主機作業系統而發生範圍變更。此分數由 CNA 給出，而此處的 CNA 是 GitHub 的公告計畫，這也是 CVE 紀錄來源識別碼所指之處。NVD 將相同向量列為次要指標，且截至 2026 年 10 月 28 日，將該條目列為「Deferred」（暫緩）狀態，意即 NVD 發布的是指派者的分析，而非其自身的分析。

修補程式比安全公告早了一個月推出。

時間順序從發表日往回推，而這是紀錄中最不直觀的部分。Lasso 於 2026 年 7 月 8 日透過 GitHub 的安全諮詢通道私下回報該漏洞。MaxKB 隔日回覆，將報告範圍限定於官方映像檔，並要求提供容器概念驗證；研究人員於 7 月 10 日提供了該項內容以及沙箱繞過方式。一項修正提交 594f50f2 於 7 月 9 日落地——也就是回報後一天——並改寫了 sandbox_shell.py，使模型的命令字串先被解析，且 gosu 前綴會套用到每個簡單命令，而不只是第一個命令，同時每個引數清單都會重新加上引號，讓替換無法逃逸到父 shell。Lasso 的報告將這項變更描述為把 gosu 前綴套用「到每個簡單命令，而不只是第一個」。

承載它的版本 v2.10.5-lts 於 2026 年 8 月 6 日發布。GitHub 公告於 9 月 2 日上線，NVD 於 9 月 21 日發布 CVE，CISA 的 SSVC 區塊於 9 月 22 日加入，GBHackers 也於同日報導，而 Lasso 自己的文章則於 9 月 10 日出現——是在這段序列的中段，而非開頭。追蹤版本標籤而非公告來源的操作人員，在警告出現前約四週就已取得修補程式。

版本邊界值得比這份公告所給予的更多關注，因為兩個主要來源的說法並不一致，而版本庫釐清了這個問題。公告的表單欄位將受影響版本記錄為「<= 2.10.3-lts」，並附註說明這點已在 2.10.3-lts 上驗證過，且該易受攻擊的路徑「可能」影響所有以這種方式建置代理的版本。Lasso 自家的說明則將受影響範圍記載為「<= 2.10.4-lts」。各標籤證實了這個更寬的範圍：2026 年 7 月 16 日發佈的 v2.10.4-lts，帶有與 v2.10.3-lts 相同的 75 行 sandbox_shell.py，而改寫後的 311 行檔案則首見於 v2.10.5-lts。只讀了公告所載範圍的 2.10.4-lts 維運人員，會據此認定自己不在受影響範圍內。但事實並非如此。

這個修正並未做到的事

2.10.5-lts 修正的是包裝器：它不再以 root 身分組建單一 shell 字串。它沒有做的，是針對該工具的任何處理。直接閱讀 2026 年 10 月 22 日發布、標籤為 v2.10.8-lts 的儲存庫可看出，代理仍以 backend=SandboxShellBackend 建構，且 interrupt_on 仍恰好帶有三個鍵——write_file、read_file 與 edit_file——而沒有 execute。該公告的前兩項補救建議——預設改以不執行（non-execution）的後端建構，以及在核准對照表中加入 "execute": True——並未出現在該版本中。

故障關閉的建議較晚才納入 v2.10.7-lts，而這對狀況最糟的部署模式至關重要。該建議於 2026 年 10 月 15 日發布，將 sandbox_shell.py 中的那一行從 CONFIG.get("SANDBOX", 0) 改為 CONFIG.get("SANDBOX", 1)。對於從未設定該變數的原始碼或裸機安裝，包裝器現在預設為啟用而非停用，這正是狹義上的「非容器部署採故障關閉」建議。該公告在同一標題下要求的不只如此——要求具備執行能力的流程在沙箱執行環境無法使用時拒絕啟動——並另行要求包裝器絕不為 root shell 建構命令字串。在容器方面，這是一項事實而非建議：在 v2.10.8-lts 標籤中，installer/Dockerfile 與 installer/Dockerfile-base 皆未包含 USER 指令，因此應用程式映像檔仍以 root 身分啟動。

綜合來看，截至 2026 年 10 月 28 日，紀錄所呈現的狀態如下。漏洞的後半部分，也就是一個分號就能走出的沙箱，已經關閉；主機部署上預設為失效開放（fail-open）的設定也已關閉。前半部分，也就是一個帶著後端物件到來、且不是核准對照表中鍵值的 execute 工具，仍是 MaxKB 建構具工具能力助理的方式。研究人員自己的補救建議是較狹窄的那一項：升級至 2.10.5-lts 或更新版本，並在啟用沙箱的情況下執行 Docker 版本。GBHackers 轉達了相同指示，並為管理員提供更廣泛的清單：除非明確需要執行程式碼，否則停用具備 shell 能力的代理後端；任何 execute 動作之前都要求人工核准；以非 root 身分執行容器；並將爬取的頁面、RAG 文件與上傳內容視為不受信任的輸入。

同一批九月資料中的另一筆 MaxKB 紀錄

歸檔中本批次的第二筆 MaxKB 條目，是另一個結局更糟的缺陷。CVE-2026-77516 同樣於 2026 年 9 月 21 日發布至 NVD，屬於權限繞過而非命令注入：從 2.0.0 版到 2.9.2 版，最低角色的工作區成員即使已透過 WorkspaceUserResourcePermission 被明確拒絕存取某項工具，仍可透過 tool_ids、skill_tool_ids 或 mcp_tool_ids 綁定該工具的識別碼，並經由代理或工作流程的派送路徑執行該工具。派送路徑不會重新套用專用工具路由所強制執行的個別工具授權，而工具執行會解密伺服器端的 init_params，因此呼叫者會收到其所被拒絕之工具所攜帶的憑證。其評分為 5.4，而 NVD 的描述以一句 CVE-2026-77521 不必承載的話作結：「截至本次審查，尚無已修正版本可用。」

對任何要判斷這兩個漏洞的人來說，真正有用的是這種對比。評分 10.0 的漏洞在一天內就有修正提交，且該修正於漏洞公布前一個月釋出。評分 5.4 的漏洞在其 CVE 公布時，尚無已釋出的修復版本。

真正仍未关闭的部分，比评分所暗示的要小，却比补丁说明所暗示的要大。该发现并无争议，其机制已由发现它的团队在两种部署模式下完成端到端验证。暴露面则完全未被测量——没有人公布有多少 MaxKB 助手附带工具、其中有多少可被不可信方触达，或有多少运行在未启用沙箱的主机上——因此该缺陷在现实世界中的后果取决于部署习惯，而没有任何被引用的来源统计这些习惯。而设计中把评分推到最高的那部分，在当前版本中依然存在：一项可运行命令的能力，默认附带，却未出现在那张要求先由人类确认的图中。