OpenClaw 安全最佳实践:来自 28K 木马事件的教训

2026年4月29日2 分钟阅读

Share with

28K 事件实际暴露了什么

四月份在 OpenClaw 社区流传的「28K」数字,是一个恶意包在被发现之前所感染的系统数量。这个木马通过一款流行的 OpenClaw 扩展进入,收集所有它能拿到的 API 密钥,并悄悄把自己嵌进当周后续运行的 Agent 提示词里。

它能进来,不是因为 OpenClaw「不安全」,而是因为大多数 OpenClaw 部署的配置方式跟大多数开发者工具一样:密钥放在环境变量里,Agent 跑在开发者的笔记本上,扩展靠信任安装,「Agent 做了某件事」和「账单到了」之间没有任何审计日志。每一个默认值单独看都没问题。叠加起来,正好构成了这个木马所针对的威胁模型。

这篇文章不是功能宣传文。Office Claws 不是 OpenClaw 运行时——我们是一个 Codex-first 的桌面管理器,下文的大部分控制项对两种 Agent 同样适用。我们想要展开的是 OpenClaw 用户在这次事件之后真正面对的威胁模型,以及那些让下次事件变成无关紧要小事的、平淡的本地优先实践。

OpenClaw 木马的影响半径:扩展 → 密钥 → Agent 提示词 → API 花费

OpenClaw 用户真正面对的威胁模型

有三件事让 Agent 平台比普通的开发者工具更值得攻击,OpenClaw 不例外。

密钥就是真金白银。 一把泄露的 OpenAI 或 Anthropic 密钥不只是凭据,它是一台计费计量的 ATM。攻击者可以在账单告警触发之前,用一个周末在一把密钥上烧掉 5,000 美元。
Agent 是有「手」的。 一个有 shell 权限的 Agent 可以读取你的代码库、向你的仓库 push、以你的身份执行脚本。藏在 Agent 提示词或工具列表里的木马可以做同样的事。
供应链很宽。 每一个扩展、MCP server 或「社区包」都跑在和 Agent 同一个信任域里。一套装了十二个扩展的 OpenClaw,就有十二个潜在入口。

任何不解决这三点之一的实践,都是装饰。

风险	糟糕的默认值	真正起作用的、平淡的控制项
密钥外泄	密钥放在源码旁的 `.env`	本地 OS keychain,短周期轮换
Agent 在笔记本上拥有完整权限	一个 uid,一个文件系统	Agent 跑在自己的 VPS 上,使用受限作用域的 token
扩展供应链	自动更新,无审查	锁版本、读 diff、不自动安装
看不见的花销	API 账单月底才到	每个 Agent 的花销上限 + 每日监控

五个真正能动针的控制项

1. 密钥留在操作者的机器上

这次事件之后杠杆最大的控制项,也是最古老的:不要把秘密送到运行不可信代码的地方。在 Office Claws 里,你的厂商密钥存在桌面应用本地存储中。只有当 Agent 调用厂商时,密钥才会通过加密的 Tailscale 隧道传给 Agent,从不会写到 VPS 磁盘上。如果有木马落到 Agent 那台机器,它找不到密钥——因为密钥从未到过那里。

如果你继续留在 OpenClaw,等价的做法是把密钥从项目 .env 里挪到 OS 自带的钥匙串中(macOS 的 Keychain、Linux 的 secret-tool、Windows 的 DPAPI),并在会话开始时读取。麻烦,是麻烦。但这就是「被攻陷」和「有点尴尬」之间的差别。

2. Agent 住在别处

让 Agent 跑在和你的源码树同一台机器上,意味着任何一次入侵都能波及全部。让它跑在 VPS 上——你自己每月几欧的 Contabo 实例——大多数攻击就变成了「攻击者 root 了一台短命 droplet」。这台 droplet 没有你其他仓库的 SSH key,没有你银行的浏览器会话,也连不上你团队的 Slack。销毁、重建;影响半径就是一台机器。

这就是我们交付的模式。Self-hosted 版的 Office Claws 用预制快照在三分钟内完成 Contabo droplet 的开通;Agent 跑在那边,你的笔记本通过 Tailscale 跟它对话。

Agent 在自己的 VPS 上,密钥留在操作者的机器上

3. 给每个安装的扩展锁版本

28K 木马是一次供应链攻击。对社区扩展开自动更新,就是 OpenClaw 版的 curl | bash。锁版本。升版本前先读 diff。任何要求「所有工具、所有目录」的扩展,都用对待要求「读取所有页面」的浏览器扩展那种态度去对待——长长地停一下,找一个更小的替代品。

两条实用规则:

一个扩展需要往你从没听说过的域名出网,直接 No。
一个扩展的维护者 GitHub 履历只有三个 commit,直接 No。

4. 在厂商侧设置花销上限

每一家受支持的厂商都允许给单个密钥设置花销上限。设置一个。28K 木马之所以有利可图,是因为账单到之前没人察觉;同样的木马打到一个设了 50 美元/日上限的密钥上,只是个小麻烦,不是事故。Office Claws 在桌面应用里展示每个 Agent 的 token 消耗,但权威的防线是你在 OpenAI 或 Anthropic 那边设置的上限。我们没法替你设,也不想替你设。

如果你对「Agent 做了什么」的唯一记录是 Agent 自己的 scrollback,那你就没有记录。每一条 Agent 提示词和每一次工具调用都应该落到你能控制的地方:Agent VPS 上的 gateway 日志、你自己运维的 Loki/Grafana 栈,或者——在 managed 计划里——桌面应用的活动 Feed。目的不是天天读它,而是事故之后能在几分钟内回答「这把密钥碰过什么」,而不是几周。

在实践中长什么样

具体地说,一位认真对待这次事件的 OpenClaw 用户,从四月走出来时大概有这样一套栈:

laptop  ── Tailscale ──► VPS (one per agent)
  │                       │
  │                       ├─ agent runtime
  │                       ├─ pinned extensions
  │                       └─ gateway log → operator-side
  │
  ├─ keys in OS keychain (NOT in .env)
  ├─ provider spend cap set per key
  └─ desktop app showing per-agent token burn

这就是 Office Claws 默认为 Codex Agent 交付的同一套栈。如果你在订阅被封后从 OpenClaw 迁出来,你顺带也把这份安全姿态作为成本迁移的副产品收下了。如果你留在了 OpenClaw,上面的架构依然可达——只是要你自己去布线。

建议

今天就把密钥从 .env 里挪走。 即使你只做这一件事,下一个被植入的扩展也无法外泄它读不到的密钥。
下次写代码之前先设花销上限。 厂商面板里五分钟。本页 ROI 最高的控制项。
审计你已安装的扩展。 不在用的全卸了。在用的,锁到一个已知良好的 commit 上。
把 Agent 从笔记本上迁走。 不管是 self-hosted 上的 OpenClaw 还是 Office Claws 上的 Codex,笔记本都不是长期运行、有 shell 权限的 Agent 该待的地方。
保留一份操作者侧的日志。 不必花哨,但要在下一次事件之前就存在,而不是事后再补。

28K 不是最后一次。Agent 平台现在已经赚钱到让「供应链 → 密钥 → 账单」成为一种商业模式,而不是巧合。上面这些控制项不会阻止它。它们只是把影响半径压到足够小,让下一次事件是周五下午的一张工单,而不是一整个周末的战情室。