AI議事録プラットフォーム「tl;dv」で、ログイン済みの任意ユーザーが全ユーザーの会議記録18万件以上を閲覧でき、進行中の通話にリアルタイムで乱入できる脆弱性が見つかった。研究者が1月に報告したが、6ヶ月経った今も修正されていない。鍵のかかっていない会議室に、誰でも入れる状態だ。

会議室で例えるなら、ドアの鍵が壊れているようなものだ。あなたは自分の鍵が合っていないのだろうと思い込んでいるが、実は受付が合鍵を使っていて、誰でももらえる。ドアを閉じて四半期予算の話をしたり、クライアントを恨んだり、リストラ名簿について話したりしても、ドアの鍵は飾りにすぎない——入りたい人がいれば、ほんの少しノブを回すだけだ。さらに悪いことに、ドアには「この会議室はセキュリティ認証済み」と書かれたプレートが貼ってあり、鍵はドアの前に掛けっぱなしで、誰でも手に取れる。たとえ話はここまでにするが、実際との違いはこうだ：tl;dvの脆弱性は物理的な鍵が壊れたのではなく、データベースのテナント分離が欠如していることにある。ログイン済みの任意のユーザーがライブラリ全体の会議記録を列挙でき、進行中の通話にリアルタイムで乱入することさえ可能だ。
事件

忘れられたコレクション、18万件の会議が無防備に

181,874件の会議記録、84,312人の独立ユーザー、ログイン済みの任意のユーザーが進行中の通話にリアルタイムで乱入できる。6ヶ月経っても、脆弱性はそのまま。

tl;dvはAI議事録プラットフォームで、ボットをGoogle Meet、Zoom、Teamsの通話に入れて、すべてを録音・文字起こし・AI要約を生成する。ユーザー数は200万人超と称し、著名投資家がバックアップし、LinkedInの営業系インフルエンサーの半分が宣伝している。ユーザーはこれを使って営業電話、面接、評価面談、内部戦略会議を録音する——「本通話は録音されます」とアナウンスがあって、みんな気まずく笑ってから45分間 business secrets を話し続ける、ああいう会議だ。

脆弱性は認証フローにあった。ユーザー登録後、プラットフォームはJWTを発行し、gw.tldv.io/v1/users/firebase/tokenでFirebaseトークンと交換する。このトークンでFirestoreデータベースを照会できる。

問題なのは、meetingsコレクションにテナント分離が実装されていないことだ。tl;dvの認証済みユーザーであれば誰でも、プラットフォーム上のすべてのアカウントのすべての会議記録を照会できる。

各記録には作成者のメールアドレス、会議ID（Google MeetやTeamsのルームに直接参加可能なもの）、サービス提供者、録画状態、タイムスタンプが含まれている。

さらに厄介なのがリアルタイム性だ。状態がrecordingの会議は、その会議IDがまさに進行中の通話となっている。攻撃者はこのコレクションをリアルタイムで監視し、会議が録画開始するのを見てIDを奪い、招かれざる客として乱入できる。

どの瞬間でも、コレクションには状態がrecordingの会議が約1,000件眠っている。スクリプトを走らせている攻撃者なら、1,000件すべてに同時に参加できる。

検証はシンプルそのものだった。彼はFirestoreから会議IDを取得し、マレーシア教育省主催のリアルタイムのGoogle Meetに参加した。女性が157人の参加者に向けてプレゼンを行っており、参加者リストにはすでにtl;dvのボットがいた。招待されていない彼も入室していた——Firestoreデータベースからの「招待」だ。彼はまた、アメリカの某トップ大学（.edu）の学生が起業アプリを開発している会議にも参加。21人がオンラインで、プロジェクト全体の画面を共有し、プロトタイプを議論し、.eduメールにクライアント側の検証を追加すべきかと話し合っていた。まさにその場でSupabaseをセットアップしている最中だった。BobDaHackerの願いは「頼むからRLSポリシーを設定してくれ」——ほとんどの人は設定しない。そしてtl;dvと同じ末路を辿る。

規模はどれくらいか？彼はmeetingsコレクションを照会した：181,874件の会議記録、84,312人の独立ユーザー、35,003のメールドメインをカバー。23カ国の政府会議が含まれていた：ブラジル、コロンビア、ペルー、ウクライナ、エルサルバドル、フィリピン、チリ、インドネシア、メキシコ、アメリカ、カタール、マレーシア、ウズベキスタン、スリランカ、ハイチ、南アフリカ、ジャマイカ、ホンジュラス、アルゼンチン、タイ、日本、イスラエル、ベリーズ、すべて.govドメイン。バークレー大学、東京大学、De La Salle大学、コロンビア国立大学など、数十の.eduおよび.acドメインの大学会議。企業会議は残りの35,000ドメインをカバー：三井倉庫（4つの地域オフィス合計484件の会議）、三井不動産、HubSpot、Confluent、Mekari、AnyMind Group。ピーク月は2025年7月で、43,209件の会議。最も忙しい時間帯：水曜日のUTC 14時、7,804件——まさに週次スタンドアップの時間だ。

デフォルトでは会議は非公開で、動画や文字起こしは閲覧できない。しかし彼は27,334件の会議IDを取得して公開状態を確認したところ、1,000件以上が公開されていた。715件の招待者メールが露出し、228のドメインにまたがっていた。

ブラジル政府の保護会議（PACTO Mata Atlântica）もその一つで、参加者はWWF、The Nature Conservancy、Conservation International、WRI、サンパウロ州政府。

ウクライナデジタル変革省の会議も含まれていた。HubSpotの営業通話、コロンビア国立大学、チリのCámara Verdeの会議もだ。

BobDaHackerは1月28日、LinkedInでRaphael Allstadtに連絡し、数分で返信が来た：「ありがとう！CTOに報告してもらえる？すぐ対応するよ」。彼はメールを送った。相手は「ありがとう！」と言った。

彼は報奨金があるかと尋ねた。「うちのCTOが返信するよ」。しかしCTOから返信はなかった。1月29日：「CTOはまだ連絡してこないし、脆弱性も修正されてない」。1月30日、Raphael：「チームがすぐにレビューしてくれると信じてる❤️」。

2月14日：「メール届いてない、脆弱性まだ生きてる」。Raphael：「彼が返信するよ☺️」。2月19日：「対応中。時間はかかるけど、進めてるので安心して」。3月6日：「まだ直ってない」。既読、返信なし。

7月22日：「まだ直ってない……」返信なし。6ヶ月が過ぎ、Firestoreデータベースは相変わらず門戸敞開だ。彼らのセキュリティページにはトロフィーがずらり：SOC2コンプライアンス、GDPRコンプライアンス、EU AI Actコンプライアンス——コンプライアンス証明書が壁一面に並びながら、データベースのドアは一度も施錠されていない。ドアの鍵は最初から壊れていて、施錠という発想自体がない。テナント分離の欠如は構造的なもので、リアルタイム乱入を許す設計だ。

なぜ重要か

18万件の記録、23カ国の政府、一つのログインアカウントで全部見える

tl;dvのデータベースには、前述した日のすべての会議記録が眠っている——登録ユーザー（無料プランでも）は一件ずつ閲覧できる。

数字自体が驚異的だ。23カ国の.govドメイン（ブラジル、ウクライナ、アメリカ、日本、イスラエル、マレーシア、南アフリカ、アルゼンチンなど）が含まれ、政府職員がtl;dvで会議を録画した記録が、ログイン済みの任意のユーザーにライブラリ全体として列挙できる状態で並んでいる。大学も無関係ではない。バークレー大学、東京大学、De La Salle大学、コロンビア国立大学など数十の.edu・.acドメインが含まれ、企業側では三井倉庫だけで4つの地域オフィスで484件の会議が記録され、HubSpot、Confluent、AnyMind Groupの会議メタデータがすべて同じ未分離のコレクションに混在している。

43,209
月間新規会議数（2025年7月がピーク）
漏洩したメタデータ中の会議作成ピーク。出典：研究者が取得したtl;dvデータベースのスナップショット。
7,804
水曜日UTC 14時台の同時会議数
最も忙しい時間帯はまさに週中スタンドアップ——漏洩しているのは企業の日常だ。
27,334
抽查された会議ID
そのうち1,000件以上の動画・文字起こしが公開状態、715件の招待者メールが露出。

会議メタデータは最初の層にすぎない。研究者は27,334件の会議IDを取得して公開状態を確認し、1,000件以上で動画や文字起こしが公開されていた。715件の招待者メールが228のドメインにまたがって露出し、ブラジル政府の環境会議（PACTO Mata Atlântica）の参加者リストにはWWF、The Nature Conservancy、Conservation International、WRI、サンパウロ州政府が名を連ねた。ウクライナデジタル変革省の会議も含まれている。

最も直感に反するのは、これが高度な攻撃ではないことだ。パスワードを破る必要もゼロデイ脆弱性もいらない。tl;dvアカウントを登録し、Firebaseトークンを取得してmeetingsコレクションを照会するだけで、テナント分離がまったく実装されていない。研究者が2026年1月28日に会社へ報告し、7月22日に再度確認しても修正されておらず、CTOは一通もメールを返さなかった。