2026 年 1 月某個週二早晨，一位安全研究員在 GitHub 上發布了一個概念驗證漏洞利用程式。標題低調得很：「OpenClaw WebSocket Origin Bypass」。但影響可不低調。
這個漏洞利用的精妙之處在於它的簡單性。攻擊者可以製作一個包含幾行 JavaScript 的惡意網頁。當 OpenClaw 使用者造訪那個頁面——點擊電子郵件、Slack 訊息或任何地方的連結——JavaScript 就會悄悄連接到他們本機上執行的 OpenClaw 實例並執行任意指令。不需要驗證，除了點擊連結之外不需要任何使用者互動，就能完全存取機器。
CVE-2026-25253 在 CVSS 量表上評分 8.8。安全社群稱之為嚴重漏洞。OpenClaw 團隊最初稱之為「WebSocket 架構的已知限制」。這兩種描述之間的落差，說明了這場危機是如何演變的。
事件時間軸
第一個 CVE 在 1 月 14 日發布。48 小時內，Shodan 掃描發現超過 42,000 個 OpenClaw 實例公開暴露在網路上——任何知道 URL 的人都可以利用這些實例。其中許多是企業部署，可以存取內部檔案系統、資料庫以及儲存在環境變數中的憑證。
在第一個修補程式發布之前，CVE-2026-26327 就出現了：一個讓攻擊者完全跳過登入的驗證繞過漏洞。同一週內出現兩個嚴重漏洞，都可以遠端利用，都影響同樣超過 42,000 個暴露的實例。
然後是 ClawHub 的問題。安全研究員開始稽核 OpenClaw 官方技能市集，發現 41.7% 的已發布技能存在漏洞——有些是意外的，有些是故意植入的。數百個惡意技能在過去幾個月裡悄悄上傳，等待使用者安裝。XDA Developers 發表了一篇標題為「請停止使用 OpenClaw」的文章，迅速爆紅。
為什麼這不只是運氣不好
把 OpenClaw 危機當成一連串不幸的 bug 來看待會讓人感到安慰——那種任何專案都可能發生的事，打個補丁就能繼續前進。但這種框架忽略了更深層的問題。這些漏洞不是隨機的，它們是多年前做出的特定架構決策的可預見後果，當時 OpenClaw 還是個週末專案，安全性不是主要考量。
WebSocket 信任模型是第一個問題。OpenClaw 的 Web 介面在不驗證 Origin 標頭的情況下接受 WebSocket 連線。這是一個有充分文件記載的漏洞類別——跨站 WebSocket 劫持——自 2012 年以來就廣為人知。修復方法很簡單：檢查 Origin 標頭。但在 OpenClaw 中修復它會破壞圍繞著這個寬鬆模型建立起來的外掛生態系統，所以一再被推遲，直到它變成了 CVE-2026-25253。
第二個問題是作業系統層級的權限。當你安裝 OpenClaw 技能時，它以與 OpenClaw 程序本身相同的權限執行。在大多數系統上，這意味著它可以讀取你的檔案、存取你的網路、執行指令，以及讀取包含 API 金鑰和密碼的環境變數。沒有沙箱，沒有能力模型，沒有辦法只授予技能它所需要的存取權限。你安裝的每個技能都隱含地被信任可以存取一切。
第三個問題是 JavaScript 供應鏈。OpenClaw 的 node_modules 包含 1,200 多個套件。ClawHub 上的惡意技能利用了這一點，發布名稱與熱門套件相似的套件——拼字搶注——然後等待它們作為相依性被引入。在一個有大型相依性樹的動態語言中，這種攻擊在平台層級幾乎不可能防止。
真正的安全設計是什麼樣子
ZeroClaw 是基於一套不同的假設建立的。不是「我們之後再加安全性」，而是「安全限制從第一天起就塑造架構」。
Rust 的所有權系統在編譯時消除了整個漏洞類別。緩衝區溢位、釋放後使用、資料競爭——這些在 Rust 程式碼中不是需要修補的 bug，而是編譯錯誤。CVE-2026-25253 在 OpenClaw 中之所以可能發生，部分原因是 JavaScript 的動態特性使得在語言層級強制執行安全邊界變得困難。在 Rust 中，這些邊界在程式碼執行之前就由編譯器強制執行。
閘道配對取代了遠端存取的密碼驗證。ZeroClaw 不是暴露一個連接埠然後希望使用者設定強密碼，而是要求客戶端和閘道之間進行加密配對——類似於藍牙配對的工作方式。在網路上找到你的 ZeroClaw 實例的攻擊者，沒有配對金鑰什麼也做不了。
預設拒絕的允許清單模型意味著每個工具、檔案路徑和網路端點都必須在代理可以存取之前明確許可。試圖讀取其指定工作區之外檔案的技能會得到權限錯誤，而不是存取權限。試圖向未列出端點發出網路請求的技能會被封鎖。預設是無存取權限；你授予你所需要的確切權限。
帶有符號連結逃逸偵測的工作區範圍界定可防止路徑遍歷攻擊。即使惡意技能試圖通過跟隨符號連結來逃脫其沙箱，ZeroClaw 也會在任何資料被存取之前偵測並封鎖這種嘗試。
而單一二進位架構完全消除了供應鏈攻擊面。沒有 node_modules，沒有套件登錄檔，沒有需要稽核的傳遞相依性。讓數百個惡意 ClawHub 技能成為可能的攻擊向量根本不存在。
如何切換
如果你目前正在執行 OpenClaw，遷移路徑很簡單。首先備份你的 OpenClaw 資料——對話歷史和設定存放在 `~/.openclaw/`，在碰任何東西之前你需要一份副本。
用一個指令安裝 ZeroClaw：
```bash curl -fsSL https://raw.githubusercontent.com/zeroclaw-labs/zeroclaw/main/scripts/bootstrap.sh | bash ```
先以乾跑模式執行遷移工具來預覽將會發生什麼變化：
```bash zeroclaw migrate openclaw --dry-run ```
這會精確地告訴你什麼將被匯入、什麼將被跳過，以及什麼需要手動處理。當你對預覽感到滿意時，執行實際的遷移：
```bash zeroclaw migrate openclaw ```
這會帶走你的記憶、設定和頻道設定。確認你的頻道重新連線，並用一個簡單的查詢進行測試。整個過程通常不到十分鐘。
業界應該從中學到什麼
OpenClaw 危機不是一個專案安全失敗的故事。它是一個關於當基礎設施軟體以腳本工具的假設建立時會發生什麼的故事。
AI 代理處理憑證、存取檔案系統、執行程式碼，並且全天候執行。它們是基礎設施，不是腳本。它們需要與 Web 伺服器相同的安全嚴謹性、與資料庫相同的架構紀律，以及與任何其他以提升權限在你的機器上執行的東西相同的威脅建模。
安全性無法被改裝到一個寬鬆的架構上。它必須從一開始就被設計進去——在語言選擇、權限模型、部署架構和外掛系統中。當它沒有被設計進去時，你就會得到 42,000 個暴露的實例和一個評分 8.8 的 CVE。
問題不是你的 AI 代理是否會成為攻擊目標。而是你的架構是否在那種情況發生時能夠承受得住。