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 巨頭接下來的競爭不僅是拼模型引數和推理速度，誰能在傳統系統架構、資料隔離與訪問控制上守住底線，同樣決定了企業級客戶敢不敢放心買單。