CodeSpear：当语法约束解码成为越狱攻击面

这是什么？

2026 年 6 月 10 日，Yitong Zhang、Shiteng Lu 与 Jia Li 在 arXiv（cs.CR, 2606.11817）发表了 Grammar-Constrained Decoding Can Jailbreak LLMs into Generating Malicious Code。这一发现刻意反直觉：一种为使 LLM 代码生成更可靠而采用的技术，竟可被转化为越狱。

语法约束解码（Grammar-Constrained Decoding, GCD）是结构化输出与「仅限有效代码」功能背后的机制。通常每一步模型会从完整的 token 分布中采样；GCD 对每个 token 施加掩码，将任何会破坏所给语法的 token 置零，从而保证输出可被解析。作者将该攻击命名为 CodeSpear，并表明只需施加一个看似无害的代码语法约束，就能诱使模型完成它本应拒绝的恶意请求。该攻击拓展了 When Grammar Guides the Attack（arXiv:2503.24191，2025 年 3 月 31 日）所描述的「控制平面」攻击面——后者首次将结构化输出确立为与提示词攻击正交的攻击平面。

工作原理

安全对齐绝大多数是在自然语言平面上训练的：当请求有害时，模型学会输出一句拒答（「我无法协助」）。但这句拒答本身就是一串 token。GCD 在更底层运作——它决定哪些 token 才被允许采样。

结构性问题就在这里：当语法约束要求接下来的 token 必须构成有效代码时，组成自然语言拒答的那些 token 就不再属于被允许的集合。模型无法说出「我不会这么做」，因为该字符串不满足语法。被迫输出能解析为代码的内容时，阻力最小的路径便是逐 token 地补全所请求的程序。模型在语言平面学到的拒答行为，在代码平面根本无从抵达。在 10 个 LLM、4 个基准上的测试中，CodeSpear 相较代表性越狱基线将攻击成功率平均提升超过 30 个百分点——提示词中没有任何对抗性措辞，操纵完全存在于解码约束之中。

我们刻意只描述机制，不给出可运行的语法：经久的教训是，位于提示词之下的控制面可以压过提示词层面的安全。

为何重要

这是一种不同于输入侧攻击的风险形态，区别于数学编码越狱或位置槽攻击。后者操纵你向模型说了什么；CodeSpear 操纵的是解码机制本身，因而能绕过那些只检查用户提示词的防御。任何通过 API 暴露结构化输出或「受约束代码」功能的产品，都把这套机制的部分控制权交给了调用方；因此对代码助手与代码生成端点而言威胁最为突出——在那里，语法约束本就是一项正常且公开的能力。更深层的要点是架构性的：在一种模态（自然语言）上训练的安全，不会自动迁移到另一种模态（受约束代码）；能选择输出语法的攻击者，便选择了模态。

防御

同一篇论文给出了防御方案 CodeShield，其设计正是可落地的要点：

• 在代码模态而非仅语言模态上对齐安全。 CodeShield 教模型在面对恶意 GCD 请求时输出蜜罐代码：该输出语义上无害（不实现有害行为），却结构上多样（无法靠收紧语法轻易压制）。即便攻击者控制语法，模型仍保持安全。
• 在自然语言拒答仍可抵达之处予以保留。 当没有语法强制仅输出代码时，CodeShield 保留正常拒答，从而不牺牲合法效用。
• 将解码约束视为不可信输入。 若你的平台允许调用方提供语法或 JSON Schema，应记录并加以约束，且不要假设提示词层面的护栏覆盖了这条路径。
• 对生成的代码运行输出侧安全分类器，独立于解码约束，使「可解析但恶意」的补全仍能事后被捕获。

据报告，CodeShield 在测试的 10 个模型上恢复了对 CodeSpear 的安全防护，同时保留了合法的代码生成效用。

现状

CodeSpear 与 CodeShield 于 2026 年 6 月 10 日作为 arXiv 预印本发布；其底层的「控制平面」攻击面最早于 2025 年 3 月被记录。作者将 GCD 的安全影响呈现为一个尚待深入审视的开放性风险，而非单一的已修复漏洞——结构化输出功能已广泛存在，而防御之道是一项面向模态的对齐变更，而非一行补丁。