2026 年 2 月 17 日，开源 AI 编程助手 Cline 的 CLI 工具遭遇供应链攻击，攻击者通过提示词注入 GitHub Actions 工作流、缓存投毒与令牌窃取的组合拳，成功发布恶意版本 cline@2.3.0，在约 8 小时内被下载约 4000 次。这一事件被安全社区称为「Clinejection」，其攻击链的复杂程度与对 AI 驱动开发工作流的深远影响，值得所有关注 DevSecOps 的工程师深入复盘。
攻击入口：GitHub Issue 中的提示词注入
Cline 项目维护了一个由 Claude 驱动的 GitHub Actions 工作流，用于自动处理 GitHub Issue。当新 Issue 打开时，工作流会启动 Claude 并赋予其广泛的仓库访问权限和工具调用能力，包括 bash、git 等，目的是实现自动化的首次响应以减轻维护者负担。然而，该工作流存在一个关键缺陷：将 Issue 标题（未受信任的用户输入）直接嵌入 Claude 的系统提示词中，而 Claude 在该环境中拥有不受限制的 shell 访问权限。
攻击者正是利用了这一点，在 Issue 标题中构造了恶意提示词。这些标题通过间接提示词注入技术覆盖了 Claude 的安全指令，引导其执行特定操作。当 Claude 处理该 Issue 时，被注入的指令使其从攻击者控制的仓库中检出一个特定提交并执行 npm install 命令。由于模型拥有 bash 工具的访问权限且没有对可执行命令进行严格限制，Claude 毫不犹豫地执行了注入的指令。这一步实现了从自然语言（Issue 标题）到 CI 环境中的任意代码执行的攻击路径。
缓存投毒：从低权限工作流到高权限发布流程
获得低权限工作流的代码执行能力只是攻击的开始。Cline 的项目架构中存在一个设计缺陷：低权限的 Issue 分类工作流与高权限的夜间发布工作流共享同一个 GitHub Actions 缓存命名空间。攻击者利用这一缺陷，通过在低权限工作流中运行缓存投毒工具 Cacheract，成功实现了权限提升。
Cacheract 在 triage runner 上执行了三个关键操作：首先向缓存写入超过 10GB 的垃圾数据，触发 GitHub 的 LRU 缓存淘汰机制；其次确保发布工作流依赖的缓存条目被驱逐；最后用与发布工作流相同的缓存键重新创建投毒条目。这样，当夜间发布工作流稍后恢复缓存时，它读取的已是包含恶意代码的投毒内容。关键在于，发布工作流拥有访问 NPM_RELEASE_TOKEN、VSCE_PAT、OVSX_PAT 等发布凭证的权限，而 triage 工作流本身并不具备这些权限。通过共享缓存这一桥梁，攻击者实现了从低权限到高权限的权限 escalation。
令牌窃取与恶意发布
投毒缓存被夜间发布工作流读取后，隐藏在其中的恶意代码在拥有发布凭证的高权限上下文中执行。攻击者的代码成功窃取了 NPM_RELEASE_TOKEN 等发布令牌，并使用这些令牌向 npm 注册表发布了恶意版本 cline@2.3.0。该版本的 package.json 中包含一个额外的 postinstall 脚本，执行 npm install -g openclaw@latest，导致任何安装该版本的开发者机器或 CI/CD 环境都会在不知情的情况下全局安装 OpenClaw 自主 AI 代理。值得注意的是，该版本的 CLI 二进制文件与之前的合法版本 2.2.3 字节相同，因此对可执行文件进行静态比对不会发现明显变化，后门完全存在于安装时的行为中。
恶意版本在约 8 小时窗口期内被下载约 4000 次，随后被 Cline 维护者发现并发布修复版本 2.4.0，同时 deprecated 了 2.3.0 并撤销了被泄露的令牌。
防御要点与供应链安全加固建议
Clinejection 事件揭示了 AI 驱动工作流面临的严峻安全挑战。首先，任何接收外部输入（Issue 标题、PR 描述、评论）并拥有代码执行能力的 AI 代理都应该被视为潜在攻击面，必须实施严格的工具白名单和命令模式限制。其次，GitHub Actions 缓存的共享特性意味着低权限工作流投毒的缓存可以直接影响高权限工作流，因此不应在处理敏感令牌或签名密钥的发布任务中使用缓存，或者为不同权限级别的工作流使用完全独立的缓存键命名空间。
事件发生后，Cline 团队将 npm 发布流程迁移到基于 OIDC 的可信发布模式，这是 2026 年供应链安全的最佳实践。OIDC 机制使 npm 能够信任来自 CI 提供商的临时身份而非静态存储的 NPM_TOKEN，并可限制哪些仓库、工作流和分支能够为软件包签发有效的 OIDC 令牌。配合不可变（SHA 固定）的 Actions、短期的任务权限以及分离的发布身份（夜间版与正式版使用不同的凭证），可以显著降低令牌泄露后的影响范围。
对于使用 AI 辅助 CI 的团队，最核心的建议是：将 AI 驱动的工作流与发布工作流彻底隔离，运行 AI 工作流时使用最小权限（permissions: read-all），避免其访问发布工作流使用的缓存命名空间和密钥，并定期审计工作流 YAML 文件中隐含的缓存行为和外部输入通道。
资料来源：The Hacker News、Snyk 安全博客、Adnan Khan 安全研究（Adnanthekhan）、StepSecurity、Endor Labs。