編按：本文綜合整理自 bobdahacker 原始研究報告、Dark Reading 報導、Netizen 與 HN 討論串，並加入 Siami 編輯部觀點與分析。
事件概述：六個月無人理會的資安炸彈
Google、Zoom、Microsoft Teams 上常見的 AI 會議錄音工具 tl;dv（Too Long; Didn’t View），被獨立研究員 BobDaHacker 揭露其 Firestore 資料庫完全沒有跨租戶隔離，任何登入帳號都能查詢全平台 181,874 場會議資料。這份漏洞報告早在 2026 年 1 月 28 日 就送出，但直到 2026 年 8 月 10 日 原文發布，漏洞仍未修復。
更糟的是，原文直接列出受影響的單位與規模——23 國政府單位、頂尖大學、Salesforce、HubSpot、Confluent、Mitsui Fudosan 等知名企業的會議中繼資料全部暴露。BobDaHacker 甚至在證明漏洞時，親自以「未受邀」身份加入 一場馬來西亞教育部針對 157 名參與者的簡報現場，與已加入的 tl;dv 機器人並列在與會者清單中。
漏洞根因：Firestore 沒設 Tenant Isolation
tl;dv 的後端使用 Google Cloud 的 Firestore 儲存會議資料。當使用者登入後，平台會發一個 Firebase Token 讓前端存取 projects/lmi-store/databases/(default) 這個資料庫。
問題出在 meetings 這個 Collection 完全沒有寫安全規則：
- 任何登入的 tl;dv 帳號都能讀取所有會議紀錄
- 每筆紀錄含：建立者 Email、會議 ID（可加入的 Google Meet / Teams 連結）、錄影狀態、時間戳
- 狀態為
recording的會議 ≈ 即時直播中的會議列表 - 任何時候有約 1,000 場會議正在錄影，等於 1,000 個未上鎖的會議室
研究員測試時實測：只要拿到一筆進行中的會議 ID，就能不請自入。他在兩場進行中的會議「試聽」——一場是馬來西亞教育部線上簡報（157 名與會者），另一場是某美國頂尖大學新創團隊在螢幕分享 Supabase 後台的內部會議（21 人）。
BobDaHacker 在內文寫道：「我心裡一直想大喊『請記得設 RLS 政策』，但這是概念驗證，不是免費資安諮詢。」
受害者規模：23 國政府、大學、企業全中
BobDaHacker 統計了 181,874 筆會議紀錄，涵蓋 84,312 名使用者、35,003 個 Email 域名。具體分佈：
政府單位（23 國）：巴西、哥倫比亞、祕魯、烏克蘭、薩爾瓦多、菲律賓、智利、印尼、墨西哥、美國、卡達、馬來西亞、烏茲別克、斯里蘭卡、海地、南非、牙買加、宏都拉斯、阿根廷、泰國、日本、以色列、貝里斯。全都被命名包含 .gov 域名。
頂尖學府：柏克萊加州大學（UC Berkeley）、東京大學、De La Salle、Universidad Nacional de Colombia，以及數十個 .edu 與 .ac 域名。
企業客戶：三井倉庫（Mitsui-Soko，484 場會議，橫跨四個區域辦公室）、三井不動產、HubSpot、Confluent、Mekari、AnyMind Group 等。
時間熱點：高峰月份為 2025 年 7 月，當月 43,209 場會議。最忙時段是週三下午 2 點 UTC（7,804 場會議）—— 全世界的「週三下午 stand-up」。
研究人員從 27,334 個會議 ID 中另外爬出 1,000+ 場「預設公開」的會議，洩露 715 個受邀者 Email，涵蓋 WWF、The Nature Conservancy、Conservation International、巴西州政府環保會議 PACTO Mata Atlântica、烏克蘭數位轉型部、HubSpot 業務電話、智利綠色商會等。
為什麼這件事重要
這次揭露的嚴重性不只是「資料被外洩」，而是三個層面的結構性問題：
第一，Firestore 預設安全規則不足。Google Cloud 的 Firestore 強調「deny by default」，但開發者必須明確寫 allow 規則。tl;dv 工程師在 users、chats、transcripts、clips、recordings、videos、notes、teams、organizations 等 Collection 都正確寫了 403 隔離，唯獨忘了 meetings。一個 Collection 的疏忽，導致 18 萬場會議（含未來進行中的即時 ID）暴露。
第二，責任揭露流程徹底失敗。研究員 1 月 28 日聯絡對接窗口 Raphael Allstadt，後者承諾會轉給 CTO 處理。六個月內，CTO 從未回信。BobDaHacker 從 2 月到 7 月共發出至少 6 次後續追蹤，全部「已讀不回」。Raphael 自己反而在內部 World Cup 預測遊戲中拿下第 2 名（298 分）和個人 Gmail 也被洩漏。
第三，AI 工作流放大攻擊面。tl;dv 之類的 AI 會議助理歸檔了大量「使用者明確同意錄製」的敏感內容——求職面試、業務談判、政府簡報、績效考核。一旦資料庫被突破，攻擊者不只是拿到通訊錄，而是整個組織的會議脈絡。HN 上有深偽語音釣魚業者留言指出：「買家最常問『攻擊者要去哪裡拿到員工的錄音』，現在答案是『任何 tl;dv 使用者都能爬』。」
tl;dv 官方頁面仍驕傲展示 SOC2、GDPR、EU AI Act、AES-256 等 6 個合規標章。研究員感嘆：「The Firestore database has better uptime than their inbox.」（Firestore 資料庫比他們的收件匣更穩定。）
數據解讀：用「未修補月數」看企業資安體質
這次事件可以拉出兩個值得追蹤的量化指標：
漏洞存在時間：從 2026 年 1 月 28 日首次揭露到 2026 年 8 月 10 日公開報告，整整 6.5 個月。這段時間內，如果有任何攻擊者獨立發現，未來進行中的會議可能都已被側錄。
責任揭露的反應時間：HN 評論指出一個關鍵事實——「漏洞不是被攻擊者利用，是被研究員 6 個月持續『貼著鼻子』提醒，公司依然沒修」。這顯示 tl;dv 內部沒有強制將「外部研究員通報」歸類為 P0 事件的流程。
Firestore 開發的反模式：Cloud Firestore 用文件結構表達租戶隔離時，最常見錯誤就是忘記寫 rules。任何使用 Firestore 的 SaaS 服務，都應該審視自己的 firestore.rules——尤其是 allow read: if request.auth != null; 這種寫法，沒寫 tenant 範圍就是裸奔。
BobDaHacker 其他揭露脈絡：他在過去一年內也揭露過 Pope’s Official App 70 萬使用者 Email 洩漏、Bandsintown 驗證繞過（拿到 Rick Astley 19 萬粉絲的 Email）、Fifa World Cup 2026 直播 RTMP 認證缺失等。共通點：全部是「忘了加最基本的安全規則」。
Siami 觀點：合規標章 ≠ 資安體質
這次最諷刺的，不是漏洞本身，而是 tl;dv 用來招攬客戶的「合規標章」反而成為最大打臉。
SOC2、GDPR、EU AI Act 是「制度面」的認證，它們幾乎從不驗證程式碼層的具體存取規則。一家可以同時擁有 SOC2 報告以及 Firestore 完全沒設安全規則的 Collection。這不是「標章無用」，而是「標章只能證明你通過了當時的審查，無法證明你未來不會寫錯一行設定」。
對企業 IT 採購而言，這次事件有三個立即的行動建議：
- 盤點自己公司使用的第三方 AI 工具，特別是含有「內容錄製 / 螢幕錄製 / 會議筆記」功能的——這些工具拿到的資料比純 API 工具深得多。
- 要求廠商提供 Firestore / 資料庫層的存取規則範本，不要只看合規報告。
- 建立「撤銷協力廠商存取」流程——如果廠商出事，能不能在 24 小時內切斷整合、刪除資料、改金鑰。
對廣大工程師而言，這次事件最值得記得的教訓是：Firestore / Firebase 的預設值偏開發者友善、偏不安全。任何放上 production 的 Collection 都要明確寫 deny-by-default 規則，並對每個 Collection 跑「跨租戶讀取測試」。
原文結尾：「對 tl;dv：你們平台記錄了人們最敏感的對話——求職面試、業務談判、政府簡報。請修 Firestore。請對資安研究人員回信。」
網友熱門留言 (6)