論文發布於 AIA: 2026年4月18日

ClawJacked：惡意網站如何接管你電腦上的小龍蝦

Oasis Security 指出，任何網站都能直接對 OpenClaw 的本機閘道服務開 WebSocket 連線；這個閘道服務其實就是跑在自己電腦上的管理入口。攻擊者可以冒用命令列介面（CLI）客戶端的身分繞過來源檢查，再利用 loopback 位址（也就是連回自己這台電腦的本機位址）不受速率限制的密碼驗證一路暴力猜密碼；修補已經釋出，但真正的教訓是，不能再把 localhost 這種本機來源訊號當成可信身分依據，agent 的工作階段和每一個 RPC 方法（可直接呼叫後端功能的管理操作）都得當成特權控制面，分開驗證、分級授權。

Agentic AIWebSocket SecurityLocalhost TrustIdentity & Access

7 項對應的 AIDEFEND 防禦手法

來源: Technical Analysis of Cross-Origin WebSocket Exploitation in OpenClaw

作者 Elad Luz · 原文發布: 2026年2月26日

威脅分析

這不是單一漏洞，而是三個錯誤的信任假設疊在一起。 來源檢查只套用在特定客戶端 ID（系統用來辨識連線身分的名稱）；凡是從 localhost 進來的新裝置，又會被系統直接自動配對；連來自 loopback 位址的密碼猜測，都不記次數、不限速，也不寫進日誌。
真正的遠端對手不是本機程式，而是瀏覽器裡的那個網頁。 在 Chrome、Edge 和大多數 Firefox 設定裡，公開 HTTPS 網頁都能對 ws://127.0.0.1:18789/ws 開連線。只看 TCP 來源、不看是哪個網頁發起連線，等於把公網頁面的程式碼誤認成可信的本機工具。
一旦登入成功，對方拿到的不是單一功能，而是整個控制面。 白皮書列出的可呼叫方法涵蓋 chat 劫持、設定改寫、節點指令派送、agent 檔案寫入、排程工作建立，以及日誌讀取。換句話說，攻擊者不是只能偷看，而是能直接改設定、下指令、留下持久化痕跡；這裡說的控制面，就是能管理這個 agent 的那一層核心介面。
使用者自己設的密碼，在這條攻擊鏈裡幾乎不算防線。 Oasis 實測瀏覽器 JavaScript 每秒可嘗試 300 次以上；只要 loopback 驗證沒有套進速率限制，再常見一點的密碼很快就會被猜中。
這類本機 agent 閘道服務，本質上就是管理 API。 裝置配對、工作階段建立、還有高風險 RPC 方法，都要用保護對外控制面的標準來硬化，不能只把它當成桌面工具背後的本機元件。

適用的 7 項 AIDEFEND 防禦手法

AID-M-009.003

Agent Identity, Delegation Lineage & Runtime Authorization

極高

不要再把「宣稱自己是某種客戶端，再加上來源位址看起來是 loopback」當成授權依據。閘道服務的工作階段應該綁在可驗證的客戶端身分，外加短生命週期的工作階段憑證；由瀏覽器開出的 WebSocket 連線，不能只因為來自 127.0.0.1 就直接拿到 CLI 或節點程式等級的權限。

AID-H-019.004

Intent-Based Dynamic Capability Scoping

極高

新的工作階段一開始只該拿到完成當前任務所需的最小 RPC 集合。這裡的 RPC 集合，可以把它理解成「這個工作階段到底能直接叫後端做哪些事」；像 config.patch、node.invoke、skills.install、agents.files.set、cron.add 這些方法，不該預設就開給它，除非另有受信任的流程明確授權。

AID-I-008.002

Cross-Origin Read/Write Segmentation with Step-Up Confirmation

極高

把「瀏覽器連到 localhost」和「公開網頁試圖對 loopback 服務做寫入」都視為敏感邊界。來自公網頁面的內容，不該在沒有額外核准的情況下，直接對本機 agent 閘道服務開管理用 WebSocket、完成裝置配對，或觸發任何狀態變更。

AID-M-009.002

Authority Envelope & Action Risk Classification

高

把裝置配對、設定改寫、節點指令執行、建立持久排程、還有跨裝置資料讀取，都歸類成高風險控制面動作。這些動作不該跟一般 chat 或唯讀狀態查詢走同一條授權路徑。

AID-D-005.002

Security Monitoring & Alerting for AI

中

針對 loopback 驗證爆量失敗、新裝置配對、客戶端 ID 與頁面來源不相符，以及第一次出現 node.invoke、config.patch、cron.add 這類高風險 RPC 呼叫發出警示通知。這裡的 RPC 呼叫，指的是直接要求後端執行某個管理動作；白皮書已經說明，localhost 上的猜密碼行為甚至沒有被記錄，這類監測資料不能缺。

AID-D-015.002

High-Risk Action Confirmation Telemetry & Bypass Detection

中

裝置配對、開啟管理用 WebSocket，以及呼叫 node.invoke 這類方法，都應該留下確認證據。把配對提示、核准紀錄、工作階段身分和實際執行事件串起來，才能偵測沒有經過預期使用者額外核准的靜默配對或 RPC 呼叫。

AID-I-004.006

Agent Identity & Persistent State File Write Protection

中

就算工作階段已經被拿下，也不能讓它自然延伸成持久後門。要對 agent 的身分檔、記憶／狀態檔，以及排程相關設定加上寫入保護，避免攻擊者把 agents.files.* 或自動化端點變成能長期存活的後門機制。

身為資安防禦者，我們應該這麼做

先盤點端點上是否有 OpenClaw 或類似的本機 agent 閘道服務，特別是監聽 18789 連接埠的實例；全部升到 2026.2.25 版或之後。
如果還在用密碼驗證，優先改成隨機產生、長度夠長、難以猜中的 token；同時清掉不再需要的配對裝置，並輪替裝置 token。
把來自瀏覽器的管理動作全部列為高風險：新裝置配對、node.invoke、設定改寫、agent 檔案寫入、skill 安裝、排程建立，都要額外核准或直接擋下。
把 loopback 驗證爆量失敗、客戶端 ID 與來源不相符、第一次裝置配對，以及高風險 RPC 呼叫，全部寫進監測和警示規則。
逐台確認每個 OpenClaw 實例到底能碰到哪些東西：AI 服務供應商的 API key、訊息平台、shell 指令、工作區檔案、日誌；沒有明確需求的權限就收掉。

1 個額外的防禦考量

瀏覽器對 localhost 暴露面的迴歸測試

除了上面對應的防禦技術，推出本機 AI 助手的團隊還應該再補一層釋出前的迴歸測試：把任意網站都當成攻擊者，持續驗證 localhost 上的 HTTP 與 WebSocket 服務會不會出現來源混淆、自動配對，或把 loopback 連線誤當成高信任來源。

建議做法: 固定跑一套測試工具，從公開 HTTPS 頁面對 Chrome、Edge、Firefox、Safari 實際發起連線，逐項驗證來源檢查、配對提示、驗證限速，以及管理方法暴露情形，再決定能不能出貨。

結論

OpenClaw 這個案例說明，只要瀏覽器還能對本機服務開 WebSocket，localhost 就不是安全邊界。防禦底線是把本機閘道服務當成特權控制面來設計：身分要能驗、工作階段要縮權、關鍵 RPC 要分級、持久狀態要保護，而且每次釋出都要拿真實瀏覽器做回歸驗證。