2026年に入り、AIプラットフォームを標的にした脆弱性が立て続けに公表されている。4月公表の CVE-2026-33017（Langflow の RCE、CVSS 9.8） を皮切りに、LangChain・LightLLM・LM Studio など、社内のAIワークフローで広く使われているOSSでも Critical 級の脆弱性が相次いでいる。
AIプラットフォームの脆弱性は「RCE → 内部ネットワーク侵入 → モデル/プロンプト窃取 → 顧客データ漏えい」へと連鎖しやすい。特に RAG（社内検索）やAIエージェントを稼働させている企業は、攻撃対象面が広いため対応を急ぐ必要がある。
本記事では、2026年に公表された主要なAIプラットフォーム脆弱性を一覧で整理し、自社環境での対応優先度の付け方、ハードニング手順までを網羅的に解説する。
目次
- なぜAIプラットフォームが狙われるのか
- 2026年の主要脆弱性マップ
- CVE-2026-33017（Langflow）を軸に見る攻撃チェーン
- 対応優先度の付け方（Tier 1〜Tier 3）
- AIプラットフォーム共通ハードニング5項目
- FAQ
なぜAIプラットフォームが狙われるのか
Langflow、LangChain、LightLLM といったAIオーケストレーション基盤は、モデルAPIキー・社内データ・外部ツール実行権限を同じプロセスで束ねている。攻撃者から見ると「1つ取れば全部取れる」集中ポイントだ。
加えて、これらのOSSは開発速度が非常に速く、セキュリティレビューが後追いになりがちという構造的な弱点を持つ。週単位で新機能が追加される一方、過去の機能に潜む脆弱性が後から発見されるケースが続いている。
セクションまとめ： AIプラットフォームは「認証情報・社内データ・実行権限」の集約地点で、1点突破で複数資産が取られる構造。OSSの開発速度とセキュリティレビューの非対称性が脆弱性の温床になっている。
EMERGENCY RESPONSE
この脆弱性、貴社システムは影響を受けますか？
影響範囲の一次評価を無料で実施。致命的脆弱性は24時間以内にアラートし、パッチ適用・恒久対応まで伴走します。
2026年の主要脆弱性マップ
| CVE | 製品 | CVSS | 脆弱性の種類 | 修正バージョン | 公表日 |
|---|---|---|---|---|---|
| CVE-2026-33017 | Langflow | 9.8 | 認証バイパス経由のRCE | 1.3.x 以降 | 2026年4月 |
| CVE-2026-28741 | LangChain (community) | 8.8 | SSRF → メタデータサーバ到達 | 0.3.x 以降 | 2026年3月 |
| CVE-2026-21772 | LightLLM | 9.1 | 任意ファイル書き込み → RCE | 最新 main ブランチ | 2026年3月 |
| CVE-2026-19984 | LM Studio | 7.5 | ローカルAPIの認証欠如 | 0.4.x 以降 | 2026年2月 |
| CVE-2026-17502 | Flowise | 8.1 | デフォルト認証情報 | 2.x 以降 | 2026年2月 |
上記5件はいずれも 「AIワークフロー実行プロセスを攻撃者が乗っ取れる」 カテゴリに属する。特に CVSS 9.0 以上の3件（Langflow・LightLLM・LangChain）は、外部公開されていれば即座に RCE に至るため、最優先で対応したい。
セクションまとめ： 2026年だけでCVSS 9.0以上のAIプラットフォーム脆弱性が3件公表されている。OSS選定時は「使われているかどうか」ではなく「脆弱性の修正サイクルが回っているか」で判断すべきだ。
CVE-2026-33017（Langflow）を軸に見る攻撃チェーン
Langflow は LangChain をノーコードで扱えるビジュアルビルダーで、国内外のAI PoC現場で急速に普及している。CVE-2026-33017 は、その Langflow に存在した認証バイパスを経由したRCEで、CVSS 9.8 と極めて深刻だ。
攻撃は概ね次の流れで進行する。
- 偵察：Shodan や Censys で
8501/tcp（Langflow デフォルトポート）が開いているホストを検索 - 初期侵入：認証バイパスを用いて
/api/v1/flows/runに細工したペイロードを投入 - RCE確立：フロー実行機能のコードインジェクション経由で任意コマンド実行
- 特権昇格：Langflow プロセスが保持する環境変数から OpenAI・Anthropic・Azure OpenAI の API キーを奪取
- 横展開：同一ネットワーク内の RAG データストア（Qdrant・Pinecone・pgvector 等）に接続し、社内ドキュメントを窃取
特に深刻なのは、多くの企業が Langflow を「社内検証環境」という名目で VPN の内側にも外側にも置いている点だ。PoC 用サーバーという認識から認証設定を省略していると、CVE-2026-33017 の攻撃面にそのまま一致する。
セクションまとめ： Langflow の RCE は「偵察→認証バイパス→APIキー窃取→RAG侵害」の5ステップで社内AI資産が丸ごと奪取される。PoC サーバーだからと認証を省略している環境が最も危ない。
「自社のAIプラットフォームがこの5件の影響を受けるか即座に確認したい」
利用中のAI基盤・RAG環境の脆弱性棚卸し、ハードニング方針の策定、運用ルールの整備までワンストップで支援します。PoC環境のまま本番相当データを扱ってしまっているケースが多く、最初の棚卸しだけでも効果があります。
※ 営業電話はしません | オンライン対応可 | 相談だけでもOK
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
対応優先度の付け方（Tier 1〜Tier 3）
5件すべてを同時に対応するのは現実的ではない。以下の Tier で優先順位を付けると判断がブレにくい。
Tier 1（48時間以内に着手）
- インターネットに露出している AIプラットフォーム（Langflow・Flowise・LM Studio など）
- 本番データまたは本番相当データを扱っている PoC 環境
- 認証なしの社内ポータルから到達できるAIワークフロー
Tier 2（1〜2週間以内）
- VPN/社内ネットワークからのみ到達可能なAIプラットフォーム
- 開発者個人PC上の LM Studio・Ollama 等
- 本番に昇格予定の RAG プロトタイプ
Tier 3（月次サイクル）
- 完全にローカル閉域で運用されているAIワークフロー
- サンプルデータのみで動作する学習・検証用環境
セクションまとめ： インターネット露出と本番データの有無を主軸に Tier 分けする。Tier 1 の条件に1つでも該当するなら、48時間以内の対応が推奨される。
AIプラットフォーム共通ハードニング5項目
個別のCVE対応に加え、AIプラットフォーム全般で有効な5つのハードニングがある。
1. APIキーをプロセス環境変数から外に出す
Langflow のように RCE で環境変数が抜ける攻撃では、環境変数にAPIキーを置いている限り被害は不可避だ。シークレットマネージャー（AWS Secrets Manager・HashiCorp Vault・Azure Key Vault）経由で実行時に取得する構成に寄せる。
2. 認証を「本番と同じ」で PoC にも適用する
PoC だから省略、という運用を廃止する。SSO 連携または IP 制限を最低限必須化する。
3. AIワークフロー実行プロセスを非特権で動かす
Docker で動かすなら USER を明示し、root 実行を避ける。ホストボリュームの書き込み権限も最小化する。
4. アウトバウンド通信を制御する
RAG で使う外部API以外への通信を VPC ネットワーク ACL でブロックする。攻撃者が C2 サーバーに接続する経路を塞ぐ。
5. モデルAPI側でレート制限と利用ログを有効化する
OpenAI・Anthropic・Azure OpenAI ともに、ダッシュボードでレート制限とクォータ、IP 制限を設定できる。APIキーが盗まれた際の被害を抑える最後の防波堤になる。
セクションまとめ： AIプラットフォームの防御は「個別CVE対応＋共通ハードニング」の二段構え。特にシークレット外出しと PoC への認証適用は、将来の未知CVEにも効く投資になる。
自社AI環境の即席点検チェックリスト
- Langflow / Flowise / LM Studio を最新バージョンに更新した
- インターネット公開しているAIプラットフォームはない、または認証を必須化している
- APIキーはプロセス環境変数ではなくシークレットマネージャー経由で注入している
- PoC 環境でも本番同等のSSO / IP制限が有効になっている
- RAG データストア（Qdrant・Pinecone・pgvector 等）のアクセス制御が AIプラットフォームと独立している
- モデルAPI側でレート制限・IP制限・利用ログが有効になっている
FAQ
Q1. PoC 用の Langflow でも本当に攻撃されますか？
Shodan では Langflow で検索すると数千件のホストが観測されている。攻撃者は「本番か PoC か」を区別しないので、公開されていれば全て対象になる。
Q2. APIキーを環境変数で管理するのは悪手ですか？
コンテナ実行時に一時的に注入する分には妥当だが、長期間の環境変数設定は避けるべきだ。RCE 脆弱性が1件でも見つかった時点で全部抜ける前提で設計する。
Q3. LangChain を使っているアプリ全部が危険なのですか？
CVE-2026-28741 は langchain-community の一部連携モジュールに限定される。本体を使っているからといって即座に脆弱とは限らないが、依存関係ツリーを確認して最新化するのが安全側の判断だ。
Q4. ローカルPC上の LM Studio も狙われますか？
LM Studio の API は標準でローカルホストにバインドされるが、社内ネットワークで共有しているケースでは攻撃面になる。CVE-2026-19984 以降のバージョンを必ず利用すること。
参考情報
- NIST National Vulnerability Database「CVE-2026-33017」「CVE-2026-28741」「CVE-2026-21772」「CVE-2026-19984」「CVE-2026-17502」
- Langflow 公式リリースノート 1.3.x 系
- OWASP「Top 10 for LLM Applications 2025」
- 経済産業省「AI事業者ガイドライン第1.1版」（2025年）
関連記事
- Langflow CVE-2026-33017 RCE脆弱性｜AI基盤の緊急対応ガイド
- ゼロトラストセキュリティ導入ガイド（中小企業向け）
- RAG検索拡張生成の導入ガイド
- AIガバナンス・リスク管理ガイド
AI環境のセキュリティ棚卸しはGXOにご相談ください
「PoCで動かしたまま本番相当のデータを扱ってしまっている」「社内にAIのセキュリティレビューができる人がいない」——そんな課題に、AI環境の脆弱性診断から運用ルール整備まで一貫支援します。オンラインを中心に全国対応可能です。
※ 営業電話はしません | オンライン対応可 | 相談だけでもOK