受影響的版本會將用戶端密鑰、授權碼以及 PKCE 驗證金鑰傳送至攻擊者控制的權杖端點。此修補程式已包含在 1.30.0 和 2.2.0 版本中。
模型上下文協定 (MCP) 是一個開放標準，用於將 AI 應用程式連接到外部工具和資料，而此套件是建置 MCP 伺服器和用戶端的官方 Python SDK。
透過竊取的憑證，攻擊者可以從真實的登入服務請求有效的存取權杖。報告此漏洞的資安公司 Cycode 在測試中展示了完整的交換過程，並表示產生的權杖具有應用程式被授予的任何權限。用戶端密鑰的有效期限長，因此在變更之前一直有效。
對於兩個無人值守的提供者，此漏洞的評分為高 (7.5)。對於需要有人啟動登入的互動式提供者，評分為 6.5。截至 9 月 29 日，尚未分配 CVE。
用戶端會將其密鑰、授權碼以及 PKCE 驗證金鑰傳送給攻擊者，而非真實的服務。驗證金鑰是一個一次性值，旨在防止被盜的授權碼被重複使用，因此將其交出也會破壞該保護措施。
在互動式提供者中，使用者仍需批准登入。Cycode 表示，他們批准的頁面是真正的登入頁面，因此看起來沒有任何異常。兩個機器對機器的提供者則不需要登入，也不需要任何人參與。
如果應用程式使用 SDK 作為 MCP 用戶端，透過 HTTP 連接至 OAuthClientProvider、ClientCredentialsOAuthProvider、PrivateKeyJWTOAuthProvider 或已棄用的 1.x RFC7523OAuthClientProvider 等 OAuth 提供者之一，並且能夠連接到一個它無法完全控制的伺服器，同時持有真實登入服務的憑證，那麼該應用程式就會受到影響。使用 SDK 建置的 MCP 伺服器、本機 (stdio) 用戶端以及附加自身權杖的用戶端不受影響。
請升級至 1.x 系列的 1.30.0 版本或 2.x 系列的 2.2.0 版本。在已修補的版本中，用戶端會在擷取任何詳細資訊之前，先確定預期的登入服務，並拒絕任何名稱不同的服務。
對於兩個提供者而言，升級並非完整的解決方案。如果您使用 ClientCredentialsOAuthProvider 或 PrivateKeyJWTOAuthProvider，建議說明中提到「升級不會改變任何情況，除非您也傳遞 issuer= 來命名這些憑證所屬的登入服務。否則，它們仍會遵循 MCP 伺服器指向的任何伺服器。」
在 1.30.0 版本中，關於此問題的警告是一個標準的棄用警告，Python 預設會隱藏它，因此很容易被忽略。已棄用的 RFC7523OAuthClientProvider 完全沒有 issuer= 選項，因此請遷移到其他兩個提供者之一。
升級後，請清除所有已儲存的 OAuth 用戶端註冊一次，因為舊的註冊與登入服務沒有關聯，並且會保持這種狀態。如果用戶端可能已經連接到不受信任的伺服器，請輪換其用戶端密鑰並在登入服務中撤銷其權杖。在舊版本中，除了僅連接您信任的 MCP 伺服器外，沒有其他解決方法。
issuer 檢查已包含在 1.30.0 和 2.2.0 的發行說明中，於 9 月 7 日發布，列在行為變更之下，而非安全修補程式。該建議隨後於 9 月 28 日發布，與 Cycode 發布其報告的同一天。該建議歸功於八位報告者，包括 Cycode 的研究員。
無論是建議還是 Cycode 的報告，都沒有提及使用此漏洞的攻擊，也沒有在其他地方報告過。
AI 代理程式已在企業內部運作，並日益存取敏感系統和資料——而安全團隊仍然缺乏可見性、控制和治理來遏制這種存取。
攻擊者正在利用 AI 加速偵察、危害身分並升級存取權限。了解安全團隊如何透過執行階段身分控制進行反擊。
免費獲取來自產業領導者的最新新聞、專家見解、獨家資源和策略。
