ChatGPT 資料外洩（2023 年 3 月）
中級3 分鐘閱讀更新於 2026-03-15
分析 2023 年 3 月 ChatGPT 事件，Redis 客戶端函式庫的錯誤導致使用者看見其他使用者的對話標題、部分聊天紀錄與支付資訊。涵蓋根本原因、衝擊與 AI 應用安全的教訓。
2023 年 3 月 20 日，OpenAI 在使用者通報於聊天側邊欄看到其他使用者的對話標題後，暫時將 ChatGPT 下線。調查揭露了更深層的問題：在特定條件下，使用者也可能看到另一使用者的姓名、電子郵件地址、支付地址、信用卡號末四碼與信用卡到期日。根本原因是開源 Redis 客戶端函式庫中的錯誤，而非 AI 模型本身。
事件時間軸
| 日期 | 事件 |
|---|---|
| 2023 年 3 月 20 日（上午） | 使用者開始通報在 ChatGPT 側邊欄看到不熟悉的對話標題 |
| 2023 年 3 月 20 日（下午） | 通報在社群媒體擴散，截圖顯示其他使用者的對話紀錄標題 |
| 2023 年 3 月 20 日（晚上） | OpenAI 將 ChatGPT 下線進行調查 |
| 2023 年 3 月 21 日 | OpenAI 識別出 Redis 客戶端函式庫 redis-py 中的根本原因 |
| 2023 年 3 月 22 日 | OpenAI 在部署修復後將 ChatGPT 重新上線 |
| 2023 年 3 月 24 日 | OpenAI 發表詳細事件報告 |
| 2023 年 3 月 24 日 | OpenAI 揭露大約 1.2% 的 ChatGPT Plus 訂閱者支付資訊也被暴露 |
根本原因分析
直接原因
Redis 客戶端函式庫 redis-py 在連線處理上有錯誤。當請求在連線被放回連線池之後但在收到回應之前被取消時，該連線可能將前一使用者請求中的過期資料回傳給下一個使用該連線的使用者。
技術機制
正常流程：
使用者 A 請求對話清單 → Redis 連線 1 → 回應 A → 使用者 A 看到自己的資料
錯誤流程：
使用者 A 請求對話清單 → Redis 連線 1 → 請求被取消
使用者 B 請求對話清單 → Redis 連線 1（重用） → 過期回應 A → 使用者 B 看到使用者 A 的資料
此競爭條件特別發生在 OpenAI 擴展其 Redis 叢集的高伺服器負載期間。此期間請求取消較頻繁，提高了錯誤觸發的機率。
助長因素
| 層級 | 助長因素 |
|---|---|
| 基礎設施 | 開源相依套件中的 Redis 客戶端函式庫錯誤 |
| 應用 | 快取與回應傳遞之間沒有資料隔離驗證 |
| 架構 | 共用的 Redis 連線池服務多個使用者，且未於每次回應做完整性檢查 |
| 營運 | 在高流量期間進行擴展操作增加了連線重用與取消率 |
| 測試 | 現有測試套件未涵蓋競爭條件 |
不是原因的部分
此事件明確不是由以下原因造成：
- GPT 模型中的漏洞
- 提示詞注入或越獄
- 蓄意的資料蒐集或共享
- 外部攻擊者入侵 OpenAI 系統
衝擊評估
資料暴露
| 資料類型 | 範圍 | 嚴重度 |
|---|---|---|
| 對話標題 | 不明數量的使用者（在側邊欄可見） | 中 -- 標題可能揭露主題但非完整對話 |
| 對話的第一則訊息 | 在錯誤啟動視窗期間的少數使用者 | 高 -- 對話內容可能包含敏感資訊 |
| 支付資訊（姓名、電郵、信用卡末 4 碼、到期日） | 在 9 小時視窗內啟用的 ChatGPT Plus 訂閱者約 1.2% | 嚴重 -- 金融 PII 暴露 |
更廣泛的衝擊
- 使用者信任： 對 ChatGPT 隱私保護的信任顯著削弱。在對話中分享敏感資訊的使用者質疑該資料是否安全。
- 法規關注： 此事件吸引了隱私法規機構的關注，特別是在歐盟，並促成義大利對 ChatGPT 的暫時禁令。
- 產業效應： 提高了對 AI 應用面臨與傳統網路應用相同的基礎設施安全挑戰，再加上對話資料帶來的額外隱私風險的認知。
學到的教訓
對 AI 應用開發者
-
快取隔離至關重要。 快取使用者資料的多租戶 AI 應用必須實施嚴格的快取隔離。每個快取回應在交付前都應對請求使用者的身分進行驗證。
-
對話資料是 PII。 與 AI 系統的聊天對話是敏感個人資料。它們可能包含健康資訊、財務細節、法律問題與個人意見。對待對話儲存應與其他 PII 資料庫同樣嚴謹。
-
相依套件安全很重要。 漏洞位於第三方開源函式庫中，並非在 OpenAI 的程式碼。AI 應用必須稽核其相依套件鏈中的安全問題，尤其是處理使用者資料的元件。
對紅隊
此事件揭示了應納入 AI 應用安全評估的一類測試：
| 測試類別 | 具體測試 |
|---|---|
| 會期隔離 | 一個使用者的會期資料能否透過快取、連線池或共用狀態洩漏到另一使用者？ |
| 錯誤處理 | 當請求被取消、逾時或失敗時會怎樣？錯誤回應是否適當地限定於請求使用者？ |
| 並行存取 | 在高負載下，競爭條件是否會暴露跨使用者資料？ |
| 支付資料隔離 | 支付資訊是否能透過預期支付管理介面以外的任何途徑存取？ |
對部署 AI 的組織
- 假設 AI 對話包含敏感資料。 使用者會與 AI 助理分享機密資訊。資料處理應據此設計。
- 監控資料外洩。 實施異常偵測，識別當使用者收到與其預期設定檔不符的資料時的情況。
- 為 AI 特定事件準備事件回應計畫。 AI 資料外洩具有獨特的特徵（對話內容、模型行為），需要專業化的回應程序。
對紅隊演練的相關性
此事件強調 AI 紅隊演練必須延伸到模型層攻擊之外：
- 基礎設施測試應包括負載下的快取隔離、連線池行為與會期管理
- 多租戶測試應在每一層而非僅應用層驗證使用者資料邊界
- 相依套件稽核應涵蓋 AI 應用相依套件鏈中的所有函式庫，特別注意資料處理元件
- 負載測試應包括安全相關情境：安全特性在高並行下是否仍成立？
相關主題
參考資料
- "March 20 ChatGPT Outage: Here's What Happened" - OpenAI Blog (March 24, 2023) - OpenAI 的官方事件報告
- "ChatGPT Bug Exposed Users' Conversation Histories and Payment Details" - Ars Technica (March 2023) - 對該事件的詳細技術報導
- "Italian Data Protection Authority Bans ChatGPT" - Garante per la protezione dei dati personali (March 2023) - 部分受此事件影響的監管行動
- "redis-py Issue #2624" - GitHub (2023) - Redis 客戶端函式庫中的具體錯誤報告
Knowledge Check
2023 年 3 月 ChatGPT 資料外洩的根本原因為何？