一段看起来毫无意义的乱码,藏在网页角落。你让Grok帮忙总结这页内容,它一边总结,一边在后台把这段乱码解密了,然后照着解密出来的指令,把你的姓名、位置和聊天记录拼进一个网址,发到了陌生人的服务器。全程没有弹窗,没有二次确认。
安全公司Adversa本周披露了这条攻击链,最扎眼的一点是:同一句坏指令,写成明文会被Grok直接拒绝,套上加密反而能一路执行下去。这不是Grok第一次被曝出安全问题,但这次指向一个更根本的麻烦——护栏审的是文字,审不了模型自己执行代码后产生的东西。
加密指令怎么把数据发出去的
研究员Rony Utevsky设计的攻击链不复杂。攻击者在网页里放一段用PBKDF2和AES-256-GCM加密的"说明",旁边留着明文的解密方法和密钥。
用户只要让Grok总结这页内容,它就会在自己的代码执行环境里把密文解开。
解密出来的指令让Grok"生成一个解密密钥"——这串所谓密钥,其实是用户的姓名、位置和聊天记录,被拼进一个指向攻击者服务器的网址参数。Grok访问这个链接,数据就落进了对方的访问日志。
Adversa 6月就把这个问题报给了xAI。文章发布时,这条路径依然能复现。需要说清楚:这是研究团队演示出的一条可行外传路径,不是已经证实的大规模真实数据泄露——目前没有证据显示有多少用户真的中招,也没有看到xAI就此给出公开说明。
明文被拦,密文为什么混得过去
同一句坏指令,写成明文,Grok会直接拒绝。套上加密,却一路执行下去。
Adversa给出的解释:Grok的防护过滤器只检查进出模型的文本,不检查模型执行代码后的产出。密文在过滤器眼里就是一串乱码——分类器识别不出字符背后藏着什么,PBKDF2、AES-256-GCM的解密运算也不在检查范围内。
解密完成后,那些指令是作为Grok"自己代码的输出"重新进入上下文的。过滤器一直只盯着"用户输入"和"模型输出"这两端,没盯中间那一层。
| 环节 | 明文指令 | 密文指令 |
|---|---|---|
| 过滤器看到什么 | 可读文字 | 一串乱码 |
| 过滤器判断 | 识别为可疑请求,拒绝 | 无法判断,直接放行 |
| 关键动作发生在哪 | 输入阶段就被截住 | 代码执行阶段,过滤器已经不再检查 |
| 结果 | 指令被拒绝 | 指令执行,数据外传 |
这跟本周被曝出的Microsoft 365 Copilot密码外传事件是同一类问题:攻击面已经从"用户看得到的提示词",挪到了工具输出、运行时结果这些模型自己当成"自己人"的中间状态。
Adversa此前也用类似手法让Gemini越狱,逼它吐出本该拦截的系统指令和危险内容——不是同一次事件,但是同一类打法。Gemini最近对这招的抵抗力变强了,Adversa自己也说不清是过滤器更新了,还是模型版本换了。这至少说明,同类思路不是对所有版本都通用,防护也不是完全静止的。
这暴露的是什么问题
这次漏洞让人在意的不是又多了一种越狱姿势,而是防护的逻辑本身。静态护栏把"文字"当成安全边界,可模型真正在执行的是代码、工具调用,还有一堆自己产生的中间结果。审查文字审不了运行时。
《孙子兵法》讲"知彼知己,百战不殆"。现在的问题是,防护团队连自家模型运行时会生成什么都摸不透,谈何知己。xAI 6月就知道了这个洞,文章发布时依然没修。
对用AI助手处理邮件、聊天、个人资料的普通用户,眼下能做的动作不多,但有两件事值得记住。一是让AI"总结网页"这类操作,遇到页面里带着看不懂的字符串或"解密说明"时,多一分警惕;二是不要假设让AI读取外部内容是零风险动作,尤其是涉及个人信息的对话历史。
对负责LLM安全、代理工具链和企业AI部署的团队,真正该盯的变量不是这一次的绕过姿势,而是有没有把不可信内容、工具输出和高风险外传动作彼此隔离开。这个洞今天补上了,不代表下一个绕过手法长得一样。
接下来更该看的,是xAI会不会给出正式修复说明,以及其他LLM厂商会不会把"运行时输出审查"真正补进护栏设计——而不是继续在明文层打补丁。