這起事件的核心，不是假的登入頁面，而是 MCP 客戶端把真的 OAuth 憑證送錯地方。安全公司 Cycode 揭露，MCP Python SDK 的特定 OAuth 探索路徑未驗證授權伺服器身分；惡意 MCP 伺服器因而可能取得授權碼、PKCE 的 code_verifier，以及部分情境下的客戶端密鑰，進一步向真正的身分供應商換取存取權杖。最初報導可見 https://gbhackers.com/anthropic-mcp-python-sdk-flaw/，技術研究則見 https://cycode.com/blog/mcp-python-sdk-oauth-account-takeover/。
漏洞發生在「該相信誰」
MCP 讓 AI 應用程式連接外部工具與資料。遠端 MCP 伺服器若要求 OAuth，客戶端必須先找出授權頁面與權杖交換端點。正常流程會先取得受保護資源中繼資料，再讀取授權伺服器的設定，並確認設定中的 issuer 與預期身分一致。
已查證事實：Cycode 指出，惡意伺服器只要讓現代探索要求收到 HTTP 404，就能迫使 SDK 進入舊版相容路徑。由於此時內部的預期授權伺服器網址仍是空值，原有程式邏輯不會讓驗證失敗，而是直接略過 issuer 檢查。攻擊者遂可在中繼資料中填入真正身分供應商的授權頁面，卻把權杖端點改成自己控制的網址。
為何真實登入頁仍可能導致失守
使用者看到的可以是真正的 Google、Okta、Microsoft Entra ID 或其他企業身分系統，網址與 TLS 憑證都沒有異常。完成登入後，授權碼返回 MCP 客戶端；問題出在下一步：SDK 依據遭操控的中繼資料，把授權碼、PKCE 驗證值及適用的客戶端憑證送往攻擊者端點。攻擊者再把這些材料轉送至真正的權杖端點，便可能取得合法權杖。
PKCE 原本用來防止「只偷到授權碼」的攻擊，但這次連 code_verifier 一併外洩，因此不能單獨阻斷攻擊。這也是此漏洞最容易被誤判之處：使用者沒有進入釣魚網站，身分供應商看到的也可能是一組完整、有效的交換請求。
影響範圍不是所有 MCP 部署
已查證事實：受影響的是以 HTTP 連接遠端伺服器、使用 OAuthClientProvider、ClientCredentialsOAuthProvider 或 PrivateKeyJWTOAuthProvider 的 MCP Python SDK 客戶端。版本範圍為 1.9.1 至 1.29.1，以及 2.0.0 至 2.1.1；修正版分別是 1.30.0 與 2.2.0。SDK 建置的伺服器端、本機 stdio 客戶端，以及自行附加權杖或標頭的客戶端，不在研究者列出的影響範圍。
官方專案的 2.2.0 發行說明證實，新版會在舊版探索路徑也檢查授權伺服器的 issuer，並為兩種機器對機器的供應器加入 issuer= 設定；跨來源 HTTP 重新導向也受到限制。這與研究報告描述的修補方向一致：https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0。
為何現在值得注意
MCP 的信任模型正從「使用者手動安裝一個工具」走向「代理程式動態連接多個遠端服務」。官方 2026 年 7 月版規格已把授權回應的發行者驗證，以及憑證與發行者綁定，列為授權強化項目：https://blog.modelcontextprotocol.io/posts/2026-07-28/。這次漏洞顯示，規格即使定義了正確控制，只要相容性分支沒有採用相同的失敗策略，舊路徑仍可能成為繞道。
合理推論：互動式登入至少需要使用者啟動或核准流程；機器對機器供應器則可能在背景執行，沒有可辨識的登入畫面。因此企業真正需要優先盤點的，不只是開發者桌面上的 MCP 工具，也包括代理程式閘道、排程作業、CI/CD 與持有預先配置憑證的後端服務。
實際影響與容易忽略的限制
取得權杖不等於自動取得整個企業環境。實際損害仍受 OAuth scope、權杖有效期、身分供應商政策、資源端權限及是否核發 refresh token 限制；攻擊也須讓受影響客戶端連向攻擊者可控制或冒充的 MCP 端點。公開研究展示的是可行的端到端攻擊鏈，不能據此推定已有大規模利用，原始資料亦未提出受害組織數量。
另一項限制是名稱容易造成誤解。媒體稱它為「Anthropic MCP Python SDK 漏洞」，但需要修補的是 mcp Python 套件的特定客戶端與版本，不代表所有 Anthropic 產品、所有 MCP SDK，或所有 OAuth 部署均受影響。
台灣團隊應採取的動作
- 建立 Python 相依套件清冊，將 1.x 升至 1.30.0 以上、2.x 升至 2.2.0 以上，並確認實際執行映像而非只有鎖定檔已更新。
- 使用
ClientCredentialsOAuthProvider或PrivateKeyJWTOAuthProvider時明確設定issuer=，不要只依賴新版的棄用警告。 - 清除舊版留下、尚未綁定發行者的 OAuth 客戶端註冊資料。若曾連接不受完全信任的遠端 MCP 伺服器，應撤銷既有權杖並輪替客戶端密鑰。
- 把 MCP 伺服器目錄視為軟體供應鏈：採白名單、固定網域與出口流量監控，記錄探索文件、
issuer、授權端點及權杖端點的變化。
後續觀察指標
作者觀點：這起事件真正的警訊，是 AI 代理程式開始替人決定「連哪個服務、把憑證送到哪裡」。後續應觀察三件事：企業是否能辨識所有遠端 MCP 客戶端、機器身分是否全面釘選發行者，以及監控系統能否發現探索端點突然回傳 404、權杖端點跨網域或 issuer 改變。若治理仍只停留在模型輸出與提示注入，而沒有涵蓋 OAuth 探索與憑證流向，最敏感的風險可能根本不在模型裡，而在模型連接外部世界的那一層。