事件背景：漏洞不在 Android，而在控制層
已證實事實：CVE-2026-73296 影響 Microsoft 開源自動化框架 UFO 的 Mobile MCP 元件，CVSS 3.1 評分為 9.4、屬重大等級。漏洞核心不是破解 Android 作業系統，而是 UFO 在 Android Debug Bridge（ADB）前方架設的兩個 Streamable HTTP MCP 服務沒有驗證身分：資料蒐集服務使用 TCP 8020，動作服務使用 TCP 8021。CVE 彙整頁可見於 https://cvefeed.io/vuln/detail/CVE-2026-73296。
Microsoft UFO 的 GitHub 安全公告進一步確認：當操作人員依遠端部署方式，把服務綁定到 0.0.0.0，任何能連到這兩個服務的網路用戶端，都可在沒有 API 金鑰、UFO 工作階段、使用者核准或模型配合的情況下初始化 MCP 並呼叫工具。受影響版本欄位列為 3.0.7（含）以前。第一方公告：https://github.com/microsoft/UFO/security/advisories/GHSA-24fq-m9rr-g3mm。
運作機制：MCP 把 ADB 能力變成網路 API
已證實事實：8020 服務可取得螢幕截圖、UI 樹、裝置資料、已安裝應用程式與視窗控制項；8021 則可執行點按、滑動、輸入文字、按鍵事件、啟動 App 與點擊指定控制項。安全公告展示的資料流很直接：MCP 的 tap 呼叫會抵達 ADB 的 shell input tap，截圖功能則執行 adb shell screencap、取回 PNG，再以 Base64 回傳。Google 的 ADB 文件也證實 ADB 能執行 shell 指令與擷取畫面：https://developer.android.com/tools/adb。
合理推論：這不是傳統意義上先突破手機防護、再提升權限的攻擊；攻擊者是在重用管理者原本授予自動化系統的能力。MCP 負責把能力標準化，ADB 負責真正操作裝置，而缺失的驗證讓「已授權自動化」變成「任何可達者皆可使用」。因此，風險大小不只取決於程式漏洞，也取決於服務監聽介面、防火牆、網路分段與 ADB 所連裝置的狀態。
為何現在值得注意
作者觀點：此案的重要性高於單一套件漏洞，因為它揭露代理型系統常見的設計盲點：開發者把 MCP 當成方便的內部工具插座，卻可能忘記 Streamable HTTP 已經是一個可跨主機存取的網路邊界。MCP 傳輸規格明確建議，本機服務只綁定 localhost，並為所有連線實作適當驗證；官方規格同時提醒應檢查 Origin，以降低 DNS rebinding 風險：https://modelcontextprotocol.io/specification/2025-11-25/basic/transports。
換言之，問題不在「AI 自己失控」。本案甚至不需要提示注入、惡意模型或代理推理，只要攻擊者能送出合規的 MCP 請求即可。這使偵測與治理焦點必須從模型輸出，往下移到工具端點、傳輸驗證及工具權限。
實際影響與容易忽略的限制
螢幕截圖與 UI 樹可能揭露訊息、個資、App 內容或畫面上的一次性密碼；輸入與點擊能力則可能改變裝置狀態、干擾測試，或在已解鎖且可存取的 App 中代替使用者操作。不過，這些是安全公告列出的可能後果，不代表每次利用都能繞過鎖定畫面、App 登入或 Android 權限模型。
限制條件同樣重要：攻擊面成立至少需要 Mobile MCP 服務正在執行、攻擊者能連到相應連接埠，而且伺服器的 ADB 已連接實體 Android 裝置或模擬器。預設 CLI 主機是 localhost，因此未修改的純本機部署可降低遠端暴露。這不是所有 Android 手機普遍可被網際網路接管，也沒有證據顯示漏洞已遭大規模利用。
修補資訊存在落差
CVE 彙整頁稱問題已在 3.0.8 修正；然而查證當下，GitHub 安全公告的「Patched versions」仍顯示 None。GitHub 確實存在一筆專門修補此漏洞的 commit，加入來自 UFO_MCP_API_KEY 的 Bearer 憑證、在缺少金鑰時拒絕啟動，並要求用戶端帶入相同憑證：https://github.com/microsoft/UFO/commit/e562d10060b077dedae93e0fd58c1ee379558962。
3.0.8 版本頁也已存在，但公開變更摘要沒有明列這筆 Mobile MCP 修補：https://github.com/microsoft/UFO/releases/tag/v3.0.8。因此，穩健做法不是只看版本字串，而是確認實際安裝來源包含上述修補，並等待維護者把公告、標籤與套件資訊對齊。
台灣團隊應立即處理什麼
- 盤點測試實驗室、行動 App CI、裝置農場與遠端自動化主機，確認是否執行 UFO Mobile MCP。
- 檢查 TCP 8020、8021 是否對區網、VPN、雲端安全群組或公網開放；非必要立即停止服務或改綁 localhost。
- 確認部署包含修補 commit，設定高熵
UFO_MCP_API_KEY，並讓未帶或帶錯憑證的請求在工具執行前遭拒。 - Bearer 驗證不等於加密。遠端部署仍應使用 TLS、受驗證的反向代理或可信私有通道，再以防火牆限制來源。
- 若懷疑曾暴露，先隔離主機、停止 MCP、斷開 ADB 裝置，再檢查連線紀錄、程序紀錄與裝置上的異常操作。
後續觀察指標
接下來應追蹤三件事：GitHub 公告是否正式列出已修補版本；3.0.8 發行成品是否可驗證包含 e562d10 修補；以及是否出現公開利用程式、掃描活動或已知遭利用紀錄。更長期的指標則是組織能否把 MCP 端點納入 API 資產盤點，並區分「讀取畫面」與「改變裝置」兩類權限。這起事件真正留下的警訊是：當代理工具能看、能點、能輸入時，它就不再只是開發介面，而是需要零信任邊界的遠端控制平面。