AutoJack 漏洞鏈曝光：微軟研究揭露 AI 代理如何被單一網頁挾持

1. 盲目信任 localhost

MCP WebSocket 預設接受所有來自迴路介面（127.0.0.1）的流量，並將其視為可信任的內部請求。它並未驗證請求是否真的來自合法的 AI 代理，還是來自代理正在渲染的惡意網頁內容 。由於代理本身是在本機運作，任何由代理載入的網頁都能夠發送 WebSocket 訊息，而 MCP 服務會將這些訊息誤認為來自可信任的本機來源。

2. WebSocket 端點缺乏身分驗證

MCP WebSocket 不需要任何身分驗證、階段權杖（session token）或來源檢查（origin check）。任何本機程序——或由代理渲染的網頁中執行的腳本——都能直接連上 WebSocket 並發送指令，完全不需要憑證 。這意味著服務完全無法區分合法的代理工具呼叫與攻擊者網頁注入的惡意指令。

3. 不安全的程序執行機制

MCP 服務會盲目執行經由 WebSocket 接收到的工具指令。它允許任意建立程序，沒有任何沙盒保護、能力檢查（capability check）或使用者確認機制 。一旦攻擊者的內容成功連接 WebSocket，就能指示服務在主機上執行任何命令。

當這三大弱點結合在一起時，一個惡意網頁就能指令 AI 代理的瀏覽引擎連接 MCP WebSocket、發送精心設計的工具指令，並執行任意程式碼——整個過程使用者完全不需要點擊第二個按鈕 。

受影響的版本與修復方式

此漏洞僅存在於 AutoGen Studio 的開發分支——這是微軟 AutoGen 多代理框架的開放原始碼原型 UI 。它從未包含在任何正式發布的 PyPI 版本中 。微軟透過 Microsoft Security Response Center (MSRC) 向 AutoGen 維護團隊報告此問題後，開發分支已經完成修復 。使用者應更新至最新版本的 AutoGen Studio 以套用修補程式 。截至現有資料，尚未有相關的 CVE 編號發布。

對 AI 代理安全性的廣泛影響

除了這項特定漏洞，微軟特別強調，AutoJack 展現了任何結合網頁瀏覽與本機工具存取的 AI 代理框架所面臨的根本架構風險 。瀏覽器沙盒原本的設計目的是將網頁內容與作業系統隔離。然而，當一個 AI 代理位於這個信任邊界之內，並根據所渲染的內容執行操作時，它無意間為開放的網際網路與特權本機操作之間搭起了一座橋樑 。

微軟警告，當 AI 代理參與運作時，傳統上將 localhost 視為安全隱形信任區的假設已不再成立 。該公司建議所有 AI 代理框架應採用：

• 明確的身分驗證：所有 MCP 端點都應要求驗證，即使是監聽在 localhost 的服務也一樣
• 來源驗證：確保只有合法的 AI 代理能發送指令
• 基於能力的存取控制：限制每個工具指令所能執行的操作
• 程序沙盒化：任何能夠觸及系統資源的工具都應在沙盒中執行

Localhost 曾經是安全邊界。但隨著 AI 代理開始瀏覽開放的網際網路，它已成為一個全新的攻擊面。