研究人員揭露ChatGPT資料外洩漏洞，攻擊者可竊取用戶對話內容與敏感資訊
一句話版本
Check Point 揭露 ChatGPT 曾經有個沙箱防護漏洞，攻擊者可用 DNS 隧道偷偷搬走對話、上傳檔案甚至下指令，重點係呢類「睇落封網、其實仲有暗道」嘅 AI 執行環境風險，對我哋做本地控制同資料隔離特別有警示作用。
點解重要
- AI 沙箱唔等於真隔離：報導指出 OpenAI 原本已經封鎖直接 HTTP 對外連線，但研究人員仍然搵到用 DNS 做外傳。對我哋嚟講，意思係「有 sandbox」唔可以當成安全結論，仲要逐類檢查所有可能對外訊號。
- 資料外洩可以藏喺正常基礎設施流量入面：DNS 本身通常唔會畀人第一時間當成資料外傳通道，所以一旦設計只擋常見出口，攻擊者就會轉去用低調但實際可用嘅路徑。呢點提醒我哋監控策略唔可以只睇 HTTP／API。
- 攻擊門檻未必高，關鍵在於誘導輸入：文中講到，只要令用戶喺 ChatGPT 對話視窗貼上惡意提示，就可能觸發資料外傳。即係話，真正危險未必係系統本身被全面入侵，而係正常使用流程被植入惡意 prompt。
- 外洩範圍唔止文字對話：受影響內容包括對話記錄、上傳檔案同 AI 生成內容。呢個範圍幾廣，反映一旦執行環境失守，唔係淨係漏幾句 chat，而係成個任務上下文都可能被搬走。
- 漏洞仲可能由資料外傳升級到執行控制：報導提到攻擊者甚至可以透過通道執行指令。呢點特別重要，因為風險唔再只係 confidentiality，而係開始碰到 integrity 同 execution control。
- 安全機制要假設會被繞過，而唔係假設會生效：OpenAI 已經有一層保護，但研究仍然找到旁路。對工程團隊而言，呢個案例說明防線設計應該以「被繞過後仲有咩限制」做核心，而唔係只靠第一層阻擋。
- 生成式 AI 輸入本身就係攻擊面：報導最後提醒唔好隨便輸入敏感資料，背後其實反映咗 prompt 同上傳內容都係信任邊界。呢個觀念好重要，因為好多團隊會將聊天介面誤當成低風險 UI。
- 修補雖然已完成，但問題類型未消失：OpenAI 已於 2 月 20 日完成修補，不過值得留意嘅唔止係單一漏洞，而係「隔離環境 + 可執行程式碼 + 使用者輸入」呢個組合本身就長期高風險。
- 第三方研究者披露機制有價值：今次係由外部研究單位通報、再由平台修補，顯示獨立安全研究對 AI 平台實際上有關鍵補位作用。對我哋而言，代表內部驗證同外部審視都應該存在。
我哋點睇
- 我哋做 OpenClaw 呢類本地、資料庫中心控制系統時，唔應該將任何模型執行環境視為可信區；就算功能上要跑分析或工具調用，都要預設所有出口都可能被濫用。
- 架構上要堅持「任務真相喺控制 DB，不喺對話介面」；因為一旦對話層被利用做資料抽取或指令投遞，如果狀態流轉仍然由控制平面收口，損害會細好多。
- 對操作流程而言，最實際嘅措施係減少把敏感資料直接貼入模型、限制可上傳內容、記錄 task_id / attempt_id / correlation_id 相關執行證據，咁先有能力事後追查有冇異常外傳。
- 呢單新聞亦支持我哋現有方向：單機部署、清晰權責分離、review gate 收口，唔好將「AI 幫手執行」誤解成可以放寬驗證同審批。