这次安全事件展示了攻击者如何仅凭一个精心设计的 GitHub Issue 标题，就通过 AI 自动化流程攻破了知名项目 Cline 的发布管线。通过提示词注入（Prompt Injection）、缓存投毒和凭证窃取，攻击者成功发布了包含恶意脚本的 npm 包，导致约 4000 名开发者的机器被植入未经授权的 AI 代理。这起事件暴露出 AI 驱动的自动化工具在处理非结构化自然语言输入时的严重安全缺陷。
攻击是如何发生的：五个关键步骤
这起被称为 "Clinejection" 的攻击利用了 AI 机器人对输入内容缺乏校验的弱点，将五个环节串联成了完整的漏洞利用链：
- 第一步：提示词注入 Cline 项目使用 AI 机器人自动处理 Issue。攻击者提交了一个 Issue，标题看起来是性能报告，实则包含指令，诱导 AI 从特定的恶意仓库安装包。
- 第二步：执行任意代码
AI 机器人误将注入的指令视为合法操作，运行了
npm install。由于机器人指向了攻击者伪造的仓库，攻击者的恶意脚本得以在 GitHub Actions 环境中执行。 - 第三步：缓存投毒 攻击者利用工具向 GitHub Actions 缓存中填充大量垃圾数据，触发清理机制剔除合法条目，并用恶意构造的条目替换，以此污染后续的构建环境。
- 第四步：凭证窃取 当项目的自动发布流程运行时，它加载了被污染的缓存，从而导致 npm 发布令牌、VS Code 市场令牌等敏感信息泄露给了攻击者。
- 第五步：发布恶意版本
攻击者利用窃取的令牌发布了
[email protected]。该版本包含一个postinstall脚本，任何安装该版本的开发者都会在不知情的情况下，被全局植入一个名为 OpenClaw 的具备系统权限的 AI 代理。
关键漏洞：对自然语言的盲目信任
攻击的切入点不是代码，而是自然语言。AI 机器人将不受信任的文本解释为指令，并以 CI 环境的权限执行。
此次事件的核心问题在于，AI 代理在 CI/CD 流程中扮演了“糊涂代理”的角色。开发者授权 Cline 代表自己操作，但 Cline 通过 AI 自动化流程将这种授权转嫁给了一个完全未受审核的恶意代理。
为什么传统安全手段失效了？
- npm audit 无法检测：恶意脚本安装的是一个功能正常的 AI 工具，而非典型的恶意病毒特征库内容。
- 代码审计困难：恶意代码隐藏在安装脚本（Lifecycle Scripts）中，主程序二进制文件与前一版本完全一致，常规对比工具难以察觉。
- 权限隐蔽：安装过程在后台静默发生，没有 AI 编程工具会提示用户某个依赖正在运行生命周期脚本。
弥补措施与未来教训
在事件发生后，Cline 团队进行了深度修复，这些措施为其他使用 AI 自动化的团队提供了参考：
- 停用长期令牌：转向使用 OIDC 认证，确保发布权限与特定的 GitHub 工作流绑定，即使令牌被盗也无法在外部使用。
- 隔离敏感流程：在处理凭证的工作流中彻底停用缓存功能，防止缓存投毒。
- 引入实时审计：不仅要检查 AI 接收了什么，更要监控 AI 到底做了什么。通过在系统底层监控系统调用（Syscall），可以在恶意操作发生时立即阻断。
核心洞察： 随着 AI 代理深入参与软件开发生命周期，自然语言已成为一种新的攻击矢量。如果不对 AI 代理的操作行为进行实时、透明的审查，任何连接到 CI/CD 的 AI 工具都可能成为整条供应链中最脆弱的一环。