CVE-2025-34291 とは
CVE-2025-34291 は、ノーコード／ローコードで AIエージェントや RAG パイプラインを組み立てる人気フレームワーク「Langflow」に見つかった重大脆弱性です。CVSS は 9.4（v4.0）。未認証の遠隔攻撃でアカウント乗っ取りとリモートコード実行（RCE）が可能で、さらにワークスペースに保存された全アクセストークン・APIキーが露出します。2026年5月21日に米 CISA の KEV（Known Exploited Vulnerabilities）カタログに追加され（連邦機関の適用期限は2026年6月4日）、実際に悪用が確認されています。
Langflow は LLM アプリ開発で広く使われ、社内に立てた開発・検証用インスタンスがうっかりインターネットに露出しているケースが少なくありません。AI 開発基盤が攻撃対象になる、近年急増している攻撃面の代表例です。
仕組み: 3つの弱点の連鎖
この脆弱性の本質は、単独では決定打にならない3つの弱点が連鎖して未認証 RCE に至る点です（具体的な攻撃コード・PoC は本記事では扱いません）。
- 寛容な CORS 設定: Langflow が任意のオリジンからの、認証情報付き（credentials）クロスオリジンリクエストを受け入れてしまう。本来、信頼するオリジンだけに絞るべき設定が緩すぎる。
- 弱い CSRF 防御: トークン更新用の
/api/v1/refreshエンドポイントが、Cookie をSameSite=Noneで発行しつつ追加の CSRF 対策を欠いていた。このため、被害者が攻撃者の用意した悪性ページを開くだけで、被害者の認証情報を使ったクロスオリジンの更新リクエストが成立してしまう。 - コード実行エンドポイント: 認証後にアクセスできる「Python コードを実行して検証する」設計のエンドポイントが存在する。
攻撃の流れは、(1) 被害者を悪性サイトに誘導 → CORS/CSRF の穴を突いて有効なトークンを奪取（アカウント乗っ取り）→ (2) そのトークンでコード実行エンドポイントを叩き RCE、というものです。サーバを掌握されると、ワークスペース内に保存された各種 SaaS/クラウドの APIキー・トークンまで奪われ、連鎖的な侵害（cascading compromise）へ発展します。
なぜ AI フレームワークで起きやすいのか
Langflow に限らず、AI エージェント／ワークフロー基盤は構造的に攻撃面が広い傾向があります。
- 「コードを実行する」機能が中核: ノードや関数を動的に評価・実行する設計が多く、ユーザー入力がコード実行に直結しやすい。実際 Langflow では、過去にも認証なしで Python の
exec()を呼ぶエンドポイント（CVE-2025-3248）や、別系統の RCE（CVE-2026-33017）が報告されており、同種の問題が繰り返し見つかっている。 - 機密情報の集積地: LLM/外部 API を束ねる性質上、多数の APIキー・トークンが1か所に集まる。1度の侵害の被害が大きい。
- 「とりあえず公開」されがち: PoC・社内検証で立てたインスタンスが認証不十分なまま放置・露出しやすい。CISA KEV 入りの別 Langflow 脆弱性では、アドバイザリ公開から約20時間で攻撃スキャンが始まったとの報告もある。
影響範囲と修正版
- 対象: 1.6.9 までの Langflow（公開時点の最新を含む）。
- 修正: 1.6.0 系で緩和が入り、完全な修正は 1.7 系で対応とされています。最新の安全なバージョンへアップグレードしてください。
バージョン番号や修正状況は更新され得るため、必ず公式の GitHub セキュリティアドバイザリ／リリースノートで最新情報を確認してください。
対策
- 最新版へアップグレードする。CISA KEV 掲載＝悪用中のため最優先。
- インターネットに直接公開しない: Langflow（および同種の AI 開発基盤）はVPN・社内ネットワーク・リバースプロキシ＋認証の内側に置く。公開が必要なら IP 制限・WAF を併用。
- 強固な認証を必須化: 既定値・空パスワードのまま運用しない。多要素認証や SSO の前段保護を入れる。
- 保存トークン／APIキーの最小権限・ローテーション: ワークスペースに置く外部サービスの鍵は権限を絞り、漏えい前提で定期ローテーション。露出が疑われたら即失効。
- CORS/CSRF/Cookie 設定の見直し（自作・自前運用のアプリにも一般化できる教訓）: 信頼するオリジンだけ許可し、状態変更系には CSRF トークンを、Cookie は適切な
SameSiteを設定する。
侵害が疑われたら
- 露出していた Langflow に保存していた全 APIキー・トークンを即ローテーションする（下流の SaaS/クラウドへ波及しているとみなす）。
- サーバ上の不審なプロセス・cron・追加されたフロー／ノードを点検し、RCE の痕跡を確認する。
- 連携先サービスの不正アクセス・不審な API 利用がないかログを確認する。
- 汚染が疑われる場合はクリーンな環境で再構築し、検証済みの状態から復旧する。
この事例からの教訓
- AI 開発基盤も「本番同等」に守る。コードを実行する設計＋機密の集積という性質上、露出した瞬間に高価値の標的になる。デフォルトで公開しない。
- Web の基礎（CORS・CSRF・SameSite Cookie）は今も効く防御線。新しい AI ツールでも、土台の Web セキュリティが破れると一気に崩れる。
- 同種の脆弱性は繰り返す。1つのプロダクトで RCE が続く場合、設計上の攻撃面が広いサインと捉え、ネットワーク分離など多層防御で備える。
OWASP でいえば A05:2021 - Security Misconfiguration（CORS の誤設定）、A01:2021 - Broken Access Control（CSRF を含む）、そして A03:2021 - Injection（コード実行）にまたがるテーマです。LLM 固有のリスクは OWASP Top 10 for LLM も参照に値します。全体像は OWASP Top 10 入門、関連手口は クリックジャッキング・SSRF の解説も合わせてご覧ください。同時期の重大事例は Trend Micro Apex One（CVE-2026-34926）・Windows Netlogon RCE（CVE-2026-41089） でも扱っています。
なお当サイト（secutils.jp）は Langflow を使用しておらず、本脆弱性の影響は受けません。