CVE-2026-77243 值得注意的地方，不只是又一個高風險漏洞，而是它揭露了代理式 AI 工具鏈裡一個容易被誤解的安全邊界：工具沒有出現在清單中，不代表伺服器真的禁止執行它。當管理者把「隱藏」當成「授權」，最小權限便可能只存在於介面上，沒有落實到執行層。
事件背景：限制看似生效，實際上只藏住名稱
依據 CVE 彙整頁面，MCP Atlassian 是連接 Jira、Confluence 與 AI 用戶端的 Model Context Protocol（MCP）伺服器。0.22.0 以前的版本，雖會依照 ENABLED_TOOLS 與 TOOLSETS 過濾回傳給用戶端的工具清單，卻沒有在收到 tools/call 請求時重新檢查。知道隱藏工具名稱的用戶端，因此可以直接呼叫原本被排除的讀取、寫入或刪除功能。原始資料頁面：https://cvefeed.io/vuln/detail/CVE-2026-77243。
專案官方 GitHub 安全公告交叉驗證了這項描述：受影響版本為 0.22.0 以前，修補版本為 0.22.0；漏洞版本的 tools/list 會過濾結果，但 tools/call 仍從完整、未過濾的 73 項工具註冊表中派送。公告並示範，在只允許 jira_search 的情況下，直接呼叫未列出的 jira_get_issue 與 jira_create_issue 仍可執行。官方公告：https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-3r68-hf9h-887v。
運作機制：發現工具與授權工具是兩件事
來源事實：MCP 用戶端可以先取得工具清單，再以工具名稱送出呼叫。漏洞版本只在「列出哪些工具」這一步套用政策，真正執行時則交由底層工具管理器從完整註冊表查找。工具名稱也不是秘密：專案本身是開源軟體，名稱可能來自原始碼、文件、舊版清單、快取、紀錄，甚至模型先前保留的上下文。
合理推論：攻擊者不必破解 Jira 或 Confluence，也不必誘使模型重新探索工具；只要已能向該 MCP 端點提出請求，並取得可被後端接受的身分或連線權限，就能繞過伺服器管理者設定的工具級限制。這是「已通過入口驗證，但越過功能授權」的問題，而非工具名稱遭猜中的一般資訊洩漏。
修補提交把判斷集中到共用的 _is_tool_authorized，讓列示與呼叫都檢查 ENABLED_TOOLS、toolset 與唯讀模式；未授權工具會以與不存在工具相同的錯誤拒絕，避免額外洩漏。提交還加入派送層迴歸測試，確認遭拒呼叫不會抵達執行器。修補內容：https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460。
為何現在值得注意
MCP 正從單機個人工具走向多人共用、以 HTTP 提供服務的企業整合。官方 MCP 架構文件強調主機端應處理授權決策、安全政策與同意要求，伺服器也必須遵守安全限制：https://modelcontextprotocol.io/specification/2025-11-25/architecture。這表示工具清單可以是發現機制或介面裁剪，但不能取代每次操作的授權。
作者觀點：代理系統放大了這類缺口。傳統使用者通常只會點選畫面上看得到的功能；代理或自動化程式卻能自行組裝 JSON-RPC 請求，也可能從先前會話或文件取得工具名稱。因此，任何只在工具發現階段執行的限制，都應被視為使用體驗設定，而不是安全控制。
實際影響與容易忽略的限制
官方評分為 CVSS 3.1 的 8.8 分，向量包含網路可達、低攻擊複雜度、需要低權限、不需使用者互動，以及機密性、完整性與可用性的高衝擊。可能後果取決於 MCP Atlassian 所持憑證原本能做什麼：若服務帳號可讀取內部議題、建立 Jira 工作項目、修改或刪除 Confluence 頁面，繞過後的呼叫也可能承接這些權限。
但這不等於所有安裝都能被網際網路匿名接管。官方公告指出，風險主要集中在多人或 HTTP 傳輸部署；單一使用者的 stdio 模式沒有第二個主體需要由工具篩選隔離。此外，READ_ONLY_MODE 原本已有列示與呼叫雙重防護，公告明確表示它不受這個特定缺陷影響。是否真的能讀、改、刪資料，仍受 Atlassian 帳號權限、網路可達性、端點驗證及其他控制約束。
對台灣組織的意義
台灣軟體、金融、製造與跨國協作團隊常以 Jira 管理缺陷、客戶案件及研發排程，也以 Confluence 保存設計、維運和內控文件。若企業讓 AI 助理透過共用 MCP 服務存取這些系統，盤點時不能只查看模型介面顯示哪些工具，而要從傳輸層直接測試被排除的工具名稱是否仍可呼叫。
- 立即確認 mcp-atlassian 版本，低於 0.22.0 者升級至 0.22.0 或更新版本；官方版本頁面為 https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0。
- 在測試環境對每個遭排除工具直接送出
tools/call，驗證請求於執行器之前被拒絕，而非僅從tools/list消失。 - 重新檢查服務帳號、API token 與 OAuth scope，避免 MCP 層失守時直接承接過大的 Jira、Confluence 權限。
- 檢索既有紀錄中「清單未出現、卻發生呼叫」的落差，特別關注建立、更新、刪除及附件操作。
後續觀察指標
第一，組織是否已完成所有執行實例與容器映像的升級，而不只是更新設定檔。第二，其他 MCP 伺服器是否也把 allowlist、角色或唯讀規則只套在列示階段。第三，日誌能否同時記錄呼叫者、工具名稱、授權決策與下游 Atlassian 操作結果。第四，安全測試是否把「已知名稱直接呼叫」納入固定案例。
這起事件最重要的教訓是：工具發現控制的是代理「看見什麼」，執行層授權控制的才是代理「能做什麼」。兩者可以共用同一套政策，但絕不能只實作前者。