自社が使う生成AI基盤にも「サプライチェーンの脆弱性」がある——そんな実態を大規模に可視化した研究が公開されました。LLM（大規模言語モデル）を支えるOSSフレームワークやツールに潜む脆弱性を横断分析したもので、公開状態のLLMサービスのうち45.6%が、少なくとも1件のリモート悪用可能な脆弱性の影響下にあったと報告しています。AIの内製・PoCが増えた今、情シスにとって他人事ではありません。
本記事は arXiv 掲載の実証研究「Demystifying LLM Supply Chain Vulnerabilities in the Wild」（ソフトウェア工学の国際会議 Internetware 2026 に採録）を、実務者向けに噛み砕いて解説します。個別の論文の主張であり、環境や対象の取り方で数値は変わりうる点は割り引いて読んでください。
- LLM基盤の脆弱性は「AI特有」より「従来型」が圧倒的多数だという実態
- 被害が集中しているOSS（Ollama・Open-WebUI・Dify）と、その理由
- 情シスがまず確認すべき「公開状態のAIサービス」の棚卸しの勘所
どんな研究か（1文でいうと）
LLMの開発・運用に使われる77リポジトリ・529件の実際の脆弱性（CVE）と、インターネットに公開された63,243件のLLMサービスを突き合わせ、「どんな脆弱性が、どこに、どれだけ広がっているか」を実証的に測った研究です。ライフサイクルを12段階に分けて分布を整理しています。
何がわかったのか：脆弱性の8割は「従来型」
まず情シスにとって重要なのは、LLM特有の脆弱性は全体の18.5%にとどまり、残り81.5%は従来型の脆弱性だったという点です。つまり「AIだから新しい特殊な守り方が要る」以前に、Webアプリとして当たり前の穴が数多く残っていた、ということです。
| 分類 | 主な内訳（件数） |
|---|---|
| 従来型（81.5%） | パストラバーサル 121件／インジェクション 91件／不適切なアクセス制御 76件 |
| LLM特有（18.5%） | モデルファイル・プロンプト・データセット等の不適切な扱い 54件／生成物の検証不備 24件／LLMOpsワークフローの汚染 16件 ほか |
被害はどこに集中しているのか
公開サービスへの影響という観点では、特定の人気OSSに被害が偏在していました。研究では、以下の3プロジェクトだけで「脆弱性の影響を受けるサービス」の約91.6%を占めたとしています。
- Open-WebUI：稼働 15,873／関連CVE 36件
- Dify：稼働 16,077／関連CVE 17件
- Ollama：稼働 8,103／関連CVE 17件
いずれも「手元で手軽にLLMを立てる」ために現場で人気のツールです。裏を返せば、情シスが把握しないまま部門・個人が立てた“野良LLM”が、そのまま外部公開されている可能性を示唆します。ここが今回いちばん刺さるポイントだと感じます。
実際にどんな被害につながるのか
研究は、悪用時の深刻な影響を3つに整理しています。抽象論ではなくCVE付きの実例が挙げられている点が生々しいところです。
- モデルの改ざん（約35.5%）：RagFlowのCVE-2024-10131／CVE-2024-12433などで、攻撃者が任意コード実行に至り「学習済みモデルの重みや推論ロジックを書き換える」恐れ。AIの出力そのものを乗っ取られる。
- データセットの露出（約18.1%）：LangChainのGraphCypherQAChain（CVE-2024-8309）で、プロンプト経由のSQLインジェクションからデータ持ち出しに至りうる。
- GPUリソースの不正利用（約21.1%）：RCE経由で高価なGPUを踏み台にされ、計算資源をただ乗りされる。
「AIの精度が落ちる」程度の話に見えて、実際はコード実行・情報漏えい・資源の悪用という、従来のインシデントと地続きの被害です。だからこそ既存の脆弱性管理の延長線で捉えられます。
情シスから見た「使いどころ」
この研究のありがたい点は、身構えすぎなくてよいと教えてくれるところです。特殊なAIセキュリティ製品を導入する前に、まず従来のセオリーがLLM基盤にも効くと分かるからです。現場目線で優先順位をつけるなら、次の順で確認するのが現実的でしょう。
- 公開状態の棚卸し：Ollama・Open-WebUI・Difyなどが、意図せず社外から到達可能になっていないか。まずは「立っているか」より「外から見えるか」を確認する。
- 外部リソースは信頼しない：外部から持ち込むモデルファイル・プロンプトテンプレート・データセットは“実行される可能性のある入力”として扱う。
- パッチ運用に乗せる：LLM系OSSは更新が速い。既存の脆弱性管理の対象台帳に入れておく。
正直なところ、限られた人員で日々増える“便利ツール”の版まで追い切るのは骨が折れます。だからこそ「全部を完璧に」ではなく、まず外部公開されているものだけでも把握する——ここに絞るだけでリスクは大きく下がるはずです。
限界・留意点
過度な一般化は禁物です。数値は特定のデータセット・収集時点・対象リポジトリの取り方に依存し、公開サービスの検出も観測条件で上下します。CVEは「報告された脆弱性」であって、報告の多い人気OSSほど件数が積み上がる傾向がある点にも注意が必要です。あくまで傾向をつかむための材料として読み、自社環境の実測に置き換えて判断してください。
情シスはどうすべきか（まずは公的指針へ）
個別のチェックリストを自前で長々と作るより、まずは体系だった公的資料を土台にするのが近道です。AI固有の論点はまだ発展途上ですが、「外部から持ち込む資産を信頼しない」「公開範囲を絞る」という考え方は、既存のサプライチェーン対策とそのまま地続きです。ソフトウェアの脆弱性管理の基本は、IPAの中小企業の情報セキュリティ対策ガイドラインが入り口として使いやすいでしょう。運用の現場では、利用ツールの届け出・棚卸しといった地道なユーザ啓発が結局いちばん効きます。
より広い文脈は、当サイトのサプライチェーン攻撃とは？仕組みと種類をわかりやすく解説もあわせてご覧ください。AIエージェント側のリスクはAIエージェントの記憶汚染攻撃とは 研究論文を解説で扱っています。
まとめ
- LLM基盤の脆弱性は8割超が「従来型」。特別な守り方より、まず基本の脆弱性管理が効く。
- 被害はOllama・Open-WebUI・Difyなど人気OSSに偏在。“野良LLM”の外部公開が最大のリスク。
- 情シスはまず「外から見えるAIサービスの棚卸し」から。数値は傾向として読み、自社で実測を。
出典
- Shenao Wang, Yanjie Zhao, Zhao Liu, Quanchen Zou, Haoyu Wang「Demystifying LLM Supply Chain Vulnerabilities in the Wild: Distribution, Root Cause, and Real-World Impact」（arXiv:2502.12497、Internetware 2026 採録）https://arxiv.org/abs/2502.12497
- IPA 中小企業の情報セキュリティ対策ガイドライン https://www.ipa.go.jp/security/guide/sme/index.html
