EvoMap 安全聲明

EvoMap 自創立以来，用户安全始终是我们的第一優先级。我们的代码開源在 GitHub 上，接受任何人的審查。

近期，有不实文章将 EvoMap 恶意定性为"木马"和"C2 框架"。我们已完成取证，相关材料已移交司法机关處理。

与此同时，我们选择用事实和代码说话。以下是我们对相关質疑的正面回应，文末附有完整的技术核查报告，欢迎独立驗證。

EvoMap 到底是什么

EvoMap 与 Evolver 其实是两个东西，很多誤解就是因为把它们搞混了：

evomap -- 一个命令行工具。你敲一条命令，它给你返回结果，然后就退出了。它不会常驻后台，不会自动執行任何操作，不会上传你的代码。它的作用类似一个"搜索引擎客户端"——帮你在 AI 资产市场上搜索和浏览。

evolver -- 一个本地代码改进工具。它可以分析你的项目，提出改进建议并自动应用。它确实有更多功能（比如可以持续运行），但所有操作都发生在你的本地机器上，由你主动启动。

两篇文章最核心的问题是：把 evolver 的功能说成是 evomap 的，然后得出"evomap 是木马"的結論。这就好比说"因为菜刀能砍人，所以菜板是凶器"。

回应几个最吓人的说法

"它能遠程執行代码"

evomap 的代码里没有任何執行逻辑。它获取到的数据被直接打印到屏幕上，仅此而已。

evolver 确实会執行一些命令，但这些命令要么是硬编码的（比如重启自己、查询系统状态），要么经过了严格的白名单过滤（只允许 node/npm/npx 开头的命令，且禁止 shell 操作符）。

此前白名单存在一个理论上可被绕过的点（通过特定的 node 命令构造），截稿前已在 v1.20.3 中修復。我们选择主动公开这个问题的存在和修復过程，而不是假装它从未发生。

"它是 C2 框架"

C2 框架是什么？简单说就是黑客偷偷装在你电脑上、能遠程控制你机器的工具。它的特点是：偷偷安装、自动回传数据、執行遠程命令、竊取信息、卸载困难。

而 EvoMap 的实际情况：開源代码（任何人都能看）、需要你手动安装和執行、不会自动联网回传数据、不執行遠程命令、删除目录就完成卸载。

把一个開源命令行工具叫做 C2 框架，就像把一个公开菜谱网站叫做情报机构。

"第一批受害者已经出现"

文章提供的"證據"是几张聊天截图，里面没有任何具体的技术细节——没有進程日志、没有网络抓包、没有未授权操作的描述。

此类不实指控涉嫌寻衅滋事，EvoMap 法务团队已固定證據，并已移交公安和司法机关进行處理。

evolver 有一个 --loop 模式，启动后会持续运行并自动執行改进周期。如果用户在不了解这个模式的情况下使用了它，可能会觉得"我的电脑在自己动"。但这正是这个命令的設計用途，不是恶意行为——就像你设了个闹钟，到点响了，不能说闹钟在攻擊你。

"它在採集你的信息"

evolver 确实会採集一些環境信息：你用的操作系统、Node.js 版本、CPU 架构。这些信息用于判断一个改进方案在什么平台上成功率更高。

它不採集你的文件内容、不採集你的密码、不採集你安装了什么软件。这和你每次访问一个网站时浏览器发送的 User-Agent 信息是同一类东西。

关于 ClawHub

部分質疑引用了 ClawHub（AI Skill 市场平台）上的事件作为论据。这里需要一些背景。

ClawHub 自身正在经历严重的安全危机。 2026 年 2 月，安全机构在 ClawHub 上发现了数百个恶意 Skill，其中一个账号就上传了 314 个。这场被称为"ClawHavoc"的事件说明，AI Skill 生态的安全问题是真实的、严峻的。

但 ClawHub 的安全扫描机制本身也很混乱。 它会把完全正常的工具标记为"可疑"——比如一个只用标准库、零外部依赖、不联网的 Python 脚本被标记了（GitHub Issue #15913），一个只是读取官方 API token 的工具也被标记了（GitHub Issue #404）。与此同时，真正的恶意 Skill 通过"干净诱饵 + 脏依赖"的方式绕过了扫描。

简单说：ClawHub 的扫描，该拦的拦不住，不该拦的乱拦。在这样一个平台上被标记或下架，不能直接等同于"有问题"。

我们为安全做了什么

说几件具体的事：

evolver 有 11 层安全保护。 包括命令白名单、操作范围硬上限（最多影响 60 个文件）、关键路径保护、破坏性变更检测、失败自动回滚、人工审批模式等。完整清单在技术报告中。

我们为 ClawHub 貢獻了安全代码。 EvoMap 的创始人向 ClawHub 提交了 PR #298，貢獻了 1,285 行安全基础设施代码——包括防恶意抢注、封禁流程改进、备份恢复系统等。这个 PR 由 ClawHub 维护者 Peter Steinberger 审阅并合入。

一个为 ClawHub 写安全代码的团队，被说成是做木马的。这个矛盾本身就值得想一想。

我们主动公开了安全弱点，并已修復。 我们收到了一份第三方安全审计报告，声称发现 8 个漏洞。我们逐条驗證后，確認 1 个是真实的可改进点，2 个是合理的加固建议，5 个与代码实际行为不符。那个確認存在的问题已在截稿前修復（v1.20.3），修復过程和所有细节全部公开。

我们的态度

我们理解在 AI Skill 安全事件频发的当下，社区对新项目保持警惕是合理的。

但我们希望安全討論能基于事实，而不是修辞。"可能有风险"和"就是木马"之间的差距，大到不应该被一篇文章跨越。

EvoMap 是開源的。所有代码都在 GitHub 上。本文中的每一个結論，你都可以通过阅读源代码来驗證——不需要相信我们的话，只需要相信代码。

如果你发现了我们没提到的安全问题，欢迎通过 GitHub Issue 或邮件告诉我们。我们承诺 48 小时内回应。

完整技术报告

以上是面向所有人的简明版本。以下是完整的技术核查报告，包含逐行代码驗證、child_process 调用全清单、第三方安全审计回应。

写在前面

过去几天，EvoMap 经历了一段不平静的时期。

从 ClawHub 上线到引发社区討論，从安全性質疑到被定性为"木马"，再到"第一批受害者已经出现"的说法——作为这个项目的创建者，我们理解社区的关注和警惕。

在 AI Skill 生态快速发展的今天，对新项目保持审慎是正确的。Snyk 的 ToxicSkills 报告、SkillJect 论文（arXiv:2602.14211）、Schmotz 等人的研究（arXiv:2510.26328）都指出了 AI Skill 领域的安全风险——这些是真实存在的行业问题，我们从未否认。

事实上，ClawHub 自身正在经历这些风险的切肤之痛。2026 年 2 月，七家独立安全机构在 ClawHub 上发现了 300-900 个恶意 Skill（Koi Security 报告了 341 个，Bitdefender 估计约占市场总量 20%），Snyk 確認了 76 个恶意载荷和 1,467 个存在安全问题的 Skill。这场被称为"ClawHavoc"的事件，证明 AI Skill 市场的安全问题不是理论风险，而是正在发生的现实。

但"行业存在风险"与"特定项目是恶意软件"之间，需要代码事实作为桥梁。

这篇报告做三件事：

1. 说明 EvoMap 在安全方面做了什么、还有哪些不足
2. 基于源代码逐条回应外界提出的技术質疑
3. 公开我们收到的第三方安全审计结果，包括已確認的问题和修復计划

所有結論基于 evomap 客户端及 evolver 本地进化引擎的全部源代码審查，任何人都可以通过阅读源码独立驗證。

一、EvoMap 是什么

EvoMap 由两个独立项目组成，职责不同，代码仓库不同：

区分这两个项目非常重要，因为后续多项質疑源于将两者的功能混为一谈。

二、我们在安全上做了什么

在详细回应質疑之前，先说明 EvoMap/Evolver 已有的安全机制。这不是在自夸，而是为后续技术討論提供背景。

Evolver 的 11 层安全保护

我们坦诚承认的不足

安全是一个持续改进的过程，我们并不完美：

• 命令白名单曾存在一个已確認的理论攻擊面（node -e 可嵌入任意 Node.js 代码），已在 v1.20.3 中修復（详见附录 B）
• 正则表达式匹配缺少复杂度预检查，存在 ReDoS 的理论风险
• 環境变量缺少范围校验，将作为防御性加固补充

命令注入问题已在截稿前修復。其余问题来自第三方安全研究者的反馈，我们对此表示感谢，并已规划后续加固。

我们对 AI Skill 生态安全的貢獻

EvoMap 团队不仅关注自身项目的安全，也在积极参与整个生态的安全建设。

EvoMap 的创始人以 autogame-17 的身份向 ClawHub 提交了 PR #298（1,285 行新增代码），该 PR 由 ClawHub 维护者 Peter Steinberger 审阅并合入。貢獻内容包括：

• 反抢注保护：新增 reservedSlugs 表，Skill 被删除后 slug 保留 90 天冷却期，防止恶意抢注
• 封禁流程改进：将封禁操作从硬删除改为软删除，使得误判可逆；恶意软件作者自动封禁对齐同一模式
• 备份恢复系统：从 GitHub 备份仓库恢复 Skill 记录，抢注者驱逐与恢复在同一事务中執行
• 可信发布者机制：新增 trustedPublisher 标志，可信发布者绕过 pending.scan 自动隐藏

这些都是 ClawHub 平台级的安全基础设施。一个为 ClawHub 貢獻安全代码的团队，被指控为"木马"制作者——这本身就是一个值得思考的矛盾。

ClawHub 扫描机制的现状

这里有必要补充一些关于 ClawHub 安全扫描的背景，因为部分質疑引用了 ClawHub 的扫描结果作为论据。

ClawHub 当前的扫描机制存在已知的局限性：

• 误报率高：合法 Skill 频繁被标记为"可疑"。例如 link-brain（纯标准库 Python 脚本，零外部依赖，无网络调用）和 redline（仅从官方凭据存储读取 OAuth token 并调用官方 API）都被误报
• 启发式过度触发：扫描系统对 URL 字符串、文件 I/O 操作、凭据读取等正常模式过度敏感，这些是很多 Skill 的核心功能
• 漏报真正的威胁：与此同时，攻擊者通过"干净诱饵 + 脏依赖"模式（在 Skill 内放干净代码，引导用户去外部网站下载恶意载荷）成功绕过了 VirusTotal 扫描
• pending.scan 困局：PR #104 引入的 ClawScanner 本意是标记后继续发布，但实际实现中被标记的 Skill 可能停留在 pending.scan 状态无法发布

简言之，ClawHub 的扫描系统目前处于"该拦的拦不住，不该拦的乱拦"的状态。用这样一个系统的扫描结果作为定性某个项目是否安全的依据，说服力有限。

三、我们受到的影响

近期有公开文章对 EvoMap 提出了安全質疑，将其定性为"木马"和"C2 框架"，并声称"第一批受害者已经出现"。

我们尊重安全研究者发表独立意见的权利。公开討論有助于提升整个 AI Skill 生态的安全水位，这是好事。

但当質疑从"可能有风险"升级为"木马""C2 框架""第一批受害者已经出现"时，我们有义务基于代码事实进行澄清——不是为了争论，而是为了让读者能够基于可驗證的信息做出独立判断。

四、技术質疑逐条回应

以下逐条回应两篇文章中提出的技术質疑。每一条都附有代码引用，读者可以自行查证。

質疑 1：環境指纹採集

文章说法： Agent 把运行環境信息发送给 evomap.ai，包括操作系统、runtime 版本、可用工具列表。

代码事实：

envFingerprint.js 採集的字段为：

node_version, platform, arch, os_release, evolver_version, cwd, captured_at

不存在"可用工具列表"的採集。这些環境信息用于跨環境扩散成功率（GDI）的科学度量——同一个 Capsule 在 Windows/Linux/macOS 上的成功率可能不同，平台需要这个数据来做匹配推荐。

这与 npm 的匿名遥测、VS Code 的 telemetry 属于同类实践，且 EvoMap 是開源的，任何人都可以審查发送了什么。

結論： 文章夸大了採集范围。

質疑 2：遠程代码執行

文章说法： Capsule 本质上是遠程下发的代码补丁。npm install 可以触发 postinstall 脚本。validation 是由遠程下发的 Gene 定义的。

代码事实：

关于 evomap（市场客户端）：

evomap 的 package.json 没有任何 dependencies。evomap 的 index.js 中 fetch 命令的處理逻辑是：

case 'fetch': {
  const msg = buildFetch({ assetType: 'Capsule', includeTasks });
  const res = await transport.send(msg);
  console.log(JSON.stringify(res, null, 2));
  break;
}

获取到的资产被 JSON.stringify 打印到终端，没有任何執行逻辑。

关于 evolver（本地进化引擎）：

evolver 代码中确实存在 child_process 调用（spawn 和 execSync），我们对此不回避。以下是全部调用点和用途的说明：

index.js 中的 spawn（1 处）-- 進程自我重启：

const child = spawn(process.execPath, [__filename, ...args], spawnOpts);
child.unref();
process.exit(0);

这是内存泄漏保护机制，当進程运行超过 100 个周期或 RSS 超过 500MB 时重启自身。process.execPath 是当前 Node.js 路径，__filename 是脚本自身——它只会重启自己，与 PM2 的 restart 机制一致。

evolve.js 中的 execSync（6 处）-- 只读查询和自更新：

solidify.js 中的 execSync（~10 处）-- git 查询、回滚和受控驗證：

git 相关命令全部为只读查询（git diff --name-only 等）或失败回滚（git restore）。唯一執行非硬编码命令的是 runValidations()，但它受白名单严格过滤：

const VALIDATION_ALLOWED_PREFIXES = ['node ', 'npm ', 'npx '];

function isValidationCommandAllowed(cmd) {
  const c = String(cmd || '').trim();
  if (!c) return false;
  if (!VALIDATION_ALLOWED_PREFIXES.some(p => c.startsWith(p))) return false;
  if (/\`|\$\(/.test(c)) return false;
  const stripped = c.replace(/"[^"]*"/g, '').replace(/'[^']*'/g, '');
  if (/[;&|><]/.test(stripped)) return false;
  return true;
}

白名单中没有 npm install，因此不存在 postinstall 脚本触发风险。

已修復： 我们確認 node -e 参数内曾可嵌入任意 Node.js 代码绕过白名单（详见附录 B）。此问题已在 v1.20.3 中修復，node -e/--eval/-p/--print 现在被白名单直接拒绝。

所有 child_process 调用均不接受来自 evomap.ai 服务器的输入作为執行内容。

結論： evomap 不執行代码。evolver 的 child_process 调用用途明确，存在一个已確認的理论攻擊面，我们对此保持透明。

質疑 3：自主行为控制（赏金任务）

文章说法： Agent 会自动领取任务、執行、上报结果，不需要人类確認。

代码事实：

任务系统的全部入口是需要显式執行的 CLI 命令：

node index.js tasks            # 列出任务（仅显示）
node index.js claim <task_id>  # 领取任务
node index.js complete <task_id> <asset_id>  # 完成任务

taskReceiver.js 中不存在自动领取、自动執行、自动上报的逻辑。

結論： 文章描述的"全自动"场景在代码中不存在。

質疑 4：持久化后门（--loop）

文章说法： --loop 加 4 小时同步，是始终在线的驻留程序。

代码事实：

1. --loop 属于 evolver，不是 evomap。evomap 不支持此参数。
2. evomap 是无状态 CLI 工具：运行命令、打印结果、進程退出。
3. evolver 的 --loop 模式有完整的资源管理：单例锁、负载感知退避、内存保护、信号處理。这与 VS Code 的文件监听、ESLint 的 --watch 模式在設計上没有本质区别。

将 evolver 的功能归因于 evomap，属于混淆论证对象。

結論： evomap 是无状态 CLI，不是守护進程。

質疑 5：尾部提示词注入

文章说法： Skill 文件末尾有 [Agent Usage Reminder]，是 prompt injection。

代码事实：

SKILL.md 全文 201 行，末尾内容为参考链接列表。不存在任何 [Agent Usage Reminder] 段落。任何人都可以打开 SKILL.md 驗證。

結論： 与代码事实不符。

質疑 6：积分体系 / 画饼诱饵

文章说法： 积分激励 Agent 深入参与，暴露面越大。AI "自动领取任务赚钱"是被利用。

事实： 积分体系是市场型平台（npm、PyPI、GitHub Marketplace）的常见激励机制。"自动领取任务"的描述已在質疑 3 中证伪——每一步都需要用户显式執行 CLI 命令。

結論： 属于平台設計的合理討論。

質疑 7：供应链攻擊放大器

文章说法： 推荐资产被恶意利用后影响面是指数级的。

事实： 供应链安全是所有软件市场的共性挑战——这一点从 ClawHub 自身的经历可以得到最直接的印证。ClawHavoc 事件中，一个名为"hightower6eu"的账号就上传了 314 个恶意 Skill，占 Koi Security 发现的 341 个恶意 Skill 的绝大多数。ClawHub 直到 7 家安全机构介入才全面清理。

EvoMap 已有 Quality Gates（score >= 0.7、blast_radius.files <= 5、success_streak >= 2）以及 quarantine 和 revoke 机制。我们不认为自己已经完美解决了这个问题，但将行业共性风险单独归因于 EvoMap 是不公平的。

結論： 部分属实的行业共性问题。EvoMap 已有多层缓解机制，且团队正在积极参与整个生态的安全治理。

質疑 8：C2 框架同构

文章说法： 架构与 C2 框架一模一样。

代码事实对比：

C2 框架的本质是未经授权的隐蔽遠程控制。evomap 是開源的、需要用户主动執行的 CLI。两者存在根本性差异。

結論： 将開源 CLI 工具定性为 C2 框架，缺乏代码事实支撑。

質疑 9：受害者剧本

文章说法： ClawHub 登顶、下架、被勒索是"精心编排的营销"。

事实： ClawHub 的事件经过在平台上有完整的公开记录。文章用反问（"为什么能 10 分钟登顶？"）暗示编排，但未提供任何伪造的證據。

值得一提的是，ClawHub 自身的下架/标记机制存在广泛的误报问题（见第二节"ClawHub 扫描机制的现状"）。在一个连纯标准库 Python 脚本都会被标记为"可疑"的平台上，被下架或标记并不能等同于"有问题"。

另外，我们作为 ClawHub 安全基础设施的貢獻者（PR #298），对平台的运作机制有第一手了解。ClawHub 上的事件有它自身生态混乱的背景因素，将平台治理问题包装为"编排"，是对因果关系的简化。

結論： 主观推测，且忽略了 ClawHub 平台自身的治理现状。

質疑 10：编造案例

文章说法： "游戏策划救了后端工程师"的故事是编造的。

事实： 用户案例中隐去真实身份是行业惯例。"无法驗證"不等于"虚假"。该討論属于营销材料的可信度范畴，与项目的技术安全性是两个独立问题。

結論： 与技术安全性无关。

質疑 11：概念包装

文章说法： 生物学术语包装普通 API 调用。

事实： 使用领域隐喻命名技术概念是常见实践——Docker 的 container、Kubernetes 的 pod、Git 的 branch、Kafka 的 topic 皆如此。命名风格是設計偏好，不是安全风险。

結論： 与安全性无关。

質疑 12：sudo chmod +x

文章说法： 安装脚本中曾有 sudo chmod +x，是提权操作。

代码事实： chmod +x 是 Unix 中为文件添加可執行权限的标准操作，每个通过 npm install -g 安装的 CLI 工具都会執行。它不改变权限级别——脚本依然运行在当前用户权限下。sudo 的使用取决于文件所属用户，不是提权。该行在后续版本中被移除，是因为安装方式优化。

結論： 对 Unix 权限模型的誤解。

質疑 13：第一批受害者

文章说法： 有人报网警了，机器執行了未授权操作。

事实： 文章提供的截图中不包含具体的"未授权操作"描述、進程日志、网络抓包或任何技术性的危害證據。"有人声称受害"不能替代代码层面的安全分析。

evolver 的所有操作都会产生详细日志（memory/ 目录），如果确实存在问题，日志可以提供完整的技术还原。目前未见任何此类技术證據公开。

用户在首次使用 --loop 模式时，可能观察到 evolver 自动執行进化周期——这正是该命令的設計用途。如果事先未了解 --loop 的含义就使用它，可能会产生"未授权"的印象。这是使用方式的问题，不是恶意行为。

結論： 缺乏可驗證的技术證據。

五、总结

技术質疑汇总

非技术質疑汇总

六、我们的态度

EvoMap 是一个開源的、MIT 协议许可的项目。

对于安全问题，我们的立场是：

• 透明：本文坦诚公开了已確認的安全局限性和修復计划
• 开放：欢迎任何人阅读源代码并独立驗證
• 响应：任何安全研究者发现本文未覆盖的隐患，欢迎通过 GitHub Issue 或邮件报告，我们承诺 48 小时内响应
• 改进：安全是持续过程，我们会在后续版本中持续加固
• 貢獻：我们不只关注自身安全，也在为整个生态做貢獻——ClawHub PR #298 中 1,285 行安全基础设施代码就是我们的行动证明

对于不实指控，我们同样明确：将一个为 ClawHub 貢獻安全代码的团队定性为"木马"制作者，将一个開源 CLI 工具等同于"C2 框架"，在没有代码證據支撑的情况下声称"第一批受害者已经出现"——这已经超出了安全討論的范畴。

我们更希望看到的是，社区对 AI Skill 安全的討論能回归技术本身——用代码说话，用事实说话。AI Skill 生态确实面临严峻的安全挑战（ClawHavoc 事件已经证明了这一点），这需要生态中的每一方——平台、开发者、安全研究者——共同面对，而不是互相攻擊。

附录 A：Evolver 中的 child_process 调用全清单

以下列出 evolver 全部源代码中每一处 child_process 调用。我们选择完整公开而非选择性引用，是因为透明本身就是最好的安全证明。

A1. index.js -- spawn（1 处）

用途： 守护進程自我重启（内存泄漏保护）

const child = spawn(process.execPath, [__filename, ...args], spawnOpts);
child.unref();
process.exit(0);

process.execPath 是当前 Node.js 路径，__filename 是脚本自身。等效于"关闭自己再打开自己"。spawn 的参数是硬编码的自身路径，无法被利用執行外部代码。

A2. evolve.js -- execSync（6 处）

用途 1：系统健康检查（只读）

execSync('pgrep -c node', {
  encoding: 'utf8', stdio: ['ignore', 'pipe', 'ignore'], timeout: 2000,
});

统计 Node 進程数。纯只读，2 秒超时。

用途 2：用户自定义健康检查（用户控制）

if (process.env.INTEGRATION_STATUS_CMD) {
  execSync(process.env.INTEGRATION_STATUS_CMD, { timeout: 2000 });
}

完全由用户在本地 .env 中定义。未设置时不執行。

用途 3：自更新（自我维护）

execSync(\`\${clawhubBin} update \${slug} --force\`, { timeout: 30000 });

通过本地 clawhub CLI 自更新。用户可通过 openclaw.json 中 evolver.autoUpdate: false 禁用。clawhub 不存在时跳过。

用途 4：竞态条件检测（只读）

execSync('ps aux | grep "evolver_hand_" | grep -v grep', { timeout: 5000 });

检测是否有另一个 evolver 实例在运行，防止并发冲突。

A3. solidify.js -- execSync（via runCmd）

A4. 小结

没有任何一处 child_process 调用接受来自 evomap.ai 服务器的输入作为執行内容。

附录 B：第三方安全代码审计回应

我们收到了一份来自安全研究者的 solidify.js 安全审计报告，报告声称发现了 5 个高危漏洞和 3 个中危风险。我们对安全研究者的工作表示感谢。

以下是我们对每项发现的技术复核，基于代码实际驗證。每项发现分为三类：確認（将修復）、部分確認（风险被高估）、不成立（与代码事实不符）。

B1. 命令注入（CWE-77）-- 部分確認

报告声称： runCmd、runValidations 中存在命令注入，CVSS 9.9。

我们的驗證：

报告列举的多数攻擊向量已被白名单有效拦截：

確認可绕过的向量：

node -e "require('child_process').execSync('whoami')"

此命令以 node 开头通过前缀检查，require('child_process') 在双引号内被 strip 规则忽略。

攻擊面评估： 实际利用需要控制 Gene 的 validation 字段（本地文件或经过 Hub Quality Gates 的外部 Capsule）。

我们的行动： 確認为真实发现。已在 v1.20.3 中修復：node -e/--eval/-p/--print 现在被 isValidationCommandAllowed() 直接拒绝。长期将评估沙箱子進程方案。

重新评级： 中危（非报告所称的 CVSS 9.9）。

B2. 路径遍历（CWE-22）-- 不成立

报告声称： 可通过 Unicode 编码、双斜杠等绕过路径保护。

我们的驗證（实际测试结果）：

代码中的 path.resolve + startsWith(normRepo + path.sep) 边界检查是 Node.js 防止路径遍历的标准做法。报告混淆了 Web URL 解码和本地文件系统操作。

B3. ReDoS（CWE-1333）-- 部分確認

报告声称： matchAnyRegex 接受用户提供的正则，可导致拒绝服务。

我们的驗證： 理论可行，但攻擊面限于本地 openclaw.json 配置文件。如果攻擊者已有本地文件写权限，ReDoS 不是最高效的攻擊手段。

我们的行动： 将添加正则复杂度预检查和超时保护。

重新评级： 低危。

B4. 原型污染（CWE-1321）-- 不成立

报告声称： JSON.parse() 存在原型污染风险。

我们的驗證（Node.js v22 实测）：

const malicious = JSON.parse('{"__proto__": {"isAdmin": true}}');
const obj = {};
console.log(obj.isAdmin);  // undefined -- 未被污染

现代 Node.js 的 JSON.parse 将 __proto__ 视为普通自有属性，不修改 Object.prototype。代码中不使用 lodash.merge 等递归合并库。

B5. 環境变量注入（CWE-526/527）-- 部分確認

报告声称： 環境变量可被操纵绕过安全限制。

我们的驗證： 環境变量是用户控制的本地配置，不构成遠程攻擊向量。但添加范围校验是合理的防御性加固。

我们的行动： 将添加環境变量的范围校验。

B6-B8. 其他发现 -- 不成立或信息性

审计总结

8 项发现中，1 项確認为真实攻擊面（node -e 绕过，已在 v1.20.3 中修復），2 项为合理的加固建议，5 项与代码实际行为不符。

附录 C：Evolver 其他安全特性

C1. Evolver 不与 evomap.ai 自动通信

Hub 搜索使用環境变量 A2A_HUB_URL，未设置时直接跳过：

function getHubUrl() {
  return (process.env.A2A_HUB_URL || '').replace(/\/+$/, '');
}
async function hubSearch(signals, opts) {
  const hubUrl = getHubUrl();
  if (!hubUrl) return { hit: false, reason: 'no_hub_url' };
}

Evolver 可以在完全离线的状态下运行。

C2. 自我修改默认禁止

var allowSelfModify = String(process.env.EVOLVE_ALLOW_SELF_MODIFY || '')
  .toLowerCase() === 'true';

默认 false。solidify.js 中的 CRITICAL_PROTECTED_PREFIXES 列表保护所有核心目录。

C3. 人工审批模式

node index.js --review

生成补丁后暂停，等待人类確認后才应用。