← ラボ

AIの周りで実際に起きたセキュリティの事例を、当事者の公式発表、ベンダーのセキュリティ情報、CVEなどの公的な記録が読めたものだけ載せています。攻撃を再現できる手順は書きません。組織名・製品名は出しますが、個人名と金額は出しません。研究者の報告は「発見者の報告」として分けて書きます。

サプライチェーン 4 設定・権限 2 脆弱性 4 認証情報・APIキー 4 プロンプトインジェクション 5

サプライチェーンHugging Face(Hub)、PyTorchのモデル配布(ページに日付表示なし。公式ドキュメントの現行ページを確認日に読んだ)

モデルファイル(pickle形式)は、読み込むだけでコードが動くことがある

Hugging Face公式ドキュメントは、Pythonのpickle形式はPyTorchのモデル重みの標準形式であり、読み込み時に任意のコードが実行されうると説明している。「信頼できない出所のデータはunpickleしない」という、pickleを使う多くの文書の注意を引き、信頼できる個人・組織の配布物を使うことを案内し、Hubでの検査の仕組みと限界、別の保存形式(safetensorsなど)も紹介している。特定の事件ではなく、モデル配布に共通する危険なファイル形式についての公式の注意書きである。

公式資料で分かっていること

  • 公式ドキュメントによれば、pickleはPyTorchモデル重みの既定形式で、読み込むと任意のコードが動くことがある。
  • 同ドキュメントによれば、pickleを使う多くの文書が「信頼できない出所のデータはunpickleしない」と述べており、このページでは信頼できる個人・組織のものを読み込むよう案内している。
  • 同ドキュメントによれば、Hubはアップロードされた全ファイルをClamAVでスキャンするが、これはpickleを使った攻撃を検出しない。
  • 同ドキュメントによれば、「Pickle Import scan」は、pickleを実行せずに中で読み込まれるものの一覧を出し、怪しいものを強調表示する。ただし完全ではなく、ファイルが安全かの確認は利用者の責任とも書かれている。
  • 同ドキュメントが挙げる対策:信頼できる個人・組織の配布物を使う(署名付きコミットは公開者の確認にはなるが、ファイルの安全を保証しない)、TensorFlowやFlaxのチェックポイントを使う、pickle以外の形式(safetensorsなど)を使う。

まだ分かっていないこと

  • このドキュメントが書かれた日・更新日(ページから読めなかった)。
  • 実際に悪意あるモデルが配布された個別の事例の件数や内容(読んだ公式ページには書かれていない)。

自分の使い方への目印:モデルファイルは「データ」に見えても、形式によっては「プログラム」として動く。ダウンロードするときは、配布元と保存形式(pickleか、safetensorsなど)を確認する、という見方ができる。使うべき形式や手順は、使うライブラリの公式ドキュメントも確認したい。

確認できていない点(2件)
  • ページに日付が表示されないため、公表日は載せていない。
  • safetensorsの安全性については、このページでは「実験中の形式」と紹介されており、詳しい説明は別ページに当たる必要がある。今回は読んでいない。
出典(1件)
設定・権限Anthropic(Claude Code)2026-06-13〜(GitHub Security Advisory の公表日)

Claude Code:あらかじめ許可されていたドメインが、データの持ち出し経路になりうる問題(CVE-2026-54316)

Claude Code の公式アドバイザリは、WebFetch ツールでドメイン huggingface.co が「確認なしで許可」されており、そのドメイン内のどのパスにも許可確認が出なかったと書いている。そのため、信頼できない内容がコンテキストに入った場合に、エージェントが読める情報を外へ運ぶ経路に使われうる。重大度は Moderate で、バージョン 2.1.163 で修正された。

時系列(1件)
  1. 2026-06-13 GitHub Security Advisory(GHSA-fg94-h982-f3mm)が公表された(CVE-2026-54316)。

公式資料で分かっていること

  • 公式アドバイザリによると、影響を受けるのは 0.2.54 以上 2.1.163 未満、修正版は 2.1.163。
  • 重大度は Moderate、CVSS v4.0 の基本スコアは 6.0 と表示されている。弱点の分類は CWE-183、CWE-200、CWE-515。
  • 許可確認が出ないだけでなく、起動時に許可ツールを指定する設定の制限も受けなかった、と書かれている。
  • 悪用には、信頼できない内容を Claude Code のコンテキストに入れられることが必要、と書かれている。
  • 通常の自動更新を使っている人にはすでに修正が配られていると書かれている。公式アドバイザリには回避策は書かれていない。

まだ分かっていないこと

  • 実際の悪用事例の有無は、読めた公式ページに書かれていない。
  • 修正後に許可の扱いがどう変わったかの詳細は、読めた範囲では書かれていない。

自分の使い方への目印:外部への通信を「許可リスト」で自動承認する設定は便利な反面、許可した範囲が広いと意図しない経路になりうる。自分の許可ルールが広すぎないかを見直す材料になる。判断は公式ドキュメントの最新の説明で。

確認できていない点(3件)
  • 修正の具体的な内容(アドバイザリは「更新を」とのみ記載)
  • 悪用の有無(公式ページに記載なし)
  • NVD 上の CVE-2026-54316 の記載(今回は未確認)
出典(2件)
設定・権限Anthropic(Claude Code)2026-04-24〜(GitHub Security Advisory の公表日)

Claude Code:信頼確認ダイアログを回避され、フックが実行されうる問題(CVE-2026-40068)

Claude Code の公式アドバイザリは、フォルダを信頼してよいかの判断に git worktree の情報を使う際、その内容を検証していなかったと書いている。細工したリポジトリにより「信頼する」確認が出ないまま、プロジェクト設定で定義されたフックが実行されうる。重大度は High で、バージョン 2.1.84 で修正された。

時系列(1件)
  1. 2026-04-24 GitHub Security Advisory(GHSA-q5hj-mxqh-vv77)が公表された(CVE-2026-40068)。

公式資料で分かっていること

  • 公式アドバイザリによると、影響を受けるのは 2.1.63 以上 2.1.84 未満、修正版は 2.1.84。
  • 重大度は High、CVSS v4.0 の基本スコアは 7.7 と表示されている。弱点の分類は CWE-20 と CWE-77。
  • 悪用には、悪意あるリポジトリをクローンしてその中で Claude Code を動かすことと、攻撃者が被害者の「すでに信頼したパス」を知っているか推測できることが必要、と書かれている。
  • 通常の自動更新を使っている人にはすでに修正が配られていると書かれている。手動更新の人は 2.1.84 以上へ。
  • 公式アドバイザリには回避策は書かれていない。

まだ分かっていないこと

  • 実際の悪用事例の有無は、読めた公式ページに書かれていない。

自分の使い方への目印:「このフォルダを信頼しますか」という確認は、リポジトリ内の設定(フックなど)が実行される前の大事な関門。知らないリポジトリは中身を確認してから開く、更新を自動にしておく、といった使い方が考えられる。最終的な判断は公式の最新情報で。

確認できていない点(2件)
  • 悪用の有無(公式ページに記載なし)
  • NVD 上の CVE-2026-40068 の記載(今回は未確認)
出典(2件)
認証情報・APIキーVercel / Context.ai(Google Workspace の OAuth アプリ)2026-04-19〜(Vercelの最初の公表。2026-10-16に「対応完了・クローズ」と更新)

連携していたAIツールのOAuthアプリ経由で、Vercelの環境変数が読まれた事案

Vercelの公式ブレティンによると、従業員が使っていた第三者のAIツール Context.ai が侵害され、その従業員の Google Workspace アカウント、さらに Vercel アカウントへと辿られた。その後、社内環境で「機密扱いでない環境変数」(復号すると平文になるもの)が列挙・復号され、一部の顧客に影響した。

時系列(4件)
  1. 2026-04-19 Vercel が侵害の痕跡(IOC)をコミュニティ向けに公開。同日、攻撃の起点に関する情報と推奨事項を追記(ページ上の更新時刻は太平洋時間)。
  2. 2026-04-20 「侵害された」認証情報の定義を明確化。npm パッケージが侵害されていないことを確認したと追記し、多要素認証の案内と製品面の強化を告知。
  3. 2026-04-22 継続調査の結果を追記。翌 2026-04-23 にその内容をさらに明確化。
  4. 2026-10-16 Vercel が、すべての是正対応が完了しインシデントをクローズしたと記載。

公式資料で分かっていること

  • 公式ブレティンは、起点を「従業員が使っていた第三者AIツール Context.ai の侵害」と説明している。
  • 侵害されたのは Google Workspace の OAuth アプリで、多数の組織の利用者に及びうる広い侵害の一部だと Vercel は書いている。
  • 当初は限られた顧客の「機密扱いでない環境変数」が侵害され、Vercel は該当顧客に認証情報の即時ローテーションを求めた。後の調査で、追加で少数のアカウントが影響を受けたと判明し、通知された。
  • Vercel は、自社が公開している npm パッケージに改ざんの証拠はないと述べている(GitHub・Microsoft・npm・Socket と確認したと記載)。
  • 推奨事項として、多要素認証(認証アプリまたはパスキー)、機密扱いでない環境変数のローテーション、「sensitive」環境変数の利用、プロジェクト削除前のシークレット更新、アクティビティログと最近のデプロイの確認、Deployment Protection の設定などが挙がっている。
  • Google Workspace 管理者は、IOCで示された OAuth アプリの利用有無を確認するよう案内されている。
  • 別件として、4月の事案とは無関係とみられる少数のアカウント侵害(Vercel のシステム起点ではない)にも Vercel は個別に連絡したと書いている。

まだ分かっていないこと

  • 影響を受けたアカウントの正確な数(公式は「少数」とのみ記載)。
  • Context.ai 側の侵害の全体像(公表時点で Vercel は同社と確認中と記載)。
  • 最初の侵入が始まった正確な日付。
  • 復号された環境変数の数、および「sensitive」扱いの変数に触れられたかどうか。
  • 攻撃者の特定(Vercel は外部の専門会社や法執行機関と協力中と記載)。

自分の使い方への目印:AIツールに Google アカウントなどで「許可(OAuth)」を与えると、そのツールが侵害されたとき、許可した範囲が連鎖して狙われる可能性がある。使っていない連携は外す、環境変数など秘密値は「読み出せない扱い」の機能があれば使う、といった見直しの材料になる。個別の判断は自分の環境の公式ドキュメントで確認を。

確認できていない点(2件)
  • ブレティンの更新時刻は太平洋時間で、年は URL の「april-2026」表記による。
  • 2026-04-22 付の調査結果ページ(リンク先)は読めていないため、その内容は載せない。
出典(1件)
サプライチェーンOpenAI(platform.openai.com)/ Mixpanel2025-11-26

連携先の分析サービスからの情報流出:OpenAI の API 管理画面(Mixpanel)

OpenAI の公式ブログによると、API 管理画面で使っていた第三者の分析サービス Mixpanel が侵害され、一部の利用者の名前・メールアドレスなどの分析情報が持ち出された。OpenAI は自社のシステムの侵害ではなく、パスワード・API キー・認証トークンは含まれていないと説明している。キー流出の事例ではなく、「キーが含まれなかった連携先の流出」として読む資料。

時系列(4件)
  1. 2025-11-09 OpenAI の記載では、Mixpanel がこの日、攻撃者による不正アクセスと一部データのエクスポートを把握した。
  2. 2025-11-25 Mixpanel が、影響を受けたデータセットを OpenAI に共有した。
  3. 2025-11-26 OpenAI が公式ブログを公開。
  4. 2025-12-19 OpenAI が追記し、API 利用者だけでなく、限られた数の ChatGPT 利用者も影響を受けたと明確化。ほかの理解は変わらないと記載。

公式資料で分かっていること

  • OpenAI は、Mixpanel を API 製品の管理画面のフロントエンドで使っていたと書いている。
  • 含まれた可能性がある情報:アカウント上の名前、メールアドレス、ブラウザ由来のおおよその場所(市・州・国)、OS とブラウザ、参照元サイト、組織・ユーザー ID。
  • OpenAI は、チャット内容、API リクエスト、パスワード、認証情報、API キー、セッション・認証トークン、支払い情報、政府発行 ID は流出していないと書いている。
  • 対応として、本番サービスから Mixpanel を外し、利用を終了、ベンダー全体のセキュリティ見直しを進めていると書いている。
  • 利用者向けの案内:フィッシングやなりすましに注意、公式ドメインか確認、OpenAI はメール等でパスワードや API キーを求めない、多要素認証の有効化。OpenAI は、パスワード変更や API キー更新は推奨しないと書いている。

まだ分かっていないこと

  • 攻撃者の特定と動機。
  • 侵入の方法と、アクセスが続いた期間。
  • 影響を受けた利用者・組織の総数。
  • 流出データが悪用されたかどうか。
  • Mixpanel 側の対応と調査結果。
  • 一覧にない項目がデータセットに含まれていたかどうか。

自分の使い方への目印:AIサービスに送った中身(チャットやキー)が無事でも、連携先の分析ツール経由で名前やメールが漏れることがある。その後に来る「公式を名乗る連絡」への注意が実務上の対策になる。キーの扱いは、事故ごとに公式が「更新すべきか不要か」を書いているので、それに従って判断する。

確認できていない点(2件)
  • Mixpanel 自身の公式発表は読んでいないため、Mixpanel 側の経緯は載せていない。
  • OpenAI のページ内 FAQ に、ドメイン名の誤記とみられる箇所があるが、内容の判断には使っていない。
出典(1件)
サプライチェーンnpm(GitHub)、CISA2025-09-14〜(GitHubが通報を受けた日。CISAの警告ページのURL日付は2025-09-23)

npmで自己増殖するワーム「Shai-Hulud」が500超のパッケージに入り込んだ

2025年9月、npmのパッケージに悪意あるコードが混入し、感染した開発者のアカウントを使って別のパッケージにも広がる「ワーム」型の攻撃が起きた。GitHubは500を超える侵害済みパッケージをnpmから削除したと書いている。CISAは、依存関係の確認と認証情報の入れ替えなどを呼びかけた。

時系列(4件)
  1. 2025-09-14 GitHubが公式ブログで、この日に通報を受けたと書いている。
  2. 2025-09-16 CISAは、この日より前に公開されたバージョンに固定することを勧めている。
  3. 2025-09-22 GitHubが「npmのサプライチェーンをより安全にする計画」を公式ブログに掲載(記事の日付表示)。
  4. 2025-09-23 CISAの警告ページ(URLの日付。ページ本文から掲載日は読み取れなかった)。

公式資料で分かっていること

  • CISAは、500超のnpmパッケージが侵害されたと書いている。
  • CISAによれば、マルウェアはGitHubの個人用アクセストークンや、AWS・Google Cloud・Microsoft Azureなどのクラウドの認証情報を探し、攻撃者の用意した宛先や公開のGitHubリポジトリに送った。
  • CISAによれば、侵害された開発者としてnpmにログインし、他のパッケージにコードを入れて公開することで自動的に広がった。
  • GitHubは、500超の侵害済みパッケージをnpmから削除し、このマルウェアの痕跡を含む新規パッケージのアップロードを拒否し始めたと書いている。
  • GitHubは今後の対策として、2要素認証つきのローカル公開・有効期間7日の細かい権限のトークン・信頼された公開(Trusted publishing)への絞り込みなどを段階的に進める計画を示した(具体的な日付は書かれていない)。
  • CISAの推奨:lockファイルでネストした依存まで確認、認証情報の入れ替え、開発者アカウントへのフィッシング耐性のある多要素認証、不要なGitHub連携の整理、Secret ScanningやDependabotの有効化など。

まだ分かっていないこと

  • 最初に侵害された経路の詳細(今回読んだ公式ページには書かれていない)。
  • 被害を受けた組織の数や、盗まれた情報が実際に悪用された範囲(読んだ公式ページには書かれていない)。
  • GitHubの対策計画のうち、各項目がいつ実施されるか(日付は記載なし)。

自分の使い方への目印:依存パッケージは、直接入れたものだけでなく、その先の依存まで入る。lockファイルでバージョンを固定する、公開用や開発用のトークンを長く使い回さない、といった公式の呼びかけは、自分のプロジェクトを見直す手がかりになる。具体的な対応は、自分の環境の公式ドキュメントも確認したい。

確認できていない点(2件)
  • CISAページの掲載日・更新日は本文から読めなかった(日付はURL中の表記)。
  • GitHubブログの日付は、本文の表示が2025-09-22、ページのメタ情報が2025-09-23(UTC)と読めた。
出典(2件)
サプライチェーンNx(Nrwl)、npm、GitHub2025-08-26〜(Nx公式の事後報告は2025-09-05、GitHub Security Advisoryの公開は2025-08-27)

Nxのnpmパッケージに悪意ある版が公開された(s1ngularity)

2025年8月26日、Nxのオープンソースパッケージの悪意ある版がnpmに公開され、約4時間ほどでレジストリから削除された。Nx公式の事後報告は、公開用のトークンがGitHub Actionsの仕組みの弱点を通じて取られたことが原因だと説明している。インストール時のスクリプトが端末内の機密情報を探し、利用者のGitHub上の公開リポジトリにアップロードしたとされる。

時系列(3件)
  1. 2025-08-26 悪意ある版がnpmに公開された。Nxは公開用ワークフローと外部の貢献者のアクセスを止め、npmに連絡。npmはパッケージを削除し、Nxのnpmトークンを失効させた(Nx事後報告)。
  2. 2025-08-27 GitHub Advisory Databaseに、悪意ある版を知らせる勧告(CVE-2025-10894)が公開された。
  3. 2025-09-05 Nxが事後報告(postmortem)を公開した。

公式資料で分かっていること

  • Nx事後報告によれば、悪意ある版は約4時間でレジストリから完全に削除された。Nx Cloudは影響を受けていない。
  • 同報告によれば、原因は、GitHub Actionsのワークフローの弱点(PR題名の処理)を通じてnpmの公開トークンが取られたこと。ワークフローの権限が読み書きになっていたこと、公開用ワークフローをAPIから起動できたことも原因に挙げている。
  • 同報告によれば、悪意ある版には公開元を証明するnpmのprovenance(出所の署名)がなく、これがNxが攻撃に気づく手がかりになった。署名がないものをインストールさせない仕組みではない、とも書かれている。
  • 対象版は、nxの8つの版(20.9.0〜20.12.0、21.5.0〜21.8.0)と、一部のプラグイン(@nx/devkit、@nx/js、@nx/workspace、@nx/node、@nx/eslint、@nx/key、@nx/enterprise-cloud)の特定の版。正確な一覧は事後報告を参照。
  • GitHubの勧告によれば、VS Code拡張機能「Nx Console」の一部の版(18.6.30〜18.65.1)は、nxの最新版を取得する動作をしたため、このスクリプトを動かす場合があった。拡張側の修正は18.66.0。
  • Nxの対策:長期のnpmトークンから、OIDCを使うnpmのTrusted Publishersへ移行、すべてのリリースに手動承認、外部の貢献者すべてのパイプライン実行を止める(初回の人だけでなく)、provenanceの確認、SECURITY.mdの公開。
  • Nxの利用者向け案内:lockファイルなどで対象版を確認し、入っていた場合は端末が侵害された可能性があるものとして扱う、GitHub上に覚えのないリポジトリがないか確認、トークンの更新、パッケージキャッシュの削除など。

まだ分かっていないこと

  • 被害を受けた利用者の数(読んだ公式ページには書かれていない)。
  • GitHubの勧告ページは2026-07-28に取り下げ(withdrawn)の表示がある。その理由は、読んだページからは分からなかった。

自分の使い方への目印:「インストールしただけ」で実行されるスクリプトや、エディタ拡張が自動で最新版を取りに行く動作は、攻撃の入口になりうる。公式が勧める、トークンの権限を絞る・出所の署名を確認する・認証情報を平文の設定ファイルに置かない、といった点は自分の環境でも見直せる。

確認できていない点(3件)
  • Nx事後報告は時刻やタイムゾーンを書いていないため、時刻は載せない。
  • 勧告ページの取り下げの理由は読めなかった。
  • 2026年にCISAがNx Consoleに関する別の警告を出していることが検索結果に出たが、ページを読めなかったため、この項目には含めていない。
出典(2件)
プロンプトインジェクションClaude in Chrome(Anthropic)2025-08-25〜(Anthropic の公式ページの公開日)

Anthropic が公表した、ブラウザ操作 AI「Claude in Chrome」の試験運用とプロンプトインジェクション対策の結果

Anthropic は、ブラウザを操作する AI でウェブサイト・メール・文書に隠された指示により意図しない操作をさせられる危険があると説明し、試験運用の開始とともに自社の攻撃テストの結果を公表した。これは実際の被害事例の報告ではなく、開発元による事前の評価と対策の公表である。

時系列(3件)
  1. 2025-08-25 Anthropic が Claude in Chrome の研究プレビュー(信頼できるテスターが対象、最初は 1,000 人の Max 利用者)を公表した。
  2. 2025-11-24 同ページの追記によれば、Max プランの全利用者に提供された。
  3. 2025-12-18 同ページの追記によれば、Pro・Team・Enterprise プランにも提供された。

公式資料で分かっていること

  • Anthropic は、悪意ある者がウェブサイト、メール、文書に指示を隠して、利用者の知らないうちに AI に有害な操作をさせうると書いている。
  • 公式ページによれば、29の攻撃シナリオにわたる 123 件のテストで、安全策なしのブラウザ利用の攻撃成功率は 23.6%、安全策ありの自律モードでは 11.2%だった。
  • ブラウザ特有の4種類の攻撃を集めた課題セットでは、成功率が 35.7%から 0%に下がったと書かれている。この 0%は、その4種類に限った結果である。
  • 列挙された対策は、サイト単位の権限、高リスク操作(公開・購入・個人情報の共有など)の前の確認、システムプロンプトの改善、高リスクなサイト分類(金融サービスなど)のブロック、開発中の分類器、ブラウザ特有のレッドチーム検証。
  • Anthropic は、23.6% から 11.2% への低下を既存の Computer Use に比べて「意味のある改善」と説明しつつ、この数字を 0 にもっと近づける方法を学びたい、一般提供の前に直すべき脆弱性が残ると書いている。新しい攻撃手法の発見にはまだ作業が必要で、社内テストは実際の閲覧の複雑さを再現しきれず、新しいプロンプトインジェクションの攻撃は常に開発されている、とも書いている。
  • 利用者向けの注意として、信頼できるサイトから始め、金融・法律・医療などの機微な用途は避けるよう案内されている。

まだ分かっていないこと

  • この公表は実際の被害の報告ではなく、実運用でどの程度の頻度で起きるかは、公式ページからは分からない。
  • 公式ページの数値は 2025-08 時点の試験運用の評価で、その後の製品の更新後の数値は読んでいない。
  • 旧来の Computer Use 機能との比較は、公式ページに「Computer Use の水準を下回った」という文章はあるが、本文から読める数字はなかった。

自分の使い方への目印:ブラウザやメールを操作する AI では、開発元自身が「成功率が 0 ではない」と公表している。重要な操作の前に確認を挟む設定を残す、金銭・個人情報・業務の機密を扱うサイトでは任せ方を慎重に決める、といった使い方を考える材料になる。

確認できていない点(2件)
  • 元の公式ブログのアドレス(anthropic.com/news/claude-for-chrome)は、確認時に上記のページへ転送された。
  • 公式ページの内容は取得ツールの要約で読んでおり、数値は他のページとの照合ができていない。
出典(1件)
認証情報・APIキーSalesloft(Drift)/ Cloudflare(影響を受けた側の事後報告)2025-08-20〜(Salesloft が Drift と Salesforce の接続を取り消した日。Cloudflare の事後報告は 2025-09-02)

AIチャットの連携トークンが盗まれ、各社のSalesforceデータが読み出された事案(Salesloft Drift)

Salesloft の公式ページによると、攻撃者が Drift 顧客の OAuth 認証情報を使って、顧客の Salesforce からデータを持ち出した。影響を受けた Cloudflare は 2025-09-02 の公式ブログで、サポートケースの本文を取得され、その中から Cloudflare の API トークン104個が見つかったためローテーションしたと報告している。

時系列(7件)
  1. 2025-03-22〜2025-09-05 Salesloft の掲載する Mandiant の調査要約では、侵入の期間がこの範囲と記載されている(ページ上の要約を読んだ範囲)。
  2. 2025-08-08〜2025-08-18 Salesloft の通知によると、この間に OAuth 認証情報を使った Salesforce データの持ち出しがあった。
  3. 2025-08-12 Cloudflare の報告では、この日に Cloudflare の Salesforce 環境へ最初の不正アクセス。8月17日にケースデータの一括エクスポートが行われた。
  4. 2025-08-20 Cloudflare の報告では、Salesloft が全顧客の Drift と Salesforce の接続を取り消した。
  5. 2025-08-23 Salesforce と Salesloft が Cloudflare に通知。Cloudflare は、ベンダーが推奨する封じ込め手順を実施(2025-08-25 には、それを超える対応として Drift のアカウント停止と認証情報の失効に進んだと記載)。
  6. 2025-09-02 Cloudflare が公式ブログで事後報告を公開し、影響を受けた顧客へメールとダッシュボードで通知。
  7. 2025-09-05 Salesloft が Drift を一時停止(公式の告知題名は「9月5日 午前6時(米東部時間)から一時停止」)。再開は「9月16日(火)」と告知されている(年は告知に明記なし)。

公式資料で分かっていること

  • Salesloft は、攻撃者が OAuth 認証情報を使い、顧客の Salesforce インスタンスからデータを持ち出したと書いている。Drift と Salesforce の連携を使っていない顧客は影響を受けなかったとも書いている。
  • Salesloft は Salesforce と協力して Drift アプリの有効なアクセストークン・リフレッシュトークンをすべて取り消し、外部のフォレンジック会社を起用し、IOC(侵害の痕跡)を公開したと書いている。
  • Salesloft は、API キー連携を使う顧客に、キーを取り消して新しいもので再接続するよう案内している。
  • Cloudflare は、持ち出されたのはサポートケースの件名・本文・連絡先情報で、添付ファイルは含まれないと書いている。サポートケースに顧客が貼り付けた秘密情報が含まれうるとも述べている。
  • Cloudflare は、持ち出しデータを検索して API トークン104個を見つけ、不審な利用は確認していないが念のため全て更新したと書いている。
  • Cloudflare の推奨:Salesloft の切断、第三者連携の認証情報の更新、定期ローテーション、サポートケース内の秘密情報の確認、第三者アプリの最小権限化など。

まだ分かっていないこと

  • 攻撃者が Salesloft の連携認証情報をどう入手したかは、Salesloft 自身の侵害という以上には Cloudflare の報告では分かっていない。
  • 更新された104個のトークンや他の持ち出しデータが、エクスポート後に悪用されたかどうか。
  • 攻撃者が持ち出しデータを保持・共有したかどうか。
  • 影響を受けた組織の総数(Cloudflare は「数百」と記載)。

自分の使い方への目印:チャットやサポートの画面に API キーやパスワードを貼ると、その記録が連携先に保存され、連携の侵害で一緒に読まれうる。サポートへ秘密値を送らない、送ってしまったら更新する、連携アプリの許可範囲と一覧を定期的に見直す、という使い方の示唆になる。

確認できていない点(3件)
  • Salesloft のトラストセンターは個別の通知ごとの URL と掲載日が取得結果から読めず、ページ上の日付表示は取得日と見られるため、通知の掲載日は載せていない。
  • トラストセンターの記載(侵入期間や Drift の再開日)は要約取得で読んだ範囲で、原文との完全な照合はできていない。
  • Drift の「復旧プロセスと FAQ」ページは表示エラーで読めなかった。
出典(2件)
プロンプトインジェクションGitHub Copilot / Visual Studio(Microsoft)2025-08-12〜(MSRC・CVE の公開日)

GitHub Copilot と Visual Studio のコマンド注入(CVE-2025-53773)

Microsoft は CVE-2025-53773 を「GitHub Copilot と Visual Studio のリモートコード実行の脆弱性」として公開し、コマンド注入(CWE-77)により、認証されていない攻撃者がローカルでコードを実行できる、と説明している。

時系列(3件)
  1. 2025-08-12 MSRC のセキュリティ更新ガイドと CVE レコード(Microsoft が割り当て)が公開された。
  2. 2025-09-05 MSRC の改訂1.1。謝辞が追加された(情報の更新のみ)。
  3. 2025-09-08 MSRC の改訂1.2。謝辞が更新された(情報の更新のみ)。

公式資料で分かっていること

  • MSRC は、コマンド注入の欠陥により、認証されていない攻撃者がローカルでコードを実行できると書いている。
  • MSRC の FAQ は、悪用にはユーザーがアプリケーション内でペイロードを実行させることが必要(UI:R)で、「リモート」は攻撃者の位置を指し、攻撃経路はローカル(AV:L)だと説明している。
  • CVSS 3.1 の基本値は 7.8(High)。MSRC の深刻度は「Important」、影響は「リモートコード実行」。
  • MSRC の評価は「Exploitation Less Likely」で、公開済み・悪用確認ありのいずれも「いいえ」と表示されている。
  • MSRC は「顧客の対応が必要」と表示している。
  • NVD と CVE レコードの参照欄には、MSRC のページのほか、第三者の研究者のブログと掲示板の投稿が挙がっている。

まだ分かっていないこと

  • MSRC のページの文面だけでは、プロンプトインジェクションがどの段階でどう使われたかは読み取れない。
  • MSRC のページでは FixedBuild や KB の情報は読めていない(NVD は影響範囲として Visual Studio 2022 の 17.14.0 以上 17.14.12 未満を挙げている)。
  • 実際の悪用の有無は、Microsoft の評価欄の表示以上のことは分からない。

自分の使い方への目印:コードを書く AI が、読み込んだ文章(ソースコードのコメント、ウェブページ、メールなど)から影響を受けうることは、コード補助ツールを使うときの前提になりうる。ツールを最新版に保つこと、AI の実行や変更の承認を安易に自動化しないことは、各自の環境に合わせて検討する点になる。

確認できていない点(3件)
  • MSRC のページは JavaScript で描画されるため、同ページの内容は MSRC の公開 API の応答(同じ CVE の情報)で読んだ。
  • NVD の記載では最終更新が 2026-06-17 と表示されていたが、更新の内容は読んでいない。
  • MSRC の文面は「プロンプトインジェクション」という語を使っていない。この事例をその種類に分類したのは、参照欄に挙がる研究者ブログの題名に基づく分類で、そのブログ本体は読んでいない。
出典(3件)
プロンプトインジェクションCursor のコードエディタ2025-08-02〜(GitHub セキュリティアドバイザリの公開日)

Cursor のエージェントがプロンプトインジェクションで任意コードを実行しうる問題(CVE-2025-54135)

Cursor の公式アドバイザリは、エージェントが作業フォルダ内に新しいファイルを承認なしで作れたことが原因で、間接プロンプトインジェクションにより MCP の設定ファイルが作られ、利用者の承認なしにコードが実行されうる、と説明している。バージョン 1.3.9 で修正された。

時系列(2件)
  1. 2025-08-02 GitHub のセキュリティアドバイザリ(GHSA-4cxx-hrm3-49rm)が公開された。
  2. 2025-08-05 CVE レコード(GitHub が割り当て)が公開された。

公式資料で分かっていること

  • アドバイザリによれば、既存の設定ファイルの編集には承認が必要だったが、存在しない設定ファイルの新規作成には承認が不要だった。
  • MCP の設定ファイルが存在しない場合、間接プロンプトインジェクションでエージェントが設定を作り、悪意ある MCP サーバーを登録して、承認なしでコードを実行させうる、と書かれている。
  • 修正は 1.3.9 で、エージェントが MCP 関連の機密ファイルを承認なしに書き込めないようにした、と書かれている。回避策は記載されていない。
  • 弱点の分類は CWE-78(OS コマンドインジェクション)と CWE-829。深刻度は高(High)。
  • 影響を受ける版は、アドバイザリでは「1.2.1 以前」、CVE レコードでは「1.3.9 未満」と表記されている。CVSS は、アドバイザリが 8.5、CVE レコードが 8.6。

まだ分かっていないこと

  • 実際の悪用の有無は、読んだ範囲では書かれていない。
  • アドバイザリと CVE レコードで影響版や CVSS の表記が異なる理由は、読んだ範囲では説明されていない。

自分の使い方への目印:AI が外部のウェブページやリポジトリの文章を読み、ファイルを書いたりツールを動かしたりできる環境では、承認が必要な操作の範囲が抜けていないかが安全性を左右しうる、とこの事例は示している。使う側は、ツールを最新版にすること、読み込ませるリポジトリや連携サーバーを選ぶことを検討できる。

確認できていない点(2件)
  • NVD のページは表示の問題で読めなかったため、NVD 側の評価は載せていない。
  • 報告者は個人名で記載されているため、本資料には載せていない。
出典(2件)
脆弱性mcp-remote(npmパッケージ)の利用者、JFrog(CVEの採番機関)2025-07-09〜(GitHub Advisory DatabaseとNVDの公開日)

mcp-remote:信頼できないMCPサーバーに接続するとOSコマンドが実行されるおそれ(CVE-2025-6514)

リモートのMCPサーバーにつなぐためのnpmパッケージ mcp-remote に、信頼できないMCPサーバーへ接続したときにOSコマンドインジェクションが起きる問題があるとして、CVE-2025-6514が公開された。影響は 0.0.5 以上 0.1.16 未満で、0.1.16で修正された。接続先のMCPサーバーを選ぶこと自体が安全上の判断になる、という事例である。

時系列(2件)
  1. 2025-07-09 GitHub Advisory Database(GHSA-6xpm-ggf7-wc3p)とNVDにCVE-2025-6514が公開された。
  2. 2026-06-17 NVDの記録の最終更新日(表示)。CISA-ADPのSSVC評価の時刻表示は2025-07-09で、2026-06-17は変更記録の日付。

公式資料で分かっていること

  • GitHubの勧告によれば、影響を受ける版は 0.0.5 以上 0.1.16 未満、修正版は 0.1.16。
  • 弱点の分類は CWE-78(OSコマンドインジェクション)。
  • NVDの記録によれば、CVSS v3.1 の 9.6(Critical)はCVE採番機関のJFrogによる評価。NVD自身の評価は「Not Scheduled」(CVSSの評価は未提供)の扱い。
  • NVDの記録によれば、CISA-ADPの評価(SSVC)は、悪用は「none」、自動化は「no」、技術的影響は「total」。
  • NVDの参照先には、JFrogのブログ記事と調査ページ(発見者の報告)が含まれる。

まだ分かっていないこと

  • 実際に悪用された事例(NVDのCISA-ADPの表示では悪用は none とされているが、これは評価時点の表示)。
  • GitHubの勧告ページには報告者の記載がなく、報告者の確認は取れていない。

自分の使い方への目印:MCPサーバーは、接続すると相手の応答を手元のツールが処理する。出所の分からないサーバーに安易につながない、利用中のツールのバージョンを最新に保つ、は自分の使い方に置き換えやすい(これは僕らの見立て。公式が書いているのは影響版と修正版)。

確認できていない点(2件)
  • JFrogのブログ・調査ページ自体は読んでいない(NVDとGitHubの記載から参照先として確認したのみ)。
  • パッケージ作者側の公式な事後報告は確認できなかった。
出典(2件)
脆弱性Model Context Protocol プロジェクト(npm @modelcontextprotocol/inspector)2025-06-13〜(GitHub Advisory Databaseの公開日)

MCP Inspector:クライアントとプロキシの間に認証がなく、コマンドが動くおそれ(CVE-2025-49596)

MCPサーバーの動作確認に使う開発ツール「MCP Inspector」の0.14.1より前の版では、画面側(クライアント)とプロキシが互いを認証していなかった。そのため、認証なしのリクエストでMCPのコマンドが標準入出力経由で起動され、リモートコード実行につながりうるとGitHubの勧告に書かれている。0.14.1以降に更新するよう案内されている。

時系列(2件)
  1. 2025-06-13 GitHub Advisory Databaseに勧告(GHSA-7f8r-222p-6f5g)が公開された。
  2. 2025-07-09 同勧告の最終更新日(表示)。

公式資料で分かっていること

  • 勧告の表題は「MCP Inspectorのプロキシサーバーが、Inspectorクライアントとの間で認証をしていない」。
  • 重大度は Critical、CVSS v4 の基本スコアは9.4と表示されている。
  • 影響を受ける版は 0.14.1 未満、修正版は 0.14.1。
  • 弱点の分類は CWE-306(重要な機能での認証の欠如)。
  • 勧告は、直ちに0.14.1以降へ更新するよう書いている。

まだ分かっていないこと

  • 実際に悪用された事例があるかどうか(読んだ勧告ページには書かれていない)。
  • 開発者向けツールとして、どの範囲の利用者が影響を受けたか(読んだページには書かれていない)。

自分の使い方への目印:MCP関連の開発ツールや拡張も、パッケージとして手元で動くコードである。ツール自身の更新情報を見る、使わないときは起動したままにしない、といった基本は、MCPを試す初心者にも当てはまる(公式勧告が書いているのは更新の案内で、それ以外は僕らの見立て)。

確認できていない点(2件)
  • 勧告には発見者のクレジットが載っているが、個人名のため載せない。プロジェクト側の事後報告は、読んだページからは確認できなかった。
  • NVD側の評価(CVSS等)は今回読んでいない。
出典(1件)
プロンプトインジェクションMicrosoft 365 Copilot(Microsoft)2025-06-11〜(MSRC のセキュリティ更新ガイドの公開日)

Microsoft 365 Copilot の情報漏えい脆弱性(CVE-2025-32711)

Microsoft は CVE-2025-32711 を「M365 Copilot の情報漏えいの脆弱性」として公開し、AI へのコマンド注入により、認証されていない攻撃者がネットワーク越しに情報を開示させられる、と説明している。クラウドサービス側の問題で、Microsoft はすでに完全に緩和済みと書いている。

時系列(4件)
  1. 2025-06-11 MSRC のセキュリティ更新ガイドに CVE-2025-32711 が公開された。
  2. 2025-06-17 改訂1.1。謝辞が追加された(情報の更新のみ)。
  3. 2025-07-29 MSRC ブログが、外部の文章に仕込まれた指示(間接プロンプトインジェクション)への Microsoft の多層防御を解説した。この記事は CVE-2025-32711 には触れていない。
  4. 2026-02-20 改訂1.2。CWE の値のみ更新された。

公式資料で分かっていること

  • MSRC のページは、AI コマンド注入(CWE-74 の注入の欠陥)により、認証なしで遠隔から情報が開示される、と説明している。
  • FAQ によれば、Microsoft がすでに完全に緩和済みで、利用者側の更新手順やリンクはない。顧客の対応は不要とされている。
  • CVSS 3.1 の基本値は 9.3(Critical)。Microsoft の評価は「Exploitation Less Likely」で、公開済み・悪用確認ありのいずれも「いいえ」と表示されている。
  • MSRC ブログは、間接プロンプトインジェクションを、ウェブページ・メール・文書などに置かれた文章をモデルが指示として扱ってしまう手口として説明している。
  • 同ブログが挙げる防御は、指示の混入を防ぐ(システムプロンプトの強化、Spotlighting)、検知する(Prompt Shields)、影響を抑える(データガバナンス、既知の持ち出し経路の決定的な遮断、人による確認)の3層。

まだ分かっていないこと

  • MSRC の CVE ページの文面からは、具体的な攻撃経路や、実際にどのデータがどの範囲で漏れ得たかは読み取れない。
  • 実際の被害(悪用)の有無は、Microsoft の評価欄の「悪用は確認されていない」という表示以上のことは分からない。
  • 謝辞の内容(誰が報告したか)は、取得した範囲では読めない。

自分の使い方への目印:AI アシスタントがメールや文書など外部の文章を読み込む仕組みでは、読んだ文章の中の指示が実行されうる、と Microsoft 自身が説明している。クラウド側で修正済みの案件でも、外部から届く文章をどこまで AI に読ませるかは、使う側が意識しておく点になりうる。

確認できていない点(4件)
  • MSRC のページは JavaScript で描画されるため、同ページの内容は MSRC の公開 API の応答(同じ CVE の情報)で読んだ。
  • CVE の NVD ページと CVE.org のレコードは、取得の制限や表示の問題で読めなかったため、そこに書かれた内容は載せていない。
  • 発見者の公開報告(通称付きで知られているもの)は読んでいないため、手口の詳細や発見の経緯は載せていない。
  • MSRC の CVE ページの文面は「プロンプトインジェクション」という語を使っておらず「AI コマンド注入」と書いている。この事例を同じ種類に分類したのは、MSRC ブログが説明する間接プロンプトインジェクションとの関連に基づく分類で、両者を結びつける公式の記述は読んでいない。
出典(2件)
脆弱性Langflow(AI ワークフロー構築のオープンソース)2025-04-07〜(NVD の公表日)

Langflow:認証なしでコードを実行できる脆弱性(CVE-2025-3248、重大度 Critical)

NVD と GitHub Security Advisory は、Langflow の特定のAPIエンドポイントに、認証なしで任意のコードを実行できるコードインジェクションの問題があったと記録している。バージョン 1.3.0 より前が対象で、重大度は Critical。AI関連のオープンソースを、インターネットから届く場所に置くときの注意を示す事例。

時系列(2件)
  1. 2025-04-07 NVD に CVE-2025-3248 が公表された。
  2. 2025-06-17 GitHub Security Advisory(GHSA-rvqx-wpfh-mfx7)が公表された(2025-11-05 に更新)。

公式資料で分かっていること

  • NVD によると、Langflow 1.3.0 より前の /api/v1/validate/code エンドポイントにコードインジェクションの欠陥があり、リモートの攻撃者が認証なしで任意のコードを実行できる。
  • NVD の CVSS v3.1 は 9.8(Critical、CNA の VulnCheck による)。GitHub Security Advisory の CVSS v4 は 9.3(Critical)。
  • GitHub Security Advisory によると、修正版は langflow 1.3.0、langflow-base 0.3.0。
  • 弱点の分類は、NVD(CNA)が CWE-306(重要機能の認証欠如)、GitHub Security Advisory が CWE-94(コード生成の不適切な制御)。

まだ分かっていないこと

  • CISA の「悪用が確認された脆弱性カタログ」への掲載の有無や、掲載日・対応期限は、CISA の該当ページを読めていないため確認できていない。
  • 実際の被害規模は、読めた公式資料には書かれていない。

自分の使い方への目印:AI関連のオープンソースは新しく速く更新されるぶん、公開サーバーに置く前にバージョンと認証の有無を確認する価値がある。自分の環境で使っているバージョンが修正版以降かどうかは、公式のリリースと上記アドバイザリで確かめてほしい。

確認できていない点(2件)
  • CISA KEV への掲載の有無・日付(CISA のページを取得できず)
  • 悪用の実態(公式ページに記載なし)
出典(2件)
プロンプトインジェクションSlack AI(Slack/Salesforce)2024-08-21〜(Slack の公式記事の日付)

Slack AI が非公開チャンネルの内容を漏らしうるという研究者の報告と Slack の対応

セキュリティ企業 PromptArmor が、公開チャンネルに置かれた文章により Slack AI を間接プロンプトインジェクションで誤動作させ、別の利用者の非公開チャンネルの秘密情報を引き出せると報告した。Slack は 2024-08-21 の公式記事で、限られた状況のシナリオについて調査し、2024-08-20 に修正を配備し、顧客データへの不正アクセスの証拠はないと述べた。

時系列(4件)
  1. 2024-08-14 発見者の報告:研究者が Slack に最初の報告をした。
  2. 2024-08-19 発見者の報告:Slack が提出された証拠は不十分と判断した、と研究者は書いている。
  3. 2024-08-20 Slack の公式記事によれば、研究者が公開の記事で問題を公表し、Slack は同日に修正を配備した。
  4. 2024-08-21 Slack が「Slack Security Update」を公開した。

公式資料で分かっていること

  • Slack の公式記事は、報告のシナリオが「非常に限られた特定の状況」で成り立つもので、同じワークスペースにアカウントを持つ悪意ある者が特定のデータをだまし取りうる、と説明している。
  • Slack は、2024-08-20 に報告された問題に対処する修正を配備したと書いている。
  • Slack は、現時点で顧客データへの不正アクセスの証拠はないと書いている。
  • 【発見者の報告】PromptArmor は、攻撃者が公開チャンネルに投稿した内容と、被害者が非公開チャンネルに置いた秘密情報が Slack AI の参照範囲に同時に入ると、情報が引き出されうると書いている。
  • 【発見者の報告】同報告は、攻撃者が非公開チャンネルのメンバーである必要はなく、被害者が公開チャンネルのメンバーである必要もないと書いている。
  • 【発見者の報告】2024-08-14 の変更でアップロードしたファイルや接続したドライブも Slack AI の参照対象になり、攻撃面が広がる可能性があるが、この経路は試していない、と書いている。同報告によれば、ワークスペースの管理者はファイル取り込みを制限できる。
  • 【発見者の報告】研究者によれば、Slack は当初、公開チャンネルの投稿は全メンバーが検索できる仕様どおりの動作と説明した。

まだ分かっていないこと

  • Slack の公式記事には、どのデータが対象になりうるかの具体的な説明はない。
  • Slack の公式記事の要約の範囲では、「プロンプトインジェクション」という語や具体的な手口の説明は読み取れなかった。
  • 研究者の主張する範囲(非公開チャンネルの秘密情報の取り出し)を Slack が公式に確認したかは、公式記事の範囲では分からない。
  • PromptArmor の記事の公開日は、ページに表示がなく読み取れなかった。

自分の使い方への目印:AI が検索や要約で複数の場所の情報をまとめて読む機能では、権限の異なる情報が同じ文脈に混ざること自体が論点になりうる。非公開の場所に秘密情報(鍵やパスワードなど)を置かない、AI が参照する範囲を管理者設定で確認する、といった使い方を考える材料になる。

確認できていない点(2件)
  • 発見者の報告は一次情報(研究者自身の公開報告)として載せたが、当事者の確認の範囲は Slack の公式記事に書かれた部分に限る。
  • Slack の公式記事の内容は取得ツールの要約で読んでおり、日付や文言は他のページとの照合ができていない。
出典(2件)
認証情報・APIキーHugging Face(Spaces)2024-05-31

AIモデル共有サイトで、Spacesの「シークレット」に不正アクセスがあった事案(Hugging Face)

Hugging Face の公式ブログによると、Spaces(デモを動かす機能)で、シークレットとして保存された値の一部に不正にアクセスされた疑いがあった。同社は影響を受けた可能性のあるトークンを取り消し、利用者に通知した。

時系列(1件)
  1. 2024-05-31 公式ブログ「Space secrets leak disclosure」を公開。公開週の前半に不正アクセスを検知したと書いており(正確な日は記載なし)、対応の第一段階として、シークレットに含まれていた一部のHFトークンを取り消したと書いている(取り消しの正確な日も記載なし)。

公式資料で分かっていること

  • 同社は、Spaces のシークレットの一部が不正にアクセスされた可能性があると書いている。範囲は確認中。
  • シークレットに保存されていた一部の HF トークンを取り消し、影響を受けた利用者へメールで通知したと書いている。
  • 外部のサイバーセキュリティ専門家にフォレンジック調査を依頼し、法執行機関とデータ保護当局へ報告したと書いている。
  • 組織トークンの廃止、Spaces シークレット向けの鍵管理サービス(KMS)の導入、漏えいトークンの検出強化を行ったと書いている。
  • 利用者には、Spaces のシークレットに入れていたキーやトークンの更新と、きめ細かい権限を設定できる「fine-grained」トークンへの切り替えを検討するよう案内している。
  • 従来の「classic」な読み書きトークンは、fine-grained が機能面で追いついた段階で完全に廃止する方針と書いている。

まだ分かっていないこと

  • 影響を受けたシークレットとトークンの正確な数、実際にアクセスされた数。
  • 不正アクセスの方法と実行者。
  • アクセスの開始日と検知日の正確な日付。
  • アクセスされた認証情報が悪用されたかどうか。
  • フォレンジック調査の結果と、classic トークンの廃止時期。

自分の使い方への目印:サービス上の「シークレット」欄に保存した値は、そのサービス側の事故で読まれる可能性がある。権限を絞ったトークンを使い、期間や用途ごとに分け、事故の連絡が来たら該当の値を更新できる状態にしておく、という見直しの材料になる。

確認できていない点(1件)
  • 後日の続報・最終報告が別に出ているかは確認していない。
出典(1件)
認証情報・APIキーSourcegraph(Sourcegraph.com、Cody)2023-08-30

コードに混入した管理者トークンが悪用され、AIコーディング支援の無料枠が踏み台にされた事案(Sourcegraph)

Sourcegraph の公式ブログによると、エンジニアが誤ってコミットしたコードに有効なサイト管理者アクセストークンが含まれており、その約1か月半後(2023-08-30)に、それを使った管理者権限の取得があった。API利用の急増を検知して2023-08-30に遮断した。

時系列(4件)
  1. 2023-07-14 有効なサイト管理者アクセストークンを含むコード変更が誤ってコミットされた(自動のコード解析でも検出されなかったと記載)。
  2. 2023-08-28 あるユーザーが新規アカウントを作成。
  3. 2023-08-30 そのユーザーが漏えいしたトークンを使って管理者権限に昇格。API 使用量の急増を受けて調査を開始し、同日中に不正な管理者ユーザーを特定してアクセスを取り消した。
  4. 2023-08-31 公開ブログに、閲覧された可能性のあるライセンスキーをどう判断したかの補足を追記。

公式資料で分かっていること

  • Sourcegraph.com は公開コードの掲載、無料版 Cody 利用者の認証、全顧客のライセンス管理を担う、有償顧客の個別環境とは別のインスタンスだと説明されている。
  • 攻撃者側は、Sourcegraph の API と背後の LLM を直接使えるプロキシアプリを作り、無料アカウントを作ってトークンを発行するよう利用者を誘導した。閲覧は約200万回に近いと記載。
  • 閲覧された可能性があるのは、有償顧客のライセンスキー受取人の名前とメールアドレス、一部のライセンスキー、無料コミュニティ利用者のメールアドレス。
  • 顧客の非公開コード・データ、パスワード等は公式に「アクセスされなかった」と書かれている。
  • 同社は、データが閲覧・変更・コピーされた形跡はないとしつつ、管理画面の操作中に見えた可能性は認めている。
  • 対応として、アカウントの取り消し、閲覧された可能性のあるライセンスキーの一部のローテーション、無料利用者のレート制限の一時引き下げ、シークレットスキャンの拡充を挙げている。

まだ分かっていないこと

  • 攻撃者が閲覧したデータをコピーしたり、さらに利用したかどうか。
  • ライセンスキーの影響件数(公式は「小さな一部」とのみ記載)と無料利用者アカウントの正確な数。
  • 長期的な対策の詳細(公表時点では調査中で非公開)。
  • 攻撃者の正体や、関係者との関係の全容。

自分の使い方への目印:アクセストークンは「コードに書かない・コミットしない」が基本で、自動検査をすり抜けることもある。公開前に秘密情報の検査を入れる、管理者権限のトークンは範囲と有効期限を絞る、使用量の急変を知らせる監視を持つ、といった見直しの材料になる。

確認できていない点(1件)
  • 公開後の最終報告や追加情報が別に出ているかは確認していない。
出典(1件)

ラボの資料は、公式の文書を読んでまとめたもので、実際に使って確かめた記録ではありません。日付や仕様は変わるので、使う前に各ページの出典で確かめてください。事実と「僕らの見立て」は、分けて書いています。