MCP工具需要動作層級授權

2026年5月17日，NVD發布AI Engine 3.4.9的CVE-2026-8719。AI Engine是一個WordPress外掛，讓WordPress網站能使用AI與MCP功能。¹³

這種失效模式應該讓每位MCP建置者都坐立難安。Wordfence指出，MCP OAuth bearer token授權路徑缺少WordPress能力檢查：任何有效的OAuth token都能觸及管理員層級的MCP工具，卻沒有驗證是否具備管理員權限。²Wordfence將此問題評為8.8 High，並標示3.5.0為修補版本。²此外掛的變更紀錄表示，3.5.0透過要求管理員能力，修正了MCP OAuth授權與token驗證。³

當伺服器把持有bearer token視為可使用所有工具的權限時，MCP授權就失效了。OAuth可以證明token是透過授權流程取得。MCP伺服器仍必須判斷該主體是否能在該資源上、以該影響範圍執行該工具。

重點摘要

MCP的HTTP授權規格提供建置者必要基礎：受保護資源中繼資料、OAuth 2.1流程、bearer token處理、token驗證、audience檢查，以及在授權範圍或權限不足時明確回傳403 Forbidden。⁴MCP安全教學則將授權定位為保護層，用來防護MCP伺服器暴露的敏感資源與操作。⁵但這些機制並不會取代應用層授權決策。伺服器仍須把token對應到使用者、角色、租戶、工具、資源、動作與政策。

CVE-2026-8719把這項差異化為具體失敗案例。AI Engine在5月12日發布的3.4.9版本，為其MCP伺服器加入OAuth 2.1與Dynamic Client Registration；接著在5月16日的3.5.0版本中，透過要求管理員能力，修補MCP OAuth授權與token驗證。³這個教訓不只適用於WordPress：任何能變更資料、發布內容、修改設定、讀取私人紀錄、花錢，或呼叫特權API的MCP伺服器，都需要在模型與用戶端之下執行動作層級授權。

工具散布會放大風險。2026年5月的一篇工具複製研究檢視了8,861個MCP與Skills儲存庫、共100,011個工具項目，並在高相似度區間發現很高的已驗證複製率。⁶重複使用模板可以傳播良好模式，也可能一併傳播缺失的檢查。

主要結論

給MCP伺服器建置者： - 先驗證token，再授權具體動作。請把兩者視為不同關口。 - 對無效或缺漏token回傳401；對有效但缺少授權範圍或權限的token回傳403。 - 用低權限token測試每個管理、寫入、發布、刪除、匯出與設定工具。

給安全團隊： - 以應用程式端點的標準審查MCP伺服器，而不是把它當成聊天外掛。 - 詢問每次工具呼叫對應到哪個使用者、角色、租戶、資源與動作。 - 要求記錄包含token主體、工具名稱、資源、授權判定與拒絕原因。

給代理平台團隊： - 市集數量不等於獨立實作數量。 - 相似度與來源檢查很重要，因為複製工具可能連同脆弱的授權邏輯一起複製。 - 將伺服器模板視為安全敏感基礎設施。

給營運者： - 如果正在使用受影響的WordPress外掛，請升級AI Engine至3.5.0或更新版本。²³ - 在確認哪些WordPress角色能觸及哪些工具前，先停用MCP暴露面。 - 每個新的MCP連線都先以唯讀模式啟動；只有在測試證明拒絕路徑有效後，才逐步擴大權限。

AI Engine壞在哪裡

AI Engine將MCP定位為一種連接方式，讓Claude Code、Claude、ChatGPT、OpenClaw與其他用戶端透過URL、登入流程與核准步驟連到WordPress網站。³3.4.9版本為MCP伺服器加入OAuth 2.1與Dynamic Client Registration，讓瀏覽器驅動的用戶端不必依賴共享bearer token也能連線。³

這個產品方向合理。共享的靜態token並不適合面向使用者的MCP整合。相較於複製貼上的密鑰，OAuth流程能更清楚地綁定用戶端、使用者與伺服器。

問題藏在下一層。根據NVD與Wordfence，脆弱路徑接受任何有效OAuth token來取得MCP存取權，卻沒有在授予管理員層級MCP工具存取權之前驗證管理員權限。¹²差別在於：

WordPress外掛頁面的修補說明用語正確：MCP OAuth授權與token驗證現在需要管理員能力，以防止非管理員使用者提升權限。³這句話點出了缺失層。Token不能替代能力檢查。

OAuth是必要條件，不是充分條件

MCP的授權規格涵蓋HTTP型傳輸的傳輸層流程。規格指出，MCP用戶端會代表資源擁有者向受限的MCP伺服器發出請求，並將流程建立在OAuth 2.1、受保護資源中繼資料、授權伺服器中繼資料、Dynamic Client Registration與bearer token使用之上。⁴

這些元件確實解決了實際問題：

MCP規格也警告confused-deputy與token-passthrough風險。MCP伺服器必須驗證提交的token目標是該MCP伺服器，也不得把從MCP用戶端收到的token轉交給上游API。⁴這項指引保護的是服務之間的邊界。

動作層級授權保護的，則是MCP伺服器內部的邊界。

一個MCP伺服器可能暴露10個工具，也可能暴露100個工具。有些工具讀取公開中繼資料。有些讀取私人紀錄。有些草擬變更。有些會修改正式環境狀態。有些管理使用者、外掛、付款、工作、訊息或基礎設施。伺服器接受會話，不代表有效token就應自動觸及所有工具。

正確鏈條應該如下：

1. 驗證token簽發者、簽章、到期時間、audience與傳輸規則。
2. 將token解析為本地主體：使用者、服務帳號、組織、租戶或自動化。
3. 載入該主體的角色、授權範圍、授權、預算與政策。
4. 依動作類型與風險分類請求的MCP工具。
5. 檢查目標資源，而不只是工具名稱。
6. 當token有效但動作超出權限時，回傳403。
7. 記錄足以供日後審查的決策細節。

OAuth把請求帶到決策點。授權決定該動作是否屬於該主體的權限範圍。

工具呼叫需要權限矩陣

代理工具讓舊式端點習慣更危險。一般網頁路由通常有狹窄的UI路徑包住它。面向模型的工具則位於規劃器之中。代理可以重試、串接呼叫、檢查工具描述、把讀取結果與寫入動作結合，並將不可信內容中的指令帶入後續步驟。

這種行為改變了最低權限模型。伺服器不該只問「這個使用者能否存取MCP？」而應該問：「這個使用者現在能否透過這個工具，對這個資源執行這個動作？」

請使用矩陣：

這個矩陣符合代理金鑰需要風險預算的模式。憑證不該像萬用bearer字串。它們應該像有界權限物件，具備伺服器端限制、活動記錄、撤銷機制與保守預設值。

它也符合AI代理所有權是信任原語中的所有權框架。每次特權工具呼叫都應對應到負責帳號、會話、權限組合、審核路徑與停止路徑。

複製工具可能複製同一個缺失檢查

即使每個MCP伺服器都來自謹慎的獨立實作，AI Engine的問題仍然重要。但工具生態系看起來沒有那麼乾淨。

Kim、Jiang、Hu、Jia與Gong在2026年5月10日發表一篇論文，測量agentic-AI生態系中的工具複製現象。他們的資料集涵蓋7,508個MCP儲存庫、87,564個擷取工具，以及1,353個Skills儲存庫、12,447個工具，總計8,861個儲存庫與100,011個工具項目。⁶作者使用token層級Jaccard相似度與ssdeep模糊結構相似度，並在不同相似度區間手動驗證抽樣配對。⁶

論文摘要指出，在MCP生態系中，高Jaccard候選項有60%經手動驗證為複製，高ssdeep候選項則有85%經手動驗證為複製。⁶該文主張，隱性重複可能污染基準測試分割、傳播脆弱實作、扭曲工具使用泛化能力的衡量，並帶來來源、歸屬與授權疑慮。⁶

這項發現改變了團隊看待MCP市集成長的方式。更多工具不會自動代表更多獨立安全審查。重複的伺服器腳手架可以為生態系帶來一致性；同樣的重複，也可能把相同的薄弱驗證模式複製到許多套件。

因此，安全審查應納入來源：

代理技能需要套件管理器主張，Skills需要套件式散布、來源資訊與政策。MCP伺服器也需要同樣紀律，再加上執行環境授權測試。

MCP授權的最低測試套件

凡是碰觸私人或可變資料的MCP伺服器，都應附上授權測試套件。只確認成功路徑的單元測試並不足夠。危險行為藏在拒絕路徑裡。

從這些案例開始：

實際狀態碼可以依產品政策調整，但差異應保留：無效憑證在主體解析前失敗；有效憑證若權限不足，則在授權關口失敗。MCP規格將缺少或無效授權對應到401，將授權範圍無效或權限不足對應到403。⁴

以WordPress而言，同一規則更明確：執行管理操作的MCP工具，應檢查與控制台、REST API或內部PHP路徑相同的WordPress能力。低權限角色不應因為呼叫是透過面向模型的協定送達，就取得通往管理員行為的新路徑。

市集審查應要求什麼

MCP市集與外掛目錄應把授權中繼資料視為一級套件資料。使用者決定是否啟用伺服器時，需要的不只是工具數量。

最低公開中繼資料如下：

這些欄位無法消滅脆弱工具，但能讓審查面變得真實。營運者可以對照宣告權限與實際程式碼，市集也能在缺陷出現時將相似實作分組。

這正是MCP授權規格與工具複製論文之間缺少的橋梁。規格告訴實作者如何完成協定層流程；生態系還需要套件層來源資訊與動作層授權證據，才不會讓重複實作一再重複相同的缺失檢查。

應該改建成什麼

將MCP授權建成一條管線：

1. 協定關口：驗證受保護資源中繼資料、OAuth流程、token位置、token有效性、到期時間、簽發者與audience。
2. 主體關口：將token對應到使用者、服務帳號、角色、租戶與工作區。
3. 工具關口：將每個工具分類為讀取、草擬、寫入、刪除、發布、匯出、管理、執行或花費。
4. 資源關口：授權精確的目標物件或租戶邊界。
5. 預算關口：在執行前套用速率、大小、花費、受眾與時間限制。
6. 核准關口：高風險動作需要人工或政策核准。
7. 稽核關口：將允許、拒絕與需要審核的判定記錄在營運者可檢查的位置。

這些關口應位於模型之外。工具描述可以告訴代理避免管理動作。提示詞可以要求謹慎。但邊界不能由它們承擔。即使代理禮貌、自信或反覆提出請求，伺服器也應拒絕未授權動作。

您的代理沙箱只是一項建議從另一個角度提出同一點：有效權限仍可能組合成不安全行為。MCP工具需要在動作邊界執行授權，因為代理組合動作的速度，會快過人類在腦中模擬後果的速度。

FAQ

MCP需要OAuth嗎？

不需要。MCP授權是選用的；HTTP授權規格適用於實作支援HTTP型傳輸授權時。同一份規格也指出，STDIO傳輸應從環境取得憑證，而不是走HTTP OAuth流程。⁴

OAuth能解決MCP授權嗎？

OAuth只解決問題的一部分。OAuth可以建立授權流程、簽發token，並讓受保護的MCP伺服器驗證bearer token。MCP伺服器仍須判斷token主體是否可以對目標資源執行特定工具動作。

CVE-2026-8719證明了什麼？

CVE-2026-8719證明，有效token路徑仍可能缺少本地能力強制執行。NVD與Wordfence描述AI Engine 3.4.9會接受任何有效OAuth token來取得MCP存取權，卻沒有在管理員層級MCP工具可被觸及之前驗證管理員權限。¹²

MCP建置者應先測什麼？

先測拒絕路徑：低權限token呼叫管理工具、唯讀token呼叫寫入工具、有效token存取其他租戶資源、過期token、audience錯誤token，以及沒有核准狀態的破壞性工具。OAuth成功路徑通過，並不代表動作層級授權成立。

為什麼工具複製會影響MCP安全？

工具複製很重要，因為重複實作可能重複相同的脆弱中介軟體、驗證捷徑與缺失檢查。2026年5月的工具複製論文在高相似度MCP候選項中發現很高的已驗證複製率，並警告隱性重複可能傳播脆弱實作。⁶

參考資料