execSync() 拼接 Git 参数的代价：从元数据到供应链执行

导语

在 Node.js 中调用 Git，有两种看起来差不多的写法：

复制代码

execSync(`git merge-base ${head} ${base}`);

以及：

复制代码

execFileSync("git", ["merge-base", head, base]);

两段代码都能完成正常业务，但安全模型完全不同。

第一段把程序、选项和数据混成 Shell 源码；第二段直接启动程序，并保留参数边界。只要 head 或 base 来自外部可控的 Git 元数据，这个差异就可能决定 CI 是正常报错，还是执行了额外操作系统命令。

Argos CI 的 CVE-2026-59960 是一个非常典型的案例。本文不重复泛泛介绍命令注入，而是深入讨论：为什么参数转义不是首选方案、为什么补丁要同时搜索四个汇点，以及怎样为子进程调用建立可验证的安全不变量。

一、漏洞事实

组件：@argos-ci/core；
漏洞：CVE-2026-59960 / GHSA-4x45-gxvp-6283；
影响：6.2.0 及更早版本；
修复：6.2.1；
类型：CWE-78 OS 命令注入；
严重度：High，CVSS 3.1 7.5；
输入：CI branch/ref；
汇点：模板字符串形式的 execSync()；
可达条件：上传流程在 hasRemoteContentAccess: false 时进行本地 merge-base 处理。

公告和修复于 2026 年 6 月 21 日发布，GitHub 已审核漏洞库于 9 月 10 日收录。官方一手来源截至核验时未确认在野利用。

二、`execSync()` 到底执行了谁

调用：

复制代码

execSync("git fetch origin main");

从开发者视角看，是在执行 Git。从进程模型看，通常先执行 Shell，再由 Shell 启动 Git：

复制代码

Node.js
  │
  ▼
/bin/sh -c "git fetch origin main"
  │
  ▼
git fetch origin main

Shell 的职责就是解释程序文本。变量替换、命令替换、管道、重定向、分隔符和引用规则，都是它的功能，而不是异常。

如果外部数据被拼进这段文本，应用就等于把部分程序源码交给外部主体编写。

三、数据从哪里来并不改变汇点风险

Argos 的分支值可来自 GITHUB_HEAD_REF 或 ARGOS_BRANCH。它经过 CI 平台、环境变量和配置对象后，看起来比 HTTP 请求参数更可信。

但命令安全只关心两个问题：

谁能影响该值？
它是否进入了命令解释器？

中间经过 JSON、TypeScript 类型、Schema 字符串转换或环境变量，都不会自动提供 Shell 隔离。

这也是为什么下列做法不能单独证明安全：

String(input)；
TypeScript 标注为 string；
从官方 CI 上下文读取；
只检查空值；
记录后再使用；
先传过多个内部函数。

污点不会因为经过可信组件而自然消失。

四、缺陷代码中的两个层次

官方公告首先展示了 gitFetch：

复制代码

execSync(
  `git fetch --force --update-head-ok --depth ${depth} origin ${ref}:${target}`,
);

另一个路径位于 merge-base 计算：

复制代码

execSync(`git merge-base ${head} ${base}`);

这两处问题具有相同结构：

复制代码

外部字符串
   +
固定命令模板
   ↓
Shell 解释

一旦发现这种模式，安全修复就不能只盯住最初触发的函数。

五、为什么官方补丁要修四处

修复提交说明共覆盖：

gitFetch；
gitMergeBase；
listShas；
listParentCommits。

前两处与公开攻击链直接相关，后两处是同模块中的变体。

这种修复方式体现了漏洞治理中的"根因半径"：

报告提供的是一个可达路径；
根因是"外部数据进入 Shell 字符串"；
同一根因可能存在于多个调用点；
修复完成的标准是模式消失，而不是一个 PoC 失效。

代码审查时，应搜索的不只是 execSync，还包括：

复制代码

exec
execSync
spawn(..., { shell: true })
sh -c
bash -c
模板字符串生成脚本
字符串拼接的命令包装器

六、正确修复：取消解释，而不是改进转义

官方补丁将 Git 调用改为：

复制代码

execFileSync("git", ["merge-base", head, base]);

以及：

复制代码

execFileSync("git", [
  "fetch",
  "--force",
  "--update-head-ok",
  "--depth",
  String(depth),
  "origin",
  `${ref}:${target}`,
]);

现在，固定代码和外部数据由 API 结构分开表达：

程序固定为 git；
每个选项是单独参数；
ref 作为一个参数传给 Git；
不再调用 Shell；
Shell 特殊字符不再获得 Shell 语义。

参数中仍有模板字符串，为什么可以？

${ref}:${target} 仍在构造字符串，但这个字符串只是参数数组的一项，解释者是 Git，而不是 Shell。

它仍需要满足 Git 的业务规则，也可能被 Git 拒绝；但它不会因为 Shell 元字符而启动另一条命令。

这体现了安全编码的核心：不是禁止字符串拼接本身，而是控制拼接结果将进入哪个解释器。

七、为什么字符过滤不是主修复

团队常见的应急方案是过滤分号、空格或引号。这种方法脆弱，因为：

Shell 特殊语法不止一种；
引号和转义规则复杂；
POSIX Shell 与 Windows 命令环境不同；
输入可能经过多轮解码和拼接；
新代码可能加入另一个未经同样过滤的字段；
业务允许的 Git ref 与 Shell 安全集合并不天然相同。

业务校验仍应存在，例如拒绝不符合产品约束的 branch/ref。但它属于纵深防御，不能代替移除 Shell。

八、无害代码模型：不启动任何子进程

复制代码

from dataclasses import dataclass


@dataclass
class CommandPlan:
    shell_source: str | None
    program: str | None
    arguments: list[str]


def old_plan(ref: str) -> CommandPlan:
    return CommandPlan(
        shell_source=f"git fetch origin {ref}:target",
        program=None,
        arguments=[],
    )


def new_plan(ref: str) -> CommandPlan:
    return CommandPlan(
        shell_source=None,
        program="git",
        arguments=["fetch", "origin", f"{ref}:target"],
    )


value = "UNTRUSTED_REF"
print(old_plan(value))
print(new_plan(value))

安全断言可以写成：

复制代码

assert old_plan(value).shell_source is not None
assert new_plan(value).shell_source is None
assert new_plan(value).arguments[2] == "UNTRUSTED_REF:target"

该模型只验证调用结构，不执行 Git、Shell 或攻击载荷。

九、回归测试为什么允许 Git 失败

官方补丁增加的测试会向 merge-base 路径提供包含 Shell 特殊语义的 ref，并断言标记文件没有创建。

目标 Git 命令可能失败，因为 ref 本身无效。测试捕获这个错误，不把"Git 必须成功"当成安全标准。

真正的安全不变量是：

外部数据不得进入 Shell；
不得产生 Git 之外的子进程；
不得出现非预期文件或网络副作用；
错误必须来自目标程序对参数的正常拒绝。

这比只断言退出码或错误文本更可靠。

十、面向 Node.js 项目的审计规则

规则一：固定程序使用直接执行 API

如果程序名固定，应优先使用 execFile、execFileSync 或 spawn 的参数数组模式。

规则二：`shell: true` 必须显式审查

任何 spawn 配置中的 shell: true，都应被视为信任边界扩大。

规则三：追踪所有元数据源

除用户请求外，还要覆盖：

Git ref；
PR 标题；
commit message；
文件名和路径；
CI matrix；
Job 输出；
第三方 API 返回值。

规则四：包装器不能隐藏 Shell

内部函数即使名为 runGit()，只要底层调用 Shell，调用者仍需承担注入风险。应在类型或 API 名称中暴露这一事实。

十一、CI 权限为何仍然重要

消除注入是代码修复，最小权限是失效防护。

若 Runner 无生产 Secret、只读、禁网、一次性销毁，即使某个依赖再次出现命令执行漏洞，影响也更有限。反之，如果任务拥有发布令牌、云身份和持久工作区，一次子进程注入可能扩展为供应链事件。

建议：

外部 PR 不注入高价值 Secret；
GITHUB_TOKEN 默认只读；
发布步骤使用独立环境审批；
自托管 Runner 不跨信任域复用；
缓存按仓库和信任级别隔离；
不可信任务不挂载 Docker Socket。

十二、排查与处置

版本

复制代码

npm ls @argos-ci/core

同时检查锁文件、全局 CLI、CI 镜像与缓存恢复后的实际依赖。

工作流

确认：

是否执行 Argos upload；
是否处理外部 ref；
是否使用 pull_request_target；
是否处于 hasRemoteContentAccess: false；
任务可以访问哪些凭据。

代码

搜索所有命令执行 API，并追踪参数到 branch、tag、SHA、路径与 CI 环境变量。

历史证据

核对异常子进程、文件、出站连接、Token 使用、OIDC 申请和制品变化。不要因为最终 Git 命令失败就直接排除前置副作用。

十三、P0---P2 清单

P0

升级到 @argos-ci/core@6.2.1 或更高兼容版本；
重新构建并验证实际 CI 制品；
暂停高权限外部 PR 中的受影响步骤；
移除不可信任务的 Secret 和写权限。

P1

用参数数组替换字符串式子进程调用；
对同模块和全仓库做变体分析；
增加特殊输入的无副作用测试；
审核内部命令包装器。

P2

制定"默认禁止 Shell"的编码基线；
对例外调用要求安全评审；
将 CI 元数据加入污点分析；
统计组织内 Shell 调用数量与修复覆盖率。

十四、总结

Argos CVE-2026-59960 的修复看似只是从 execSync 换到 execFileSync，实质上是在恢复一条已经消失的边界：固定程序属于代码，branch/ref 属于数据。

当两者被拼成一个字符串交给 Shell，这条边界只能依赖不完美的转义维持；当程序和参数由 API 分开表达，边界成为运行时结构的一部分。

安全 API 最有价值的地方，不是让开发者更容易记住危险字符，而是让危险字符根本没有机会进入错误的解释器。

事实、推断与未知事项

事实

影响 @argos-ci/core <= 6.2.0；
修复版为 6.2.1；
问题源于 ref 进入字符串式 execSync()；
补丁用 execFileSync() 参数数组覆盖四处汇点。

推断与建议

影响上限取决于 Runner 权限；
应默认取消 Shell、做变体搜索并隔离外部 PR。

未知

官方未确认在野利用；
具体组织是否受影响需结合版本与路径条件判断。

execSync() 拼接 Git 参数的代价：从元数据到供应链执行

导语

一、漏洞事实

二、execSync() 到底执行了谁

三、数据从哪里来并不改变汇点风险

四、缺陷代码中的两个层次

五、为什么官方补丁要修四处

六、正确修复：取消解释，而不是改进转义

参数中仍有模板字符串，为什么可以？

七、为什么字符过滤不是主修复

八、无害代码模型：不启动任何子进程

九、回归测试为什么允许 Git 失败

十、面向 Node.js 项目的审计规则

规则一：固定程序使用直接执行 API

规则二：shell: true 必须显式审查

规则三：追踪所有元数据源

规则四：包装器不能隐藏 Shell

十一、CI 权限为何仍然重要

十二、排查与处置

版本

工作流

代码

历史证据

十三、P0---P2 清单

P0

P1

P2

十四、总结

事实、推断与未知事项

事实

推断与建议

未知

二、`execSync()` 到底执行了谁

规则二：`shell: true` 必须显式审查