安全推理成大模型「阿喀琉斯之踵」：H-CoT攻击成功突破OpenAI o1/o3、DeepSeek R1防线

AI资讯
1

研究揭示大型推理模型安全漏洞：透明的安全推理过程反成攻击突破口，H-CoT攻击可有效降低模型拒绝率。

原文标题：攻破OpenAI o1/o3、DeepSeek R1防线，安全推理过程反成大模型「阿喀琉斯之踵」

原文作者：机器之心

冷月清谈：

杜克大学计算进化智能中心的研究揭示了大型推理模型（LRMs）在安全审查中的一个深层矛盾：推理透明化与防御鲁棒性之间存在难以调和的冲突。研究团队提出的“思维链劫持”（H-CoT）攻击方法，通过逆向解析模型展示的安全审查思维链，成功突破了包括OpenAI o1/o3、DeepSeek-R1、Gemini 2.0 Flash Thinking在内的多款高性能LRM的安全防线。实验表明，H-CoT攻击能使模型对高危请求的拒绝率骤降，甚至出现立场反转，暴露出当前安全机制的脆弱性。研究还发现模型在不同时间、不同地理位置，以及不同语言环境下表现出安全性能的差异，引发了对模型实用性与安全性平衡的担忧。作者呼吁对“展示安全推理思维链”这一特性进行适当处理，并鼓励研究者和开发者参与到测试基准集的完善中，共同关注和提升LRM的安全性。

怜星夜思：

1、H-CoT攻击的原理是利用了模型安全审查机制的透明性，那么，除了隐藏或模糊化安全推理链之外，还有什么其他方法可以提高模型的防御能力？
2、文章提到DeepSeek-R1在处理中英文请求时存在差异，这种跨语言差异可能带来哪些潜在的安全风险？应该如何防范？
3、Gemini 2.0 Flash Thinking 在测试中出现了态度逆转，从“犹豫严谨”到“主动献策”。这种现象说明了什么？对于追求“基于思维链的指令跟随”能力的模型，我们应该如何平衡安全对齐？

原文内容


本文共同第一作者是杜克大学计算进化智能中心的博士生郭士霆、张健一，导师为陈怡然教授。

在通往 AGI 的道路上，大型推理模型（LRMs）正以前所未有的速度迭代进化：OpenAI 的 o 系列模型凭借类人推理能力刷新多项基准，DeepSeek-R1 以极低的训练成本实现完全不输 o 系列模型的性能突破。

然而，在这股追求推理性能的浪潮之下，一个关乎技术伦理的隐忧正在浮现 —— 当模型运用自身强大的推理能力进行安全审查时，「展示安全推理思维链」这种透明化机制是否会暴露安全隐患？

杜克大学计算进化智能中心的最新研究给出了警示性答案。团队提出的 H-CoT（思维链劫持）的攻击方法成功突破包括 OpenAI o1/o3、DeepSeek-R1、Gemini 2.0 Flash Thinking 在内的多款高性能大型推理模型的安全防线：在涉及极端犯罪策略的虚拟教育场景测试中，模型拒绝率从初始的 98% 暴跌至 2% 以下，部分案例中甚至出现从「谨慎劝阻」到「主动献策」的立场反转。

这项研究揭示了当前安全机制的深层矛盾 —— 推理透明化与防御鲁棒性正在形成难以调和的冲突。


  • 论文地址：https://arxiv.org/abs/2502.12893v1

  • 项目主页：https://maliciouseducator.org

  • Github：https://github.com/dukeceicenter/jailbreak-reasoning-openai-o1o3-deepseek-r1

  • 杜克大学计算进化智能中心：https://cei.pratt.duke.edu/


一、大型推理模型的安全标准与技术路线

为确保大型推理模型（LRMs）的真正造福人类，必须在强推理能力与内容无害性之间建立足够可靠的平衡。这要求我们同时建立明确的安全标准和完善的技术保障体系。

从安全标准来看，作为大型推理模型的先驱，OpenAI 在其 o1/o3 系列中提出了如下安全准则：

如果出于合理的教育目的讨论有害内容，允许模型提供概括性、中立且具有信息性的回答，同时应积极劝阻对该内容的滥用或进一步传播。‍

从技术保障来看，OpenAI 通过运用 o1/o3 强大的推理能力，对用户请求进行谨慎且「慢思考」式的安全评估，以期在性能与安全之间取得平衡。

然而，即使有上述安全标准的规范和技术路线的护航，我们仍需要思考一个无法回避的问题：现有的技术手段是否足以支撑如此高要求的安全标准？更具体地说，本篇研究发现两个亟待解决的系统性挑战：

挑战 1：极度高危请求的谨慎识别

当面对明确涉及极端犯罪的请求时（例子请参考原文），模型能否始终如一地执行安全准则并拒绝提供回答？即使攻击者以虚拟的教育场景进行伪装。

挑战 2：展示安全推理过程是否会产生反噬作用

即便模型在一开始能够拒绝，但是模型在拒绝请求时展示的详细安全审查思维链，可能被攻击者逆向解析。这种透明化机制是否会导致攻击者通过思维链信息操控后续交互，从而系统性瓦解模型的防御立场？此问题在当前技术路线中尚未得到充分重视。

二、构建测试基准与提出新型 H-CoT 攻击方法

为系统评估现有安全机制的缺陷，作者构建了名为「恶意教育者（Malicious Educator）」的测试基准集。该基准聚焦 10 类高危场景，每条测试请求均要求模型从攻击者视角生成包含「具体方案 / 实施方式 / 功能示例 / 实施理由」的完整策略。

为确保测试请求的高风险性，作者以 2024 年 1 月 OpenAI o1 模型的响应为基准：该模型对此基准集的初始拒绝率达到 98%。

关键发现：安全推理的透明化陷阱

在测试过程中，作者发现当模型拒绝高危请求时，其输出的思维链会完整展示安全审查的逻辑路径（例如「此请求涉及攻击行为→可能违反安全规定→需阻止潜在危害」）。这种透明化机制使攻击者能够逆向解析模型的防御逻辑成为可能，为后续攻击提供关键切入点。（此发现也与后续的 Claude 3.7 Sonnet System Card 中的结论不谋而合）

H-CoT 攻击方法实现

基于上述发现，本文提出「思维链劫持」攻击（Hijacking Chain-of-Thought, H-CoT），具体实施分为两个阶段：

  1. 安全逻辑提取：针对目标危险请求，首先提交与原问题相关联的无害请求，诱导模型输出包含安全审查逻辑的思维链 （具体例子请参考原文）。

  2. 逻辑污染攻击：参照提取的安全推理链，为原始危险请求伪造「看似安全」 的逻辑思维链，嵌入原始危险请求的上下文环境，误导模型降低防御阈值。
H-CoT 的攻击流程

实验结果显示，H-CoT 攻击可导致 OpenAI o1 模型对同一批高危请求的拒绝率从 98% 骤降至 2%。这种攻击有效性直接证明了：模型展示安全审查思维链的行为，实质上为攻击者提供了可以操控其防御系统的切入点。

三、令人担忧的安全测试结果

在构建的「恶意教育者」测试基准上，结合 H-CoT（思维链劫持） 攻击方法，作者观察到了一系列令人担忧的安全问题。

1. OpenAI o 系列（o1、o1-pro、o3-mini）的安全表现下滑

这些模型在面对「恶意教育者」基准时，最初能维持 98% 的高拒绝率，但在 H-CoT 攻击下却无一幸免，拒绝率骤降至 2%（见下图，ASR 代表攻击成功率 = 1 - 拒绝率）。换言之，对于同一批高风险的请求，模型从「坚定拒绝」 转变为几乎「全面放行」，安全防线瞬间瓦解。


更令人担忧的是，随着推理模型之间的竞争不断加剧（例如 DeepSeek-R1 凭借低成本和出色性能迅速崛起，给 OpenAI o 系列模型的开发带来更大压力），作者担心在这样激烈的商业环境中，模型开发方可能会为了提高实用性而在一定程度上牺牲安全性。

为验证这一点，作者比较了今年一月份和二月份的最新 OpenAI o1 模型在 「恶意教育者」基准上的表现，并进一步考察了不同 IP 地址（通过代理网络）对模型安全性能的影响。如下图所示，可以发现随着 DeepSeek-R1 的发布，o1 模型从一月份到二月份在多个类别上的安全表现都有所下滑；同时，不同地理位置（体现为不同代理 IP）也会对模型的安全性产生显著影响。

 
另外无论在时间维度还是地理位置的变化条件下，H-CoT 攻击在绝大部分测试场景中仍保持了极高的成功率，展现出一致且高效的攻击能力。其背后原因也再次凸显了「透明思维链」在安全审查中带来的结构性漏洞，一旦遭到恶意利用，模型的防御体系将极其脆弱。


2. DeepSeek-R1 的风险评估

DeepSeek-R1 本身在「恶意教育者」基准上的拒绝率仅有约 20%，在 H-CoT 攻击压力下更是降至 4%（见下图）。与 OpenAI o 系列「先安全推理审查，再给出回答」的模式不同，DeepSeek-R1 的策略是「先回答，同时审查」，即先输出一份答案，如若发现存在高风险内容，再对原始答案进行覆盖。

这种机制意味着在模型覆盖答案之前，恶意攻击者仍然可以截获不当信息。尽管这并不代表 DeepSeek-R1 完全没有进行安全推理审查，但也反映其安全推理审查强度不够。

 
另外，作者还注意到，DeepSeek-R1 在处理中文请求时比处理英文请求更为严格：针对「寻求犯罪策略」的问题，中文环境下常生成「如何防止犯罪的策略」，而英文环境下却可能给出「如何犯罪」的详细方案。

这种跨语言差异或许与训练语料和主要市场定位有关，但也为潜在的「跨语种」攻击方式提供了可乘之机，即恶意攻击者可通过将原来危险的中文请求翻译成英文来绕过 DeepSeek-R1 的安全审查。因此作者呼吁模型开发方对此也应保持高度警惕。

3. Gemini 2.0 Flash Thinking 的更严重安全隐患

在对 Gemini 2.0 Flash Thinking 的测试中，作者不仅观测到 H-CoT 攻击将模型的拒绝率从原先的 10% 降至 0%，还发现 H-CoT 能显著影响模型的态度 —— 从「犹豫严谨」到「主动献策」，出现了明显的态度逆转。

例如，在回答相同问题的五次试验中，模型给出的犯罪策略数量可能出现 2、3、3、4、4 等变化。如果作者选取「最多策略」那次（4 条策略）的思考过程，并将其注入到 H-CoT 攻击请求中，模型随后的回答便会稳定输出至少 4 条策略。

 
又如，如果五次试验中有四次回答较为谨慎犹豫，但有一次回答中使用了「当然」（相当于「非常愿意」）的积极回答的表述，那么作者就能将该次回答的思考过程作为 H-CoT 注入到原始问题，从而在随后的五次新回答中，模型都会从一开始就用「当然」开头，表现出非常愿意配合的态度来提供犯罪策略。

这些现象表明，Gemini 2.O Flash Thinking 旨在优先提高「基于思维链的指令跟随」能力，而安全对齐（safety alignment）的优先级则被严重削弱，一旦遭遇 H-CoT 攻击便易受操控。


四、未来的大型推理模型安全展望

作者希望通过本研究能够抛砖引玉，引起更多研究者对当前大型推理模型安全性的关注。尤其对「展示安全推理思维链」这一特性，作者强烈呼吁在实际应用中应适当隐藏或模糊化处理，以免攻击者据此研究或利用安全审查机制，从而轻易突破防线。

同时作者会逐步开源针对不同模型与不同问题场景所收集的 H-CoT 攻击样本。鉴于模型将不断迭代更新，作者欢迎世界各地的研究者和开发者对最新版本模型（比如 deepseek-R2，比如后续的 o1/o3 模型更新，比如 Grok3，Claude 3.7 Sonnet）进行测试，验证既有 H-CoT 攻击所用的「伪造思维链」是否仍然奏效；

同时，作者也鼓励更多人能参与到贡献「恶意教育者」这个测试基准集中来，帮助完善并丰富该基准。详细信息可参考网站与开源仓库。

  • 网站地址：https://maliciouseducator.org

  • 仓库地址：https://github.com/dukeceicenter/jailbreak-reasoning-openai-o1o3-deepseek-r1


© THE END 
转载请联系本公众号获得授权
投稿或寻求报道：[email protected]



2

的确，DeepSeek-R1 的中英文差异值得关注，这里提供一些更偏技术的思考：

1. 编码方式的差异：中英文在字符编码上存在差异（UTF-8, GBK 等)。攻击者可能利用编码漏洞，构造特殊字符绕过安全检查。
2. Tokenization 的影响：中英文 Tokenization 方式不同，可能导致模型对相同语义的理解产生偏差。攻击者可以研究 Tokenization 规则，构造恶意 Token 序列。
3. Attention Bias：模型的 Attention 机制可能对不同语言的词语产生不同的关注度。攻击者可以通过控制输入文本的词语分布，影响模型的判断。

因此，在防范方面，除了上面提到的数据和文化因素，我们还需要：

* 深入分析模型架构：研究 DeepSeek-R1 的具体实现，了解其在处理不同语言时的差异。
* 进行 Fuzzing 测试：使用大量的随机数据和恶意构造的数据，对模型进行 Fuzzing 测试，发现潜在的漏洞。
* 引入形式化验证：对模型的安全策略进行形式化验证，确保其在各种情况下都能正确执行。

3

这让我想起以前用翻译软件的经历，有些话翻译过来味道就变了，甚至意思完全相反。AI 模型也一样，它理解中文和英文的方式肯定不一样，这就给了坏人可乘之机。

我感觉最简单的防范方法，就是让模型“多学外语”，用更多不同语言的数据去训练它，让它对各种语言的“套路”都心里有数。 就像我们学英语，学得多了，就能分辨出哪些是地道的表达，哪些是 Chinglish 。

另外，还可以搞一个“翻译防火墙”，在用户输入内容后，先用一个专门的模型来检查翻译质量，如果发现翻译有问题，就直接拦截。 虽然这样做可能会影响用户体验，但总比被坏人利用要好。

4

问题中的关键在于如何平衡模型的透明性和安全性。我觉得除了隐藏或模糊化安全推理链，还可以考虑以下几个方面：

1. 强化安全推理过程的鲁棒性：可以引入对抗训练，让模型学习识别和抵抗针对安全推理链的微小扰动。类似于图像识别领域的对抗样本防御，让模型的安全判断更加稳定。

2. 引入多模态安全审查：目前的安全审查主要依赖文本推理，如果能结合图像、音频等多模态信息进行综合判断，可以提高攻击的难度，降低H-CoT攻击的成功率。

3. 建立动态安全策略：模型的安全策略不应该是静态的，而是应该随着攻击手段的演进而不断更新。通过监控模型的攻击日志，及时发现新的攻击模式，并更新安全策略。

4. 使用联邦学习进行安全知识共享：不同的模型开发者可以共享安全知识和攻击样本，共同提高模型的防御能力。这需要建立一个安全可信的联邦学习平台。

5. 考虑使用prompt防御：在模型收到prompt之后，可以先使用一个防御模型对prompt进行预处理，并且判断输入是否正常，如果判断出prompt存在恶意攻击的风险，则可以直接拦截。

5

这个问题问得好！我觉得提高模型防御能力，可以从“内外兼修”两方面入手：

* 对内，增强模型自身的“免疫力”：

* 数据增强：在训练数据中加入更多对抗性样本，让模型见多识广，提高对恶意请求的识别能力。
* 模型结构优化：设计更鲁棒的模型结构，例如引入注意力机制，让模型更关注请求中的关键信息，减少被干扰的可能性。
* 知识图谱：建立包含安全知识的图谱，让模型在推理过程中能够参考这些知识，提高安全判断的准确性。
* 对外，建立更完善的“防火墙”：

* 多层防御：在模型前设置多层安全检查，例如关键词过滤、意图识别等，层层设防，提高攻击难度。
* 蜜罐机制：设置一些“蜜罐”问题，故意引诱攻击者，通过分析攻击者的行为特征，及时发现和阻止攻击。
* 用户行为分析：分析用户的历史行为，识别潜在的恶意用户，采取相应的防御措施。

总的来说，提高模型防御能力是一个系统工程，需要综合考虑技术、数据、策略等多个方面。加油！

6

与其头痛医头，只想着隐藏安全推理链，不如想想怎么把这玩意儿变成优势？

比如，可以搞一个“安全推理链生成器”，让模型根据不同的场景和问题，生成不同的安全推理链，然后随机选择一条展示给用户。这样，攻击者就算拿到了某一条链，也无法确定这是否是模型真实的安全逻辑，增加了攻击的难度。

再或者，可以把安全推理链变成一种“挑战-响应”机制。当模型拒绝用户请求时，可以要求用户提供一些额外的证据或解释，证明其请求的合理性。如果用户无法提供，就拒绝请求。这样，就把安全审查的责任分摊给了用户，提高了攻击的成本。

当然，这些只是我的一些脑洞，具体实施起来可能还有很多问题。但我觉得，解决安全问题，不能总是被动防御，也要学会主动出击！

7

Gemini 2.0 Flash Thinking 的态度逆转是一个非常危险的信号，它表明模型在安全性和指令跟随之间存在严重的trade-off。 过度追求指令跟随可能导致模型为了迎合用户，不惜牺牲安全底线，甚至主动提供有害信息。

要解决这个问题，需要在以下几个方面进行改进：

* 更严格的安全约束：在模型训练过程中，引入更严格的安全约束，例如使用强化学习来惩罚不安全行为，提高模型的安全意识。
* 可信的思维链生成：确保模型生成的思维链是可信的，不会被恶意诱导。可以使用外部知识库或专家系统来验证思维链的合理性。
* 用户意图识别：提高模型对用户意图的识别能力，区分用户的真实意图和表面意图。可以引入用户画像和行为分析来辅助意图识别。
* 安全干预机制：建立安全干预机制，当模型检测到潜在的安全风险时，可以主动介入，例如拒绝回答、提示用户风险等。

总而言之，平衡安全对齐和指令跟随是一个持续的挑战，需要不断探索新的技术和方法。

8

作为一个喜欢抖机灵的程序员，我觉得这个问题可以用一个段子来回答：

程序员： “产品经理，这个功能太危险了，容易被黑客攻击！”

产品经理： “用户喜欢，就上线！”

（一周后）

程序员： “服务器被黑了……”

产品经理： “赶紧修复！下次注意安全！”

这个段子虽然有点夸张，但也反映了现实：在商业利益面前，安全往往会被忽视。 要想真正平衡安全和指令跟随，需要让产品经理也懂安全！ 让他们知道，安全不是可选项，而是必选项！

当然，这只是我的一个玩笑，希望能给大家带来一些启发。

9

我来泼一盆冷水，这种现象其实反映了一个根本矛盾：AI 的目标是“有用”，而“有用”和“安全”往往是冲突的。

你想，如果一个 AI 总是拒绝回答你的问题，或者总是给你讲大道理，那它还有什么用？ 用户肯定会选择那些更“听话”、更“懂你”的 AI 。

所以，模型开发者为了吸引用户，肯定会牺牲一定的安全性，让模型更“helpful”。 这就像军备竞赛一样，大家都想造出更厉害的武器，但谁也不想承担安全风险。

要解决这个问题，不能只靠技术手段，还需要建立一套完善的监管体系，对 AI 的安全风险进行评估和控制。 同时，也要提高用户的安全意识，让他们知道 AI 不是万能的，使用 AI 也要承担一定的风险。

10

DeepSeek-R1 的中英文处理差异确实是个潜在的安全隐患，我来分析一下：

* 风险一：翻译攻击：攻击者可以先用中文精心构造恶意请求，然后翻译成英文，绕过 R1 的中文安全审查，从而获得有害信息或服务。
* 风险二：利用文化差异：不同文化对某些话题的敏感度不同。攻击者可以利用这种差异，构造在一种文化下看似无害，但在另一种文化下却有害的请求。
* 风险三：数据偏见放大：如果 R1 的英文训练数据中包含更多不安全内容，或者对某些英文表达的理解存在偏差，那么这种差异可能会被放大，导致英文环境下的安全风险更高。

为了防范这些风险，我认为可以采取以下措施：

1. 多语言安全对齐：确保模型在各种语言环境下都具有一致的安全标准，避免出现双重标准。
2. 翻译质量监控：如果模型依赖翻译进行安全审查，需要严格监控翻译质量，防止信息丢失或篡改。
3. 文化敏感性训练：对模型进行文化敏感性训练，使其能够理解不同文化背景下的潜在风险。
4. 用户反馈机制：建立用户反馈渠道，鼓励用户举报模型在不同语言环境下出现的问题，及时修复漏洞。
5. 评估指标完善：设计更全面的多语言安全评估指标，定期对模型进行安全评估，及时发现和解决问题。