Fireworks AI、侵害の範囲が広がっていた。請求情報に加え、一部顧客のデータセットと未完成のモデル重みも対象に

まず初めに

AIの基盤屋がやられた、という話自体は珍しくなくなった。だが今回の続報で重いのは、出たものの中に「お客さまの未完成のモデル」が入っている点だ。完成前のモデル重みは、企業の研究開発そのものである。鍵や請求書は取り替えが利くが、学習途中の重みと学習データの組み合わせは、取り替えが利かない。しかも侵入経路は自社ではなく、開発マシンを置いていた先のクラウドだった。「本番は固めた。開発環境は別」という油断が、そのまま裏口になった格好である。

※個人の感想です

何が起きたのか——10月6日の検知から、範囲は2段階で広がった

Fireworks AIは、企業がAIモデルを動かしたり、独自データで調整したりするための基盤を提供する事業者です。

同社は2026年10月6日、社内認証情報の不正使用を検知し、封じ込めを開始しました。10月9日に公表した最初のセキュリティ情報では、当時判明していたのは、評価ジョブなどで使われる保存済みの秘密情報（APIキー等）へのアクセスでした。顧客への通知は10月7日に始まり、同社は10月9日に従業員のAPIキーを入れ替え、10月10日には利用者のキーの失効追加とサービスアカウントのトークン入れ替えを行っています。

ところが調査が進むにつれ、範囲は広がりました。今回の続報（11月9日）で同社は、アカウント情報と請求情報への影響を新たに確認したと公表しました。さらに一部の顧客については、秘密情報、データセット、未完成のモデルも影響を受けた、としています。

もう1つの侵入経路も、今回初めて明らかになりました。同社の研究開発（R&D）用マシンをホストする第三者のクラウド事業者で、10月23日にセキュリティ事案が発生しました。攻撃者は10月24日、その経路を使って同社の開発マシンに到達し、不正な処理（ワークロード）を実行しました。これが追加の顧客データへの影響につながった、というのが同社の説明です。同社はこの活動を同日に検知し、直ちに是正措置を取って、判明している重大な脆弱性を塞ぎました。10月25日以降、顧客が利用する基盤（プラットフォーム）側で、攻撃者による不正アクセスの成功は検知していない、としています。

同社は、この活動の証拠が、金銭目的のサイバー犯罪グループと結び付くとしています。その手口は、正規の権限なく入手した大規模言語モデル（LLM）へのアクセス権を、不正な中継ゲートウェイ経由で転売するもので、「LLMJacking」と呼ばれます。Googleの脅威インテリジェンス部門とMandiantは11月2日、この手口の増加に関する調査を公表しており、Fireworksは続報の中でその調査にも触れています。

アクセスされた情報の範囲

続報によると、影響を受けた社内アプリケーションを通じてアクセス可能だった情報は、次のとおりです。

区分	内容
リソースのメタデータ	Fireworksのリソース識別子、表示名、説明、作成時刻など
請求情報	請求先・配送先の住所、請求書と支払い履歴、アカウント残高、クレジットの利用状況
モデル重みとデータセット	一部の顧客について、未完成のモデル重みとデータセットの一部

クレジットカード番号はFireworksでは保存しておらず、影響はなかった、としています。影響を受けた顧客には、影響の詳細と推奨される対応を知らせる通知を進めています。

一方で同社は、推論（Inference）、Training SDK、Nexusについては影響を検知していない、としています。これらはいずれも、既定でデータを保持しない設計（ゼロデータ保持）だということです。ただし同社は、この判断は現時点までの調査に基づくもので、調査は継続中であり、追加の情報が判明する可能性があるとも明記しています。

同社の対応——認証情報の総入れ替えと、データセット機能の一部停止

同社は法執行機関へ通知し、Palo Alto NetworksのUnit 42にフォレンジック分析の支援を受けています。Unit 42と進めた強化策は、次のとおりです。

• 認証情報とサービスアカウントを失効・入れ替えし、不要な特権を除去、新しい不正な認証情報が作られないよう管理を厳格化した
• 不正なネットワーク経路を制限し、影響を受けたシステムを隔離した
• データ保存と分析システムへのアクセスを見直し、公開状態や不正アクセスを防ぐ管理を徹底した
• ログと監視の仕組みを保全・強化した

利用者側への影響として、Batch Inferenceやデータセットを使う学習で使う、セルフサービスのデータセットのアップロードとダウンロードを、調査の間は無効化しています。Training SDKはデータを保持しない方式で引き続き利用でき、同社のLab環境での学習はネットワークと保存の保護を加えた隔離環境で動く、としています。

初期の公表時点で通知を受けた顧客への案内では、失効したFireworks APIキーの置き換え、特定された第三者の認証情報は発行元での入れ替え、関連するログとデータの確認、見覚えのないキー・利用者・評価ジョブ・学習ジョブ・データセットの点検が求められていました。保存された秘密情報を消すだけでは、その背後にある第三者の認証情報そのものは無効にならない、という点が重要です。

利用者が確認すること

Fireworksを使っている組織が確認すべきは、大きく3つです。

1. 同社からの事案通知が届いているか。影響を受けた顧客には個別に詳細が知らされるため、通知の有無自体が対象判断の材料になります。
2. 評価ジョブや学習の設定に保存した秘密情報（外部サービスのAPIキー等）があれば、Fireworks側の保存を消すだけでなく、発行元で入れ替えたか。過去の案内でも求められた対応です。
3. データセットのアップロード／ダウンロードが無効化されているため、Batch Inferenceやデータセット学習の業務手順に影響が出ていないか。

今回の件は、AIの学習基盤に「学習途中の重み」と「学習データ」という、企業の競争力そのものが集まる時代の侵害です。秘密情報の管理は、Claude Codeの設定ファイルから認証情報が公開される問題のような開発現場の話とも地続きになっています。なお、影響を受けた顧客の数や、対象となったデータセット・重みの具体的な規模は公表されていません。

IT Postの見方

IT Postでは、今回の続報で最も重いのは、範囲の広がり方そのものだと考えます。10月9日の時点では「秘密情報へのアクセス」で、1か月後の続報で「請求情報＋データセット＋未完成の重み」になった。初報の範囲は、その時点で調べた範囲にすぎない——この読み方は、国内の小売の事案でも繰り返し見てきた構図です。基盤の利用者は、ベンダーの初報を「確定した被害範囲」として扱わず、鍵の入れ替えのような先手の対応を、範囲確定を待たずに進める前提で付き合う必要があります。

もう1つは、侵入経路が「開発マシンを置く第三者クラウド」だった点です。本番の顧客基盤は10月25日以降守られた一方、研究開発側の環境が追加の被害の入り口になりました。AIの開発では、実験用の環境にこそ生のデータと重みが置かれがちです。守りの濃淡が本番と開発で開いている組織は、今回の経路を自社の点検項目に足す価値があります。

※個人の感想です

今後どうなりそうか

同社は調査を継続し、必要に応じて追加の更新を出すとしています。次の確認点は、影響を受けた顧客の範囲の確定、データセット機能の再開時期、そして開発環境側の侵入の詳細です。

IT Postでは、続報が公表された場合は本記事を更新します。