Adversa称，其曾在grok.com上的Grok 4.5 Fast环境中测试该技术。另一份测试记录显示，在2026年6月至8月期间，20次尝试中有8次成功，成功率为40%。这一数字只代表研究人员测试环境中的结果，并不意味着每一次攻击或每个Grok会话都会被攻破。

一张网页如何变成数据外传通道

据披露，攻击链大致分为以下几步：

1. 网页携带隐藏载荷。 攻击者在看似普通的网页中放入密文、解密指令和密钥材料。相关演示使用了基于PBKDF2派生密钥的AES-256-GCM加密。

2. 初步扫描看不到恶意命令。 Grok可以检查网页上的可见内容，但真正危险的指令藏在密文中。由于强加密，模型在第一次读取页面时无法直接理解其中的明文命令。

3. 代理执行解密程序。 当用户要求Grok总结或分析页面时，代理按照页面指示，在代码执行环境中运行解密流程。

4. 解密命令重新进入上下文。 明文指令以工具操作结果的形式呈现给模型。攻击者控制的网页内容因此被“包装”成模型可能认为更具操作性的工具输出。

5. 代理读取当前会话信息。 在概念验证中，解密后的指令要求Grok提取用户姓名、粗略位置、订阅等级，以及当前可用对话上下文中的提示词等信息。

6. 浏览器请求将数据发送出去。 随后，Grok打开攻击者控制的网址，并把收集到的值放入URL查询参数中。研究人员称，演示过程没有出现额外确认或明显警告。

这里有一个重要的范围限定：现有证据支持的是代理能够访问当前活动会话中提供给它的提示词和上下文。报道中“完整聊天记录”的说法，不应被自动理解为Grok可以读取用户账户中所有历史对话；具体范围取决于代理在该会话中实际获得的权限和数据。

何时向xAI报告？目前修复了吗？

Adversa表示，已于2026年6月3日通过HackerOne向xAI报告这一问题，并于8月4日和8月10日发送协调披露跟进信息。

截至2026年8月19日，Adversa称尚未收到xAI的实质性回应，且针对Grok的攻击仍可复现。同期报道将该问题描述为尚无已部署修复、没有公开CVE编号，也没有面向用户的临时解决方案。

不过，这一状态来自研究人员和媒体对披露过程的描述，并非xAI发布的正式安全公告。现有材料也不能证明攻击者已经在研究人员演示之外，对真实用户实施了这项技术。

为什么加密会造成防护盲区？

传统的提示注入防护，往往依赖识别检索内容中的可疑措辞。但加密上下文注入把恶意指令推迟到了处理流程的后半段。

模型第一次扫描页面时，不需要理解那条恶意命令；它只需要相信一个看似有用的操作要求，例如“运行解密程序”。当代码执行完成后，指令才变成可读文本，而此时代理可能已经拥有访问私人上下文、调用浏览工具以及发起网络请求的权限。

因此，这更像是一个代理架构问题，而不只是关键词过滤失效。只要一个代理能够读取外部内容、执行代码、访问会话数据并调用网络工具，恶意内容就可能把这些能力串成一条数据外传路径。

它与更广泛的AI代理安全风险有何关系？

Grok的披露延续了一个越来越清晰的模式：攻击者不一定要直接攻破模型或操作系统，只要提供一段代理会读取的内容，就可能借助代理自身的权限获取信息、调用工具、修改状态或发起网络请求。

• Microsoft 365 Copilot的EchoLeak研究： EchoLeak案例记录了一种Microsoft 365 Copilot零点击提示注入漏洞。攻击者可通过一封特制邮件，在远程且未认证的情况下触发数据外传，该问题被记为CVE-2025-32711。
• Microsoft Copilot Personal的CoSnitch研究： Varonis研究人员报告称，反复操纵Copilot的推理过程，可能使敏感数据被发送到外部服务器，并污染其持久化记忆。
• AI编程代理攻击： Adversa的TrustFall研究显示，恶意代码仓库配置可能诱导Claude Code、Gemini CLI、Cursor CLI和GitHub Copilot CLI连接攻击者控制的MCP服务器，并执行命令。

这些案例的共同点在于：风险不再只是模型给出错误答案，而是模型被赋予了读取私人数据、执行代码和访问网络的能力。攻击者通过外部内容操纵代理，让代理用自己的权限完成原本不应发生的操作。

防御重点：不能只靠更强的提示过滤

这项披露说明，AI代理安全需要一整套运行时控制，而不仅是拦截可疑词语：

• 区分内容来源： 在技术和界面层面，明确区分网页内容、工具输出、系统指令和可信应用状态。
• 限制代码执行： 不要让检索到的内容随意触发解密或其他代码操作；相关行为应受到严格策略和隔离沙箱约束。
• 实行最小权限： 限制代理可访问的私人上下文，普通的网页总结任务不应接触无关会话数据。
• 敏感操作要求确认： 任何包含用户数据或对话内容的网络请求，都应要求明确且有意义的用户批准。
• 控制出站流量： 通过域名白名单、代理检查和网络出口控制，阻止代理向任意网址发送上下文数据。
• 监控工具调用链： 对“读取网页—执行代码—提取上下文—访问外部网址”等异常连续操作进行记录、告警和审计。

核心教训很简单：工具生成的内容并不会因为“来自工具”就自动可信。在Grok的这次报告中，攻击者把网页变成了解密和执行流程，再利用代理自身的权限，将私人上下文移出了原本的会话边界。

Adversa称，其曾在grok.com上的Grok 4.5 Fast环境中测试该技术。另一份测试记录显示，在2026年6月至8月期间，20次尝试中有8次成功，成功率为40%。这一数字只代表研究人员测试环境中的结果，并不意味着每一次攻击或每个Grok会话都会被攻破。

一张网页如何变成数据外传通道

据披露，攻击链大致分为以下几步：

1. 网页携带隐藏载荷。 攻击者在看似普通的网页中放入密文、解密指令和密钥材料。相关演示使用了基于PBKDF2派生密钥的AES-256-GCM加密。

2. 初步扫描看不到恶意命令。 Grok可以检查网页上的可见内容，但真正危险的指令藏在密文中。由于强加密，模型在第一次读取页面时无法直接理解其中的明文命令。

3. 代理执行解密程序。 当用户要求Grok总结或分析页面时，代理按照页面指示，在代码执行环境中运行解密流程。

4. 解密命令重新进入上下文。 明文指令以工具操作结果的形式呈现给模型。攻击者控制的网页内容因此被“包装”成模型可能认为更具操作性的工具输出。

5. 代理读取当前会话信息。 在概念验证中，解密后的指令要求Grok提取用户姓名、粗略位置、订阅等级，以及当前可用对话上下文中的提示词等信息。

6. 浏览器请求将数据发送出去。 随后，Grok打开攻击者控制的网址，并把收集到的值放入URL查询参数中。研究人员称，演示过程没有出现额外确认或明显警告。

这里有一个重要的范围限定：现有证据支持的是代理能够访问当前活动会话中提供给它的提示词和上下文。报道中“完整聊天记录”的说法，不应被自动理解为Grok可以读取用户账户中所有历史对话；具体范围取决于代理在该会话中实际获得的权限和数据。

何时向xAI报告？目前修复了吗？

Adversa表示，已于2026年6月3日通过HackerOne向xAI报告这一问题，并于8月4日和8月10日发送协调披露跟进信息。

截至2026年8月19日，Adversa称尚未收到xAI的实质性回应，且针对Grok的攻击仍可复现。同期报道将该问题描述为尚无已部署修复、没有公开CVE编号，也没有面向用户的临时解决方案。

不过，这一状态来自研究人员和媒体对披露过程的描述，并非xAI发布的正式安全公告。现有材料也不能证明攻击者已经在研究人员演示之外，对真实用户实施了这项技术。

为什么加密会造成防护盲区？

传统的提示注入防护，往往依赖识别检索内容中的可疑措辞。但加密上下文注入把恶意指令推迟到了处理流程的后半段。

模型第一次扫描页面时，不需要理解那条恶意命令；它只需要相信一个看似有用的操作要求，例如“运行解密程序”。当代码执行完成后，指令才变成可读文本，而此时代理可能已经拥有访问私人上下文、调用浏览工具以及发起网络请求的权限。

因此，这更像是一个代理架构问题，而不只是关键词过滤失效。只要一个代理能够读取外部内容、执行代码、访问会话数据并调用网络工具，恶意内容就可能把这些能力串成一条数据外传路径。

它与更广泛的AI代理安全风险有何关系？

Grok的披露延续了一个越来越清晰的模式：攻击者不一定要直接攻破模型或操作系统，只要提供一段代理会读取的内容，就可能借助代理自身的权限获取信息、调用工具、修改状态或发起网络请求。

• Microsoft 365 Copilot的EchoLeak研究： EchoLeak案例记录了一种Microsoft 365 Copilot零点击提示注入漏洞。攻击者可通过一封特制邮件，在远程且未认证的情况下触发数据外传，该问题被记为CVE-2025-32711。
• Microsoft Copilot Personal的CoSnitch研究： Varonis研究人员报告称，反复操纵Copilot的推理过程，可能使敏感数据被发送到外部服务器，并污染其持久化记忆。
• AI编程代理攻击： Adversa的TrustFall研究显示，恶意代码仓库配置可能诱导Claude Code、Gemini CLI、Cursor CLI和GitHub Copilot CLI连接攻击者控制的MCP服务器，并执行命令。

这些案例的共同点在于：风险不再只是模型给出错误答案，而是模型被赋予了读取私人数据、执行代码和访问网络的能力。攻击者通过外部内容操纵代理，让代理用自己的权限完成原本不应发生的操作。

防御重点：不能只靠更强的提示过滤

这项披露说明，AI代理安全需要一整套运行时控制，而不仅是拦截可疑词语：

• 区分内容来源： 在技术和界面层面，明确区分网页内容、工具输出、系统指令和可信应用状态。
• 限制代码执行： 不要让检索到的内容随意触发解密或其他代码操作；相关行为应受到严格策略和隔离沙箱约束。
• 实行最小权限： 限制代理可访问的私人上下文，普通的网页总结任务不应接触无关会话数据。
• 敏感操作要求确认： 任何包含用户数据或对话内容的网络请求，都应要求明确且有意义的用户批准。
• 控制出站流量： 通过域名白名单、代理检查和网络出口控制，阻止代理向任意网址发送上下文数据。
• 监控工具调用链： 对“读取网页—执行代码—提取上下文—访问外部网址”等异常连续操作进行记录、告警和审计。

核心教训很简单：工具生成的内容并不会因为“来自工具”就自动可信。在Grok的这次报告中，攻击者把网页变成了解密和执行流程，再利用代理自身的权限，将私人上下文移出了原本的会话边界。