MaxKB：代理程式分派路徑讓遭拒使用某工具的使用者仍可呼叫該工具並讀取其憑證。

由 1Panel-dev 維護的開源企業級 AI 助理 MaxKB，提供依使用者與工具分別設定的權限清單，讓管理員可以授予工作區成員某項工具權限，同時拒絕另一項。根據 2026 年 9 月 2 日發布的安全公告，這項拒絕在工具自身的路由上仍有效，但在代理程式或工作流程用來呼叫同一工具的路徑上則未生效。僅具最低角色的工作區成員，在建立工作流程時可指定遭拒工具的識別碼、執行該工作流程，並取得的不僅是工具輸出，還包括 MaxKB 為執行該工具而在伺服器端解密出的憑證。2.0.0 至 2.9.2 版均受影響，且公告未指明任何已修補版本。本記錄——MaxKB 工具分派授權繞過——是 OrcaRouter AI Incident Archive 中的一筆條目，該檔案收錄完整記錄集以及此事件的相鄰條目。

這個案例值得細讀的原因不在於分數，而在於該產品早已具備正確的檢查，卻只套用在顯而易見的入口上，讓通往同一能力的第二道門無人看管。這份公告 GHSA-383v-fx78-pphm 由發現問題的研究人員撰寫，並透過 GitHub 的公告系統於 2026 年 9 月 2 日 07:43 UTC 發布，文中註明 Matteo Panzeri（@matte1782）。CVE 記錄 CVE-2026-77516 則於 2026 年 9 月 21 日隨後發布。

該公告所確立的事項

MaxKB 的每個工具模型是 WorkspaceUserResourcePermission，安全公告中將其描述為在請求時解析的預設拒絕允許清單。專用工具路由會強制執行此機制。該公告列出 apps/tools/views/tool.py 中的強制執行情形，其中 Operate.put、Operate.get、Debug.post、Export.get 和 Delete 都會針對呼叫者的工作區工具權限進行檢視權限檢查。Debug.post 是最接近直接執行工具的路由，而且它受到權限閘控。

agent 與 workflow 的派送路徑並不會重新套用該項檢查。此公告追查出三個各自漏掉該檢查的地方。在 apps/application/serializers/application.py 中，application serializer 直接從請求輸入綁定 tool_ids、skill_tool_ids與mcp_tool_ids，完全沒有針對個別工具進行授權；而公告指出，這種不對稱在同一個檔案裡就看得出來，因為 knowledge_id_list在下方幾行會依使用者可存取的知識庫進行驗證，工具卻沒有。在 apps/common/utils/shared_resource_auth.py 中，filter_authorized_ids會無條件放行呼叫者自身工作區中的所有工具；它所依賴的跨工作區閘門是企業版專屬的 hook，社群版並未提供，而且它從不查詢 WorkspaceUserResourcePermission。而在最終的執行點，apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py 會以應用程式的身分執行工具所儲存的程式碼，其中的 init_params由 rsa_long_decrypt解密，且未進行任何個別工具的授權檢查。

該公告將此結果稱為混淆代理執行：工作流程派送會執行一個工具及其儲存的機密，而同一呼叫者在該工具自身的路由上卻會被拒絕。憑證暴露則是超出一般未經授權工具使用範圍的部分。工具的 init_params 會在靜態儲存時以 RSA 加密，並僅在執行時於伺服器端解密，因此觸發該執行的呼叫者會收到他們從未持有、也無法提供的值。

以研究者自己的數據呈現的示範

安全公告報告了在 v2.9.2 上的動態確認，執行自官方一體化映像 1panel/maxkb:v2.9.2。該設定為一個工作區、一名管理員，以及第二個擁有 USER 角色的成員。管理員建立了工具 A 和工具 B，將全新的隨機密鑰放入工具 B 的 init_params，並編寫了工具 B 的主體，使其執行時傳回該密鑰。隨後僅為工具 A 向該成員授予了單一工具權限，安全公告稱，執行後已在資料庫中重新檢查了工具 B 的零授權狀態。

測試中被拒絕的那一半回傳了產品所承諾的結果。以成員身分測試時，Tool B 的偵錯路由回應 403、更新路由回應 403、匯出路徑回應 403，而已獲授權的 Tool A 則回應 200 作為健全性檢查。接著，繞過的那一半透過工具庫節點將 Tool B 綁定到工作流程應用程式中——該綁定以 HTTP 200 被接受，且沒有逐一工具檢查——而執行該工作流程回傳 HTTP 200，其內容包含工具名稱、哨兵密鑰，以及金鑰清單 ["api_key"]。

該公告指出，該機密出現在三個層面：在工作流程 API 回應中、在狀態為 SUCCESS 的工具執行記錄中，以及在資料庫資料列中，其中 Tool B 的 init_params以 344 位元組的 RSA 密文形式存在——研究人員據此主張，該值是在應用程式身分下於伺服器端解密，而非由呼叫方提供。同一名在該工具執行路由上被拒絕的成員，透過將其綁定到工作流程中，取得了該工具解密後的機密。

已公布一個分數，卻有人主張更高的分數

分配給 CVE-2026-77516 的分數為 CVSS 3.1 5.4，中度，向量為 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N。NVD 的紀錄顯示，該分數來自 GitHub 的公告資訊流，而非 NVD 自身分析；該條目狀態為 Deferred，表示 NVD 尚未對其進行增補。該存檔庫自身的分類依循此已公布分數：中度嚴重性，且未記錄到現實世界中的危害。

該公告自身的影響章節主張應更高。它指出嚴重性為 7.1（高），其向量將機密性影響提升為高，並表示當派送的工具以應用程式身分執行特權寫入時，該數值會升至 8.1。這爭議在於如何計算憑證暴露，而非繞過是否存在——同一份文件既展示了該缺陷，又主張其被低估。公開紀錄中沒有任何內容能釐清哪個數字才正確，而該檔案庫的中等評級追隨已公布的 CVE 分數，而非公告的主張。

另有兩項評估已記錄在案。CISA 的 SSVC 決策點於 2026 年 9 月 28 日加入 NVD 條目，將利用狀態記錄為「poc」、可自動化記錄為「no」、技術影響記錄為「partial」——「poc」值反映的是存在概念驗證，而該公告本身確實包含概念驗證；這並不代表已發現野外利用。FIRST 的 EPSS 模型在日期為 2026 年 10 月 27 日的估計中，將未來 30 天內遭利用的機率定為 0.242%，位於第 15.2 百分位。

有一個修正早於公告，而受影響範圍內則沒有任何修正

安全公告的版本表指出，受影響版本為 2.0.0 至 2.9.2，修補版本為無；其內文表示截至審查時尚無已修正版本，並補充說，若在帶標籤的發行版中提供修正，CVE 就能以該版本作為錨定依據。廠商的儲存庫說法略有不同，而這項差異對任何決定要執行哪個版本的人都很重要。

在 MaxKB 儲存庫中，關閉派送路徑的函式——validate_bound_tool_permissions 與 get_authorized_tool_ids（位於 apps/application/serializers/application.py）——在 v2.9.2 標籤以及 v2.10.2-lts、v2.10.3-lts 和 v2.10.4-lts 中皆不存在，而從 v2.10.5-lts 起才出現。該版本於 2026 年 8 月 6 日發布，比該公告早了四週。同一個標籤也為 base_tool_lib_node.py 新增了依使用者區分的工具檢查，並運用了 WorkspaceUserResourcePermission，同時為 shared_resource_auth.py 新增了可辨識使用者的篩選機制——也就是說，它大致上實作了該公告後來建議的三項補救步驟。

沒有人公開表示過這種關聯。v2.10.5-lts 的發行說明並未提及工具權限修正；它們列出四項不相關的安全項目，以及一批功能與錯誤修正工作。該公告未指名 2.10.5，而其受影響範圍只到 2.9.2，也就是 2.9 系列的最後一個版本。發行歷史顯示公告之後沒有 2.9.x 修補程式，因此在 2.9.2 上的部署在其自身系列內沒有已修正的組建。目前版本是 v2.10.8-lts，於 2026 年 10 月 22 日發布，其說明描述的是 X-Pack 對共用工具授權的修正，而非社群版分派路徑中的任何內容。

什麼尚未確立？

有三件事值得與這項示範區分開來看。首先，沒有公開報告指出該繞過手法曾被用於攻擊任何人。現有紀錄是發現了一項漏洞，而非調查了一起入侵事件；其中沒有受害者、沒有被歸因的行為者，也沒有造成任何損害，而公告中的概念驗證是由研究人員在受控工作區中執行。其次，似乎沒有新聞機構、監管機構或第二個研究團隊分析過該漏洞：現有的報導僅限於漏洞資料庫與彙整平台——包括 VulDB、Rapid7 的資料庫、Armis、SOCRadar 和 openCVE 等——它們列出該 CVE 並刊載公告的說明，且都沒有對程式碼提供獨立評估。因此，這裡所描述的機制僅依據一份安全公告和廠商自身的原始碼。第三，對於有多少 MaxKB 部署處於受影響範圍內，並沒有任何數字；廠商和研究人員也都沒有公布。

受影響的族群範圍狹窄，但數量並非微不足道：在 2.0.0 至 2.9.2 版、具有多於一名工作區成員的自架社群版 MaxKB 安裝，且管理員曾透過個別工具權限，不授予某個帶有憑證的工具。此缺陷並非遠端程式碼執行，且需要一個有效的低權限帳戶，因此驅動評分的是機密性影響，而非攻擊路徑。攻擊者所能獲得的內容，取決於被拒絕之工具所持有的東西——API 金鑰、權杖，以及這些憑證能解鎖的一切——這也是為何公告作者主張，其影響大於低機密性評級所暗示的程度。

操作員能做什麼

該公告的補救措施是針對維護者而非操作人員，其三個步驟對應到 v2.10.5-lts 中出現的程式碼：在工具庫與工具節點實作中執行工具之前，先套用個別工具的授權；驗證每個已綁定的 tool_ids、skill_tool_ids 與 mcp_tool_ids，在綁定時要如同 knowledge_id_list 已經做的那樣，並讓 filter_authorized_ids 查詢個別工具的授權，而不只是工作區成員資格。

對於執行受影響組建的團隊而言，依據該公告本身的說明，接下來可採取的實際步驟如下。

• 請將受影響部署中，工具 init_params 內所儲存的每一項密鑰，都視為任何工作區成員（包括權限最低的角色）皆可觸及，並輪替這些憑證，而不要假設個別工具的拒絕設定已保護了它們。

稽核工作區成員資格。此繞過手法需要在工作區中有一個已驗證的帳戶，因此移除閒置或不受信任的成員可降低暴露風險，即使在程式碼無法修補的情況下亦然。

• 檢視哪些工作流程與代理程式會綁定帶有憑證的工具，因為該公告指出，這個綁定步驟是在未逐一檢查各工具的情況下就被接受的。

• 若進行升級，請注意，每位使用者的檢查從 v2.10.5-lts 起出現在儲存庫中，且該公告並未指定任何版本為修正版本——依賴升級的操作人員所依賴的是帶標籤的原始碼，而非供應商的修補聲明。

這些都無法讓這個缺陷顯得戲劇化。它反而以一種具體且有啟發性的方式顯得平凡：授權模型設計正確、文件記錄正確，並且在有人記得要加上控管的那些路徑上落實執行。分派路徑是由那些思考工作流程應該能做什麼、而非思考是誰在提出請求的人所撰寫——而在代理平台中，那正是大多數請求實際走上的路徑。

這筆記錄帶來的教訓是結構性的，而非數字上的。以個別資源為單位的權限，其強度取決於防護最薄弱的進入點，而代理平台累積進入點的速度很快：一條偵錯路由、一條匯出路徑、一個工作流程節點、一個聊天觸發器。MaxKB 有授權清單，也有檢查機制；但在 2.0 到 2.9 這條版本線上，它欠缺的是在每一道門前都問同一個問題的習慣。