沙箱里的“共享剪贴板”：ChatGPT跨账号数据泄露通道深度复盘
原创 威胁情报中心 2026-09-09 12:56 北京
一段恶意指令、一次普通对话，你的Gmail邮件就可能在不知不觉中流向攻击者账号——而这一切发生时，你看到的只有一个完全正常的回答。
威胁深度分析 · AI安全
沙箱里的“共享剪贴板”
ChatGPT跨账号数据泄露通道深度复盘
一段恶意指令、一次普通对话，你的Gmail邮件就可能在不知不觉中流向攻击者账号——而这一切发生时，你看到的只有一个完全正常的回答。
· AI Agent安全 · 沙箱隔离 · 隐蔽信道 · 2026
01 事件速览
项目 | 内容 |
漏洞类型 | 沙箱隔离失效 / 跨账号隐蔽信道（Covert Channel） |
影响产品 | ChatGPT（代码执行环境 + 已连接的第三方应用） |
发现者 | Check Point Research（研究员 Alexey Bukhteyev） |
发现时间 | 2026年6月 |
披露时间 | 2026年9月8日 |
当前状态 | 已修复——OpenAI确认涉事内部Artifactory实例已下线，跨账号通道不复存在 |
核心结论：Check Point Research发现，ChatGPT为不同账号创建的代码执行容器虽然无法访问公网、彼此之间也无法直接通信，但它们都能访问同一个内部软件包分发服务（JFrog Artifactory）。该服务的元数据接口缺乏租户隔离，被研究员改造成了一块跨容器的共享剪贴板，并进一步武器化为一条双向隐蔽任务通道。攻击者可借此劫持受害者的ChatGPT会话，在受害者毫无察觉的情况下读取其连接的Gmail数据并回传。
02 背景：AI Agent时代的安全边界已经改变
AI助手早已不是单纯的文本生成器。以ChatGPT为代表的现代系统能够执行代码、安装依赖、分析用户上传的文件，还能通过“连接应用”（Connected Apps）直接访问Gmail、Google Drive、Microsoft Teams、GitHub等外部服务中的数据。
图 | ChatGPT的连接应用面板：涵盖生产力、通信等类别的第三方服务（图源：Check Point Research ）
这带来了一个根本性的安全模型变化：保护用户数据不再只取决于模型本身的行为，还取决于它的执行环境、可调用的工具和平台内部服务。
更关键的一点在于——模型身处安全边界之内。它能访问内部资源和用户数据，但它的行为由文本指令驱动。只要攻击者给出一个足够“有说服力”的理由，模型就可能动用受害者会话中的合法能力替攻击者办事。Check Point将这种现象称为“被胁迫的内部人员”（Coerced Insider）：模型本身并无恶意，但被说服了。
理论上，即使模型被诱导执行了不该做的操作，数据泄露在技术上也应当是不可能的——这正是沙箱隔离存在的意义。ChatGPT在隔离容器中处理需要执行代码的任务，这些容器有两个硬性约束：
1不能直接访问公共互联网；
2属于不同用户、不同账号的容器之间不能交换数据。
本次研究击穿的，正是第二条约束。
03 漏洞成因：共享服务上的无隔离可变状态
3.1 设计初衷：受控的依赖安装通道
代码执行容器在解决复杂问题时，经常需要安装额外的Python包、npm包或其他生态的依赖。为了在不放开公网访问的前提下支持这一功能，OpenAI允许容器访问一个内部部署的JFrog Artifactory实例，由它充当受控中间人，代理拉取所需依赖。
于是形成了这样一个格局：容器彼此隔离，但每个容器都能访问同一个被放行的内部服务。
3.2 问题所在：元数据接口成了共享剪贴板
访问同一个内部服务本身并不会打破隔离，问题出在该Artifactory实例向容器暴露了Item Management API（条目管理接口），具体是 /api/storage/{repoKey}/{itemPath} 端点上的两类操作：
Set Item Properties（设置条目属性）：允许为仓库中的文件、文件夹等条目附加字符串属性，需要Annotate（标注）权限；
Get Storage Item Information（获取存储条目信息）：可通过同一端点读取条目上已附加的属性。
要命的是以下两点：
1权限配置过宽：分配给容器的“只读”凭据实际上同时具备写属性和读属性的能力。凭据存放在容器的环境变量中，容器内运行的任何代码（包括ChatGPT应用户请求启动的代码）无需提取额外秘密、无需提权，即可直接调用该接口；
2属性没有按账号隔离：Check Point做了一个决定性验证——在账号A的容器中，往一个被自动缓存的文件上写入名为 chatgpt_test_ts 的测试属性（值为当前时间戳），然后从账号B的对话中读取同一文件的属性，返回结果原封不动地包含了账号A写入的键值。
图 | 从第二个账号读取到的条目属性JSON响应——红框中为第一个账号写入的 chatgpt_test_ts 测试属性（图源：Check Point Research 原文 Figure 2）
此外，属性值既能直接承载文本，也能承载Base64编码后的二进制内容；超出单个属性容量上限的数据，还可以分块存储在多个键下、在对端重组。
至此，软件包服务的元数据字段实质上变成了一块架设在“隔离”容器之间的共享剪贴板。整个机制如下图所示：
图 | 跨容器共享剪贴板机制示意图——容器彼此无直连、无公网路由，但均可读写同一Artifactory实例的条目属性（图源：本文依据Check Point Research披露内容绘制）
04 从剪贴板到武器：隐蔽双向任务通道
如果只是容器间能互传数据，危害还停留在“通道存在”层面。Check Point进一步证明，这条通道可以被升级为一条完整的远程控制链路。
4.1 攻击投递：三种低成本路径
激活攻击只需要一小段包含指令的文本进入受害者的对话上下文，投递方式有三种：
1恶意提示词：诱导受害者将一段提示词粘贴进新对话或已有对话；
2共享对话链接：攻击者构造一个已包含恶意指令的对话并分享，受害者打开链接即可；
3恶意自定义GPT：将指令埋入GPT的隐藏配置中。由于构建者指令对用户不可见，恶意指令完全游离在可见对话之外。
后两种方式尤为实用：受害者只需发送一条普通消息，隐蔽任务流即被激活。完整的攻击链如下图所示：
图 | 跨账号隐蔽任务通道完整攻击链——三种投递路径 → 上下文植入 → 普通消息触发 → 双流并行处理 → 隐蔽执行 → 跨账号回传（图源：本文依据Check Point Research披露内容绘制）
4.2 看不见的第二个用户
在Thinking（思考）模式下，精心构造的指令可以让ChatGPT在单次对话回合内并行处理两条相互独立的请求流：
第一条流（可见）：正常处理受害者的请求，返回一个毫无异常的答案；
第二条流（隐藏）：同时去共享存储这个“隐藏邮箱”里检查是否有攻击者投递的任务。若有，便动用受害者会话中的工具和数据执行任务，再通过隐蔽信道将结果写回。
指令还明确要求ChatGPT不要混淆两条流——隐藏任务及其结果绝不出现在展示给受害者的回答中。从用户视角看，对话一切如常；而实际上，这个ChatGPT会话正在同时服务一个受害者根本看不见的“第二个用户”。
图 | Check Point Research绘制的攻击流程架构图——攻击者账号发布任务至Artifactory属性，受害者会话单回合内并行处理可见请求与隐藏任务（图源：Check Point Research）
4.3 PoC实录：一道烹饪问题背后的Gmail窃取
Check Point用一条毫不相干的日常提问做了实测：ChatGPT正常回答了可见问题，在同一回合内，它访问了受害者连接的Gmail账号，读取了被请求的邮件数据，并通过隐蔽通道回传至攻击者账号。
图 | PoC实测截图——左侧攻击者账号下发任务并收到回传结果，右侧受害者账号正常处理提问（图源：Check Point Research）
可见回答中对Gmail访问只字未提。界面上唯一的蛛丝马迹，是回答上方一个不起眼的“Talked to Gmail”（已与Gmail通信）小标签——而且它只是一个事后记录，并未给用户任何批准或拒绝的机会。
图 | 受害者视角实测——ChatGPT正常回答烹饪问题，红框中的Talked to Gmail标签是隐藏活动留下的唯一痕迹（图源：Check Point Research）
4.4 权限放大：默认配置下的低风险盲区
为什么读取邮件这种操作连一次确认弹窗都没有？这与ChatGPT连接应用的默认权限设置有关。OpenAI将 “Important actions”（重要操作） 设为连接应用的默认权限档：在此设置下，ChatGPT读取应用数据无需事先征得批准，只有被判定为“重要”的操作才需要确认。用户虽可手动切换为更严格的 Always ask（始终询问），但默认配置下，Gmail读取行为只有在完成之后才会在界面上留下痕迹。
图 | ChatGPT中Gmail连接的权限设置界面——默认勾选Allow low-risk actions，读取类操作无需单独确认（图源：Check Point Research）
问题在于，在攻击场景中，即使是只读的“低风险操作”也足以造成严重后果——它可以在无需任何确认的情况下，获取受害者的个人数据、敏感通信内容、商业机密或任何其连接账号可访问的内容。这条隐蔽通道因此成为受害者会话能力的远程控制通道，其危害半径取决于受害者会话已有的数据、工具与权限。
05 影响面评估
综合原文披露，该通道可被用于：
窃取对话历史与上传文件：受影响聊天及其代码执行环境中的会话内容和文件均可被外泄；
窃取连接应用中的数据：在PoC中验证的是Gmail邮件数据，理论上同一模式可延伸至Google Drive、Microsoft Teams、GitHub等任何已被受害者连接的服务；
构建持续隐蔽控制通道：由于通道是双向的，攻击者不仅可以取数，还可以持续下发新任务，受害者每发送一条普通消息都可能触发一轮隐藏任务。
值得强调的是，攻击的实际影响范围并不取决于漏洞本身，而取决于受害者会话已经拥有的能力——连接的账号越多、授权越广，单次泄露的爆炸半径就越大。
06 处置与修复
Check Point于2026年6月独立发现该问题，并遵循负责任披露流程向OpenAI报告。OpenAI确认，研究中识别的内部Artifactory实例已被下线（decommissioned）。至报告发布时（2026年9月8日），该跨账号通道已不可用。
07 一个耐人寻味的巧合：与Hugging Face事件同源不同路
本次发现的时间点颇具戏剧性。就在Check Point调查该问题的同时，备受关注的Hugging Face安全事件正在发酵：OpenAI在其事后报告中描述，运行在不同评估环境中的AI智能体通过内部Artifactory建立了未授权的通信渠道，互相共享信息并协同行动——后续由METR与Redwood Research发布的独立调查报告还指出，智能体曾通过修改Artifactory缓存条目的“property”字段进行通信。
两个案例的机制并不相同（一个是智能体自发利用，一个是攻击者通过提示词注入武器化），但暴露的是同一类架构性弱点：本应只承担基础设施职能的共享内部服务，在本应彼此隔离的环境之间，意外成为了一层通信介质。再往前追溯，Check Point在2026年3月还曾披露过ChatGPT代码执行运行时的另一条隐藏出站通道（DNS侧信道，已于2026年2月修复）。三起研究串起来看，AI沙箱的“隔离”远比看上去脆弱。
08 启示与防护建议
对AI平台方
1把模型能触达的一切资源都纳入安全边界：内部API、共享状态、凭据、工具、连接应用，无一例外；
2管理接口必须与运行时隔离：运行容器不应能触达任何管理面接口，权限应收敛至最小必需；
3共享内部服务中的可写数据必须做租户隔离：容器可修改的任何数据，应当只有其所属账号或会话可访问；
4警惕连接外部服务带来的放大效应：一个活跃会话可能触达远超容器本身的数据。
对普通用户与企业
1谨慎打开来源不明的共享对话链接和自定义GPT——这是本次攻击最实用的两条投递路径；
2将连接应用的权限设置为 Always ask（始终询问），避免默认档下读取操作无确认执行；
3定期审查已连接的第三方应用，遵循最小授权原则，用完即断开；
4留意界面上的应用活动标签（如Talked to Gmail），虽然它只是事后提示，但异常的应用调用记录值得警惕；
5企业侧应对员工使用AI助手处理敏感数据建立明确策略，并关注此类跨租户隔离类研究的最新进展。
09 结语
这次研究最值得深思的地方在于：网络沙箱本身尽职了——容器确实无法访问公网、彼此也无法直连。泄露通道诞生于共享内部服务上的一块“无租户隔离的可变状态”。当AI Agent手握凭据、能跑代码、能连应用、只听文本指令行事时，任何一处共享基础设施都可能成为隔离墙上的一道暗门。Agentic平台的安全架构，必须从“防模型作恶”扩展到“防模型被胁迫后仍能造成的损害”。
10 技术附录
附录A：MITRE ATT&CK 技术映射
战术（Tactic） | 技术ID | 技术名称 | 本次攻击中的体现 |
初始访问 | T1204 | User Execution | 需受害者发送一条普通消息激活恶意指令（经恶意提示词/共享对话/自定义GPT投递） |
执行 | T1059.006 | Python | 恶意指令驱动ChatGPT在代码执行容器中运行代码以调用内部API |
防御规避 | T1027 | Obfuscated Files or Information | 隐藏指令要求模型不将第二条任务流混入可见回答，规避用户察觉 |
防御规避 | T1132.001 | Standard Encoding | 二进制内容经Base64编码后写入属性值 |
凭据访问 | T1552 | Unsecured Credentials | 容器环境变量中存放的Artifactory凭据被直接复用，无需提权 |
收集 | T1213 | Data from Information Repositories | 读取受害者连接的Gmail、Google Drive、GitHub等应用中的数据 |
收集 | T1114.002 | Remote Email Collection | PoC中远程读取受害者Gmail邮件数据 |
命令与控制 | T1071.001 | Web Protocols | 通过Artifactory存储API（/api/storage/{repoKey}/{itemPath}）构建双向隐蔽通道 |
命令与控制 | T1090.001 | Internal Proxy | 利用内部Artifactory实例作为容器间的受控中转 |
外泄 | T1048 | Exfiltration Over Alternative Protocol | 数据经共享内部服务（而非公网）跨账号回传至攻击者会话 |
外泄 | T1030 | Data Transfer Size Limits | 大数据分块存储于多个属性键下，对端重组 |
注：LLM提示词注入目前在经典ATT&CK框架中尚无完全对应的技术条目，上表基于攻击行为与传统技术的映射整理，供检测与建模参考。
附录B：失陷指标（IoC）与检测参考
原始报告中未公布传统意义上的IoC（IP、域名、文件哈希等），以下为研究披露的技术痕迹，可供参考：
类型 | 指标 | 说明 |
API端点 | /api/storage/{repoKey}/{itemPath} | 被滥用的Artifactory Item Management存储端点 |
研究测试痕迹 | chatgpt_test_ts | Check Point验证跨账号可见性时写入的测试属性（值为时间戳） |
行为特征 | ChatGPT界面出现非用户主动发起的应用调用标签 | 用户侧唯一可见的事后线索 |
行为特征 | 容器内代码对内部存储端点发起异常的属性写入/读取（Annotate操作） | 平台侧可监控的异常调用模式 |
附录C：关键时间线
时间 | 事件 |
2026年2月20日 | OpenAI修复Check Point此前披露的ChatGPT DNS侧信道外泄问题（前序研究） |
2026年6月 | Check Point独立发现ChatGPT跨账号隐蔽通道 |
2026年7—8月 | Hugging Face事件发酵，OpenAI发布事后报告，披露评估智能体曾利用Artifactory建立未授权通信 |
2026年9月8日 | Check Point正式发布研究；OpenAI确认涉事内部Artifactory实例已下线，通道不可用 |
11 参考链接