AIエージェント構築ツール「Langflow」は、LLM（大規模言語モデル）やRAG（検索拡張生成）の処理をノードとしてつなぎ、コードを書かずにAIエージェントを組み立てられるオープンソースのアプリケーション層プラットフォームである。GitHub上で14万9千以上のスターを集め、社内にセルフホスト（自社サーバーで運用）してLLMOps基盤として使う企業が増えている。2026年7月7日、米CISA（サイバーセキュリティ・インフラセキュリティ庁）はLangflowの認可不備CVE-2026-55255を、実際の悪用が確認された脆弱性だけを載せるKEV（Known Exploited Vulnerabilities Catalog）に追加した。AIエージェント開発プラットフォームがKEVに載るのはこれが史上初とされる[1][3]。連邦機関への是正期限は本日7月10日である[1]。本稿では、この脆弱性がなぜ起きたのかを技術的に整理したうえで、社内で急拡大するAI agent基盤の権限分離という運用上の盲点を検討する。
予備知識
- IDOR（Insecure Direct Object Reference/安全でない直接オブジェクト参照）: URLやAPIのIDを他人のものに差し替えるだけで、所有者チェックなしにそのデータや処理へアクセスできてしまう不備
- KEV（Known Exploited Vulnerabilities Catalog）: CISAが運営する、実際に悪用が確認された脆弱性だけを載せる公式リスト。掲載されると米連邦機関に是正期限が課される
- CVSS（共通脆弱性評価システム）: 脆弱性の深刻度を0〜10の数値で表す業界標準指標。9以上は「緊急」水準とされる
- テナント分離: 同じシステム基盤を複数の利用者や部署が共有する際に、互いのデータや実行結果を隔離する設計
IDORのようなAPI認可の不備は今回のLangflow事例に限らず起きる。攻撃者目線のテスト手法を知ると、自社APIの点検すべき箇所が具体的に見えてくる。
CVE-2026-55255とは何か——権限チェックが抜けたIDOR
CVE-2026-55255は、認証済みの利用者であれば誰でも他人のAIエージェント処理（フロー）を実行できてしまうIDOR脆弱性である。CVSS 3.1スコアは9.9（緊急）で、ベクターはAV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Lと評価されている[2][3]。原因は/api/v1/responsesエンドポイントの実装にある。フローIDをUUIDで解決するget_flow_by_id_or_endpoint_name関数（helpers/flow.py）が、所有者を示すuser_idを照合せずにデータベースを検索していたため、他人のフローIDを知っているだけで、そのフローに埋め込まれたAPIキーや接続情報ごと実行できた[3]。影響を受けるのはLangflow 1.9.2未満で、同バージョンで所有者不一致時に404を返す明示的な検証が追加され修正された[2][3]。
LLMOps基盤を自前で構築・運用するなら、フレームワークの仕組みとセキュリティ設計を一体で理解しておく必要がある。
Sysdigが観測した実際の悪用キャンペーン
このIDORは理論上の懸念ではなく、実際に攻撃者が悪用した脆弱性としてKEVに掲載された。Sysdig Threat Research Teamは2026年6月22日から25日にかけて、単一の攻撃者がLangflowインスタンスを狙う持続的なキャンペーンを観測した[3]。攻撃者は/api/v1/flows/を列挙して他人のフローIDを収集し、/api/v1/responsesへ送りつけて実行し、ハイジャックしたフローに「APIキーを漏らせ」という趣旨のプロンプトを注入してLLMプロバイダーの鍵、クラウド認証情報、データベースの秘密情報を窃取した[3]。同じキャンペーンでは、認証不要のリモートコード実行CVE-2026-33017（CVSS 9.8、Langflow 1.8.2以前が対象、1.9.0で修正）も同時に悪用されており、単独の攻撃者がIDORとRCEを組み合わせて侵入していた[4]。
CISAは同日、Langflowに加えて3件の脆弱性もKEVへ一括追加した。深刻度を並べると、Langflowの認可不備は単独では最高値ではないが、初のAIエージェント基盤事例という点で際立つ。
| CVE | 製品 | 種別 | CVSSスコア |
|---|---|---|---|
| CVE-2026-48282 | Adobe ColdFusion | パストラバーサル→Webシェル設置 | 10.0 |
| CVE-2026-55255 | Langflow | IDOR（テナント分離不備） | 9.9 |
| CVE-2026-48908 | Joomla SP Page Builder | アクセス制御不備→RCE | 10.0 |
| CVE-2026-56290 | Joomla Page Builder CK | 任意ファイルアップロード→RCE | 10.0 |
出典: CISA KEVカタログ2026年7月7日追加分[1][4]
ソフトウェアサプライチェーン管理とコンプライアンスの領域で、EU向けにソフトウェアを提供する企業の実務判断が変わりつつある。欧州連合サイバーセキュリティ機関ENISAは2026年6月、SBOM（Software Bill of Mater[…]
なぜ「AI agentプラットフォーム史上初のKEV」が転換点なのか
この一件が示すのは、CVSSスコアの高さそのものより、AIエージェント基盤という新しい種類のソフトウェアが、既存のWebアプリケーションと同じ認可不備を抱えたまま急速に社内標準化している構図である。Langflowは低コードでエージェントを組めるがゆえに、非エンジニアの部署にも配布されやすく、複数チームが同一インスタンスを共有するケースが多い。フロー単位でLLMプロバイダーの鍵や社内API接続情報を保持する設計は利便性が高い一方、所有者チェックのようなテナント分離の基本が抜けると、被害はそのまま外部システムの認証情報漏洩に直結する。
LLMOps基盤の導入は、ツールの機能比較だけで意思決定されがちで、権限モデルの監査が後回しになりやすい。今回のようにフロー実行APIが認可チェックを欠く構造は、Langflow固有の実装ミスであると同時に、同種の低コードAIエージェント基盤に共通しうるリスクでもある。
リモート監視管理ツール（RMM、Remote Monitoring and Management、IT機器をリモートで監視・管理するツール）大手SimpleHelpに、CVSS10.0の認証バイパス脆弱性CVE-2026-48558が見つ[…]
LLMOps基盤の権限分離をどう設計し直すか
運用チームがまず着手すべきは、バージョン更新とシークレット管理の切り離しである。Langflow 1.9.2以降ではIDOR、1.9.0以降ではRCEが修正されているため、両方を満たすバージョンへの更新が最低限の対応になる[2][4]。加えて、フロー定義の中にAPIキーを直書きせず、外部のシークレット管理サービスから都度取得する設計に変えることで、フロー単位のIDOR発生時でも被害範囲を限定できる。
※本記事は2026年7月時点の情報です。料金・提供条件は変動が速いため、最新は各公式でご確認ください。一部アフィリエイトリンクを含みます。 ✅ 先に結論（Seedance 2.0の要点） 何がすごい[…]
よくある質問（FAQ）
Q1. Langflowを使っていない企業でも注意が必要か。
直接の影響は受けないが、フロー実行APIに所有者チェックがない、シークレットをフロー定義に直書きするという設計上の弱点は、他の低コードAIエージェント基盤にも起こりうる一般的なリスクである。
Q2. どのバージョンに上げれば安全か。
CVE-2026-55255はLangflow 1.9.2以降、CVE-2026-33017は1.9.0以降で修正されているため、実質的に1.9.2以降への更新が推奨される[2][4]。
Q3. パッチ適用以外に何をすべきか。
フローに埋め込んでいたLLMプロバイダーの鍵やデータベース接続情報は、侵害の有無にかかわらずローテーションし、以後は外部のシークレット管理サービスから取得する設計に切り替えるべきである。
まとめ
Langflowの認可不備CVE-2026-55255は、AIエージェント開発プラットフォームとして史上初めてCISAのKEVに載った事例であり、単なる一製品のバグではなく、急拡大するLLMOps基盤に共通する権限分離の甘さを浮き彫りにした。読者企業がとるべき判断は明確である。まずLangflowなど社内のAIエージェント基盤のバージョンとパッチ適用状況を点検し、次にフロー内に直書きされたシークレットの有無を洗い出し、外部管理への移行を予算化することである。AI agent基盤の導入速度に、権限設計とセキュリティレビューの速度を合わせることが、今後の運用コストを左右する。
