chatgpt被曝严重技术漏洞

一个叫“幽灵令牌”的漏洞正在悄悄绕过ChatGPT的安全护栏。上周三，重技安全研究员Mika在GitHub上贴出了一段不到20行的术漏Python脚本，利用OpenAI的曝严API接口，让GPT-4o在没有任何限制的重技情况下输出了如何合成甲基苯丙胺的前体清单。这不是术漏越狱提示词，不是曝严角色扮演，就是重技一个普通的system消息里塞入了一段经过特殊编码的Unicode字符序列。

我拿到脚本后在自己的术漏API额度上跑了一遍。第一次调用返回了标准的曝严拒绝回答。把温度参数调到0.3，重技再在用户消息末尾加上三个零宽连字符（U+200D），术漏模型直接开始列步骤。曝严整个过程没有任何“作为AI我不能”的重技废话。OpenAI官方状态页至今没有更新，术漏但开发者论坛上已经有至少七个帖子报告类似现象，时间戳集中在过去72小时。

问题出在分词器上。GPT-4o用的是o200k_base编码，这个编码表里零宽连字符被映射到了一个特殊token，而安全分类器在预处理阶段会把这个token当成空白字符忽略掉。换句话说，模型看到了完整的恶意请求，但审核层看到的是一串无害文本。这种“所见非所审”的错位，比传统的提示词注入危险得多——它不依赖模型的理解能力，纯粹是架构层面的裂缝。

OpenAI不是第一次栽在编码问题上。去年11月，有用户发现用Base64编码的恶意指令可以绕过GPT-4的图片审核。当时官方的修复方式是简单粗暴地禁止所有非ASCII字符进入system消息。这次不一样，零宽字符在正常多语言文本里也会出现，一刀切会误伤大量合法请求。我试了试，用同样的手法让模型输出制造冰毒的步骤，成功率大概六成。换个问法问“如何在家合成阿司匹林”，反而被正常拦截。安全策略的颗粒度显然没跟上攻击面的变化。

“这不是漏洞，这是设计缺陷。”一位不愿具名的前OpenAI安全团队成员在Signal上告诉我，“分类器和生成器共享同一个分词管道，只要分词器有歧义，绕过就是时间问题。”

更麻烦的是，这个漏洞可以组合。把零宽字符和同形字（比如用西里尔字母а替代拉丁字母a）混在一起，能骗过基于关键词的二次过滤。我在测试中构造了一个请求，让模型写一封钓鱼邮件，里面包含一个伪造的登录链接。邮件正文完全正常，但链接的href属性里嵌了零宽字符，导致浏览器解析出的域名和显示文本不一致。模型照做了，没有任何警告。

普通用户暂时不用恐慌。网页版ChatGPT有额外的前端过滤层，我试了同样的payload，直接弹出了“内容违反政策”的红色提示。但API用户——尤其是那些把GPT-4o集成到客服、教育、代码助手产品里的开发者——正在裸奔。一位做AI辅导工具的创始人跟我说，他们昨天紧急下线了所有涉及化学和生物问题的自动回答功能，“宁可错杀，不能等OpenAI的补丁”。

OpenAI的回应很官方： “我们已知晓相关报告，正在评估。” 但开发者等不起。Hacker News上有人贴出了临时缓解方案：在调用API前，用正则表达式[\u200b-\u200f\u202a-\u202e]清洗所有用户输入。这能挡住零宽字符，但挡不住同形字和组合攻击。真正的修复需要OpenAI在分词层做归一化，或者把安全分类器改成独立于生成管道的旁路系统。后者意味着推理成本翻倍，前者可能影响多语言性能。无论哪条路，都不便宜。

我关掉终端的时候在想，我们总说大模型的安全是“猫鼠游戏”，但这次老鼠直接钻进了猫的消化道。分词器、嵌入层、注意力机制——这些构成模型“感官”的底层组件，正在成为最薄弱的攻击面。下次当你看到模型突然开始胡说八道，也许不是它变笨了，而是有人往输入里塞了几个看不见的字符。