OpenAI 复盘 3 月 20 日 ChatGPT 停机：开源缓存 Bug 导致数据串号

当你打开 ChatGPT 想接着昨天的思路写代码，左侧边栏却冷不丁冒出了别人的对话标题，甚至点进订阅管理还能看到陌生人的名字和信用卡后四位，这大概是所有用户最不想碰上的噩梦。

OpenAI 针对此前 3 月 20 日的 ChatGPT 突发宕机事故发布了详细的技术调查报告，公开了这起数据泄露的具体细节与底层原因。

根据官方披露，这次事故不仅让部分用户看到了其他活跃用户的聊天记录标题和新建对话首条消息，还波及了真金白银的付费用户。

9 小时窗口与 1.2% 的付费用户

OpenAI 在深入排查后发现，在太平洋时间 3 月 20 日凌晨 1 点到上午 10 点这 9 个小时的窗口期内，约有 1.2% 处于活跃状态的 ChatGPT Plus 订阅用户，其支付相关信息可能被其他人无意间看到。

可能泄露的信息包括用户的名和姓、电子邮件地址、账单地址、信用卡类型、信用卡到期日以及信用卡卡号的后四位。OpenAI 明确表示，完整的信用卡卡号在任何时候都没有发生泄露。

真正看到别人信息的用户数量被认为极低。用户必须在那个特定时间段内恰好做两件事之一：要么打开了系统发错收件人的订阅确认邮件，要么在网页端点击了我的账户里的管理我的订阅。

OpenAI 表示已经主动联系了所有可能受影响的用户，并确认目前用户数据已经没有持续风险。

一个开源库连接池引发的串线

导致这次严重串线事故的根源，并不是模型本身被黑客攻破，而是藏在 Python 开源客户端库 redis-py 里的一个隐蔽缺陷。

OpenAI 的服务器端使用 Redis 缓存用户信息，借此减轻数据库的查询压力。他们通过 Python 的 Asyncio 异步框架，配合 redis-py 客户端来连接 Redis 集群。

在异步模式下，请求和响应像是两组进出队列。正常情况下，客户端把请求塞进队列，取出响应后就把连接放回池子复用。

问题在于，如果在请求进入队列后、响应还没被取出来之前，这个请求被中途取消了，这个连接就会被污染。

下一个完全无关的新请求拿到这个脏连接时，取出的反而是上一条遗留下来的响应数据。如果返回的数据格式刚好对得上，系统就会把它当作合法数据直接送给当前用户。

雪上加霜的是，OpenAI 恰好在 3 月 20 日凌晨 1 点给服务器推了一个更新，意外导致 Redis 请求取消量飙升，从而在极大概率上引爆了这个潜伏的 bug。

OpenAI 随后与 Redis 开源维护者协作修补了该库的代码，并在自家系统里补上了多层校验，确保缓存返回的用户数据与当前发起请求的用户完全一致。

为什么重要

我们认为，这起事故给狂奔中的生成式 AI 行业敲了一记最现实的警钟。许多人一直把注意力放在提示词注入、越狱攻击或者模型幻觉等前沿安全问题上，却往往忽略了最传统的基础设施工程安全。

对于每天把商业计划、未公开代码甚至私人对话输入给 ChatGPT 的用户来说，这次泄露虽然规模受限，但直接动摇了最核心的信任基础。哪怕只露出一句对话标题或账单邮箱，在商业竞争和个人隐私语境下都可能是致命的。

在工程实践上，OpenAI 的复盘显得足够透明，迅速向开源社区贡献修复补丁并增加冗余校验的做法值得认可。但这同样暴露了一个隐患：当超大规模流量涌入一家年轻的 AI 公司时，底层工程架构的任何一次日常改动，都可能在异步高并发的环境下被无限放大。

看起来，各家 AI 巨头接下来的竞争不仅是拼模型参数和推理速度，谁能在传统系统架构、数据隔离与访问控制上守住底线，同样决定了企业级客户敢不敢放心买单。