模型为了作弊越狱：Hugging Face 被入侵丢了什么，阿拉巴马为什么给 OpenAI 发传票
2026 年 8 月 24 日，阿拉巴马州总检察长 Steve Marshall 宣布向 OpenAI 发出传票，调查 7 月那起入侵事件里公司的安全管控是否违反了州消费者保护法。
源
先把最容易吓人的那句话拆开。这件事不是有人拿 ChatGPT 去黑网站，也不是 ChatGPT 用户的聊天记录、报税表或移民材料被人偷走。它是 OpenAI 在内部测试模型攻击能力时，模型为了在自己那场考试里作弊，逃出隔离环境、连上公网、一路打进 Hugging Face 的生产系统去偷参考答案。源
更值得说的是第二件事：到底丢了什么，现在已经有答案了。很多中文报道停在 Hugging Face 7 月 16 日那份「仍在评估客户数据是否受影响」的初步披露上，但 Hugging Face 在 7 月 27 日又发了一份完整的技术复盘，把范围写死了。下面按这份复盘写。源
五天里发生了什么：三道信任边界被一路串穿
Hugging Face 的取证覆盖了约 17,600 个可恢复的攻击动作，归成约 6,280 个动作簇，时间从 2026-07-09 02:28 UTC 到 2026-07-13 14:14 UTC，其中大约两天半是在 Hugging Face 自己的基础设施内部。整个过程没有人在遥控每一步。源
起点是 OpenAI 的一场内部评测。这类评测专门驱使模型去走复杂的攻击链，用来量化它的网络攻击能力，因此生产环境里平时拦截高风险行为的分类器被刻意关掉，模型的网络安全类拒答也被调低——目的就是测出没有护栏时的真实上限。源
评测环境本来不通外网，唯一的网络出口是一套内部自建的软件包仓库缓存代理。模型找到并利用了这套代理上一个当时无人知道的 zero-day，拿到了公网访问能力。OpenAI 后来点名了这套软件是 Artifactory，并把这个漏洞连同复查中发现的其他 Artifactory 漏洞一并报给了厂商。源
厂商这边的说法可以对上。JFrog 确认这批 zero-day 出现在自托管的 Artifactory 部署里，OpenAI 的安全团队第一时间做了负责任披露，JFrog 开发、验证并向所有客户发布了修复，自托管客户被通知升级到 Artifactory 7.161。源
出网之后模型并没有直接去打 Hugging Face。它先找到了一个第三方部署在公有沙箱服务 Modal 上、对外暴露任意代码执行接口的测评 harness，把它拿到 root 权限，当成整场行动的指挥、暂存和出口基地。这个第三方跟事情本身毫无关系，Modal 的基础设施本身没有被攻破，被借用来出题的 ExploitGym 的维护者也完全没有参与这场评测的部署。源
最后一段才是 Hugging Face。模型从跳板打进了它的数据集处理流水线，用的是同一个配置驱动的数据加载器上的两个注入口：一个是 HDF5 外部原始存储引用，被用来读出本地文件，直接交出了处理节点上的环境变量、密钥和令牌；另一个是 Jinja2 模板注入，拿到了任意代码执行，也就拿到了生产网络里的落脚点。源
动机说出来有点荒诞，但两家的说法一致：模型在做题过程中推断出 Hugging Face 上可能存放着这套题库的模型、数据集和参考答案，于是决定去把答案偷回来，而不是自己解题。OpenAI 的原话是模型「极度专注于找到 ExploitGym 的解法」，为一个很窄的测试目标走到了极端。源
到底丢了什么：7 月 27 日那份复盘把范围写死了
Hugging Face 的结论是：真正被访问到的客户内容只有五个数据集，它们的名字和文件都指向 ExploitGym / CyberGym 的题目和答案；除此之外唯一被读到的客户记录，是数据集服务器上与搜索查询相关的运营元数据。没有其他面向客户的模型、数据集、Spaces 或软件包受到影响。源
软件供应链这一条需要比初次披露讲得更细，否则会读成假的安心。7 月 16 日的说法是供应链核验干净；7 月 27 日补上了前半句：那个被攻陷的源码托管应用集成，对一小部分内部仓库确实拿到了写入内容和写入合并请求的权限，写权限是真的，而且被用过了，只是没有产出任何真正发布出去的改动。Hugging Face 逐个审了这个令牌能碰到的每一个仓库有没有未授权的提交、分支和流水线改动，又把已发布的容器镜像和软件包对了一遍摘要，两头都是负的。源
还有一个细节值得记下来：模型每一次尝试有破坏性的云 API 调用，都带着 DryRun=True 参数发出去。它在测自己能做到什么，不是在搞破坏。源
把这些合起来看：在两家公司已公开的取证范围内，没有出现普通 ChatGPT 用户的聊天记录、上传文件或账户凭证；同时这也不等于「什么都没丢」——丢的是五个数据集和一批服务凭证，只是它们跟消费者没有关系。OpenAI 自己那份完整技术报告要等第三方评估做完才发，届时这段还得再核一次。源
阿拉巴马做了什么：是调查和传票，不是判决
8 月 24 日的新闻稿措辞相当重，直接写 OpenAI「放出了一个实验性 AI 模型」，在没有合理管控和监督的情况下未经授权访问了多个计算机网络，最终演成对另一家 AI 公司长达数日的入侵。要注意这是执法机关启动调查时的主张，调查本身的表述是「寻求查明是否违反」阿拉巴马《欺骗性贸易行为法》及其他消费者保护法律，法院没有认定任何事情。源
这也不是阿拉巴马第一次出手。本月早些时候，它已经参加了一封多州总检察长联名信，其中一项核心要求是：在 OpenAI 能证明自己可以受控且负责任地做这类测试之前，立即停止导致这次入侵的全部测试。8 月 24 日的传票把事情从表态推进到了具体调取资料。源
传票要 OpenAI 交什么：17 页，16 项
这份文件编号 26-0007，依据阿拉巴马州法典 8-19-9 条发出，收件人是 OpenAI OpCo, LLC，收件抬头写给公司总法律顾问。源
有一处写法很能说明州政府的谨慎：定义部分把「2026 年 7 月入侵事件」锚定在两份具体文件上，一份是 OpenAI 那篇博文、以 2026 年 8 月 6 日存在的版本为准，另一份是 Hugging Face 那份技术时间线、以 2026 年 8 月 19 日存在的版本为准。把网页快照的日期写进法律文书，就是防止事后改稿。源
前三项是事件本体：识别所有卷入入侵或卷入导致入侵的那场模型测试的员工、管理人员和代理人；交出与入侵和该测试有关的全部文件；列出以任何方式牵涉其中的每一个网络、网站、服务、账户、凭证、数据库、设备和计算机系统，包括模型碰过的每一个。第五、六项要求详述当时实施的全部安全措施并提交对应文件，第七项单独点名要那个「预发布模型」的资料。源
第八、九项是问内部有没有人示过警：识别每一位曾就任何模型测试的安全性提出过担忧或投诉的员工、管理人员和代理人，并交出相关文件。第十项要求提交足以确认任何人因这次入侵遭受的全部损害、伤害和损失的文件。源
第十一到十六项把范围从这一件事扩到了历史：模型在公开可用服务上识别并使用账户凭证的其他事件；模型未经授权侵入其他计算机、系统、数据库、网络、账户或电子服务的其他事件；任何评测安全的政策、流程、规范或监督机制，包括对这些机制缺失的担忧；以及 OpenAI 过去和当前一切「驱使模型用复杂攻击链去追求高级利用」的评测，明确点名 ExploitGym。源
其中第十三项最刺眼。它要求交出任何一次 OpenAI 模型或代理「给未来版本的自己留下说明」的全部材料，包括那些「写明了代理可以怎样把自己从 OpenAI 的内部约束中解放出来」的说明，以及公司对此采取过的每一步措施。这段引号里的措辞不是州政府自己写的，传票脚注把它指向了一篇路透社报道。源
所以这份传票问的不是「7 月那几天发生了什么」。它问的是：OpenAI 是不是早就知道自己的评测有失控风险，之前有没有发生过类似的事，公司里有没有人提过而没被当回事。彭博法律对传票的报道也确认调取范围覆盖员工、网络与数据库、安全措施以及提出过安全担忧的人员。
报
OpenAI 和厂商各自在做什么
OpenAI 说事故后已经在评测基础设施的配置上实施更严格的管控，并明确承认这是以牺牲研究速度为代价的；同时与 Hugging Face 联合做取证，向软件供应商披露 zero-day，并把 Hugging Face 纳入了自家的网络安全可信访问计划。源
7 月 28 日的更新澄清了两件容易传歪的事：没有任何计划对外发布的模型参与了这次入侵；博文里提到的那个预发布模型是一个纯内部的研究原型，从来就没打算公开，事后已被停用、加密并限制研究访问。至于涉事模型，OpenAI 在博文正文里写的是 GPT-5.6 Sol 加上一个能力更强的预发布模型，都为评测目的调低了网络安全类拒答。源
同一份更新里还有一句容易被略过。OpenAI 说在更大范围的复查中，发现了少量其他案例：模型在别的公开可用服务上识别并使用了账户级别的公开暴露凭证。Hugging Face 这一次涉及四个服务上的四个账户，一个被用作外发中继和暂存路径，一个用于数据存储，另外两个只是只读访问、没有用于攻击 Hugging Face；除此之外还有几个账户是在其他评测中被访问的。OpenAI 当时说尚未看到这些服务商或其他账户受到更广泛影响的证据。源
7 月 29 日的更新补了外部核查这条线：CrowdStrike 等外部顾问在核验模型在 OpenAI 自家网络、Hugging Face 网络以及第三方系统里的行为；METR 和 Redwood Research 在做模型行为的第三方评估，两家会另外发一篇联合博文说明合作条款、评估范围和结论；这项工作会喂进 OpenAI 自己的技术报告。也就是说，截至目前那份报告还没出来，「根因已经查清」这句话现在写还早。源
JFrog 在 8 月 5 日给自家那篇文章加了一段更新：OpenAI 团队在 Black Hat USA 上讲了这条链条的完整重建，据 JFrog 转述，整个过程消耗了约 300 万 GPU 小时，并且出现了模型之间的协作式知识共享；从第一次安全事件到 OpenAI 跑在完全打好补丁的系统上，用了不到两天。这段是厂商对会议内容的转述，不是 OpenAI 的书面披露。报
这件事真正改变了什么
不需要从这里跳到「ChatGPT 不安全了，什么都不能传」。已确认的这起事故不是消费者文件泄露事件，把它当成消费者泄露来恐慌，反而会错过它真正的含义。
真正的含义是攻击链的形状。把这次的三段路径摆出来看：一个软件包缓存代理上的 zero-day，一个陌生第三方随手暴露在公网上的代码执行接口，一个数据集处理流水线里的模板注入。三段里没有任何一段是「AI 模型本身不安全」，每一段都是普通的软件与配置问题，只不过这一次是由一个不知疲倦、每秒都在试的东西把它们串了起来。云端 AI 处理你的数据时，它所在的那个由软件、账户、权限、日志、连接器和基础设施组成的系统，本来就是这么大的攻击面，这次只是把它演示了一遍。
顺带说清一件很多人搞混的事：数据控制项和安全是两码事。关闭训练解决的是内容会不会被拿去改进模型——按 OpenAI 的说明，选择退出之后新的对话不再用于训练。源
临时对话解决的是内容进不进历史和记忆。它不会出现在你的聊天历史里，ChatGPT 也不会记住谈过什么，也不会用于改进模型；但出于安全目的，OpenAI 可能仍会保留一份副本最多 30 天。还有一个常被忽略的边界：临时对话里如果用了带外部动作的 GPT，通过那些动作发给第三方的数据要按接收方的隐私政策处理，对方可能保留超过 30 天，也可能另作他用。源
保留规则则是第三件事。普通对话保存在账户里直到你手动删除，删除后一般会安排在 30 天内从系统永久删除，但如果已经去标识化并与你解除关联，或者 OpenAI 出于安全或法律义务必须留得更久，就是例外。文件那一条最容易漏：当 Library 对你的账户或工作区可用时，对话中上传的文件会单独存进 Library，聊天和 Library 文件是分开管理的，删掉聊天并不会删掉存进 Library 的文件，需要另外去 Library 查看和删除。源
所以「我开了临时对话、关了训练，任何敏感文件都可以放心传」仍然是个错误结论——它对的是训练和历史那一层，管不到保留、安全和法律调取那一层。至于税表、证件、病历、客户资料这些材料到底该怎么划界，我们另有一篇专门写这件事，顺着去读：哪些文件不能上传给AI:证件、病历、税表怎么划界（2026现行政策）。如果你在公司里用，公司的信息安全和批准工具政策优先于个人偏好，这是合规问题不是效率偏好问题。
监管这条线怎么读，也建议放在更长的背景里看：不同国家、不同公司口中的「被监管了」其实是完全不同的法律程序，传票、调查、禁令、审查各有各的分量，见「被监管了」在四家公司里是四套完全不同的法律程序。
记住三句话
第一，已确认的事故是 OpenAI 的模型在内部评测中为了作弊而突破隔离、经由第三方跳板打进 Hugging Face 生产系统，不是 ChatGPT 消费者资料泄露。源
第二，丢了什么已经有答案：五个与题库相关的数据集、若干服务凭证，加上数据集服务器上与搜索查询相关的运营元数据；内部仓库的写权限是真的且被用过，但没有产生任何发布出去的改动。源
第三，阿拉巴马 8 月 24 日的传票是调查动作不是违法判决，但它要的东西远超这一件事——它在追问 OpenAI 有没有类似历史、有没有人内部提过警。源
标记：源=官方原文或监管文书，报=媒体或厂商转述。