Langflow CVE-2025-34291 対応初動

冒頭要約

2026年5月21日、CISAは Langflow CVE-2025-34291 をKnown Exploited Vulnerabilities（KEV）カタログに追加した。NVDでは、CISA KEVの対象として、2026年6月4日までの対応期限が示されている。

この脆弱性は、LangflowのCORS設定とrefresh token Cookieの扱いが組み合わさることで、認証済みセッション境界が弱くなる問題として説明されている。この記事では、悪用手順ではなく、LangflowやAIワークフロー基盤を運用する組織が 公開範囲、CORS、Cookie、セッション、APIキー、更新状況 をどう確認するかに絞る。

まずやるべきことは、Langflowの利用有無とバージョン、外部公開の有無、認証・CORS・Cookie設定、セッションやトークンの不審利用を同じ時間軸で確認することだ。

読者別に見る影響

情シス・SaaS管理者

Langflowを社内検証や部門主導のAIワークフローで使っている場合、正式な資産台帳に載っていない可能性がある。まずは「誰が、どこで、どの認証方式で、外部から到達できる状態にしているか」を確認する。

特に、社内SaaSの裏側でLangflowがAIプロキシや業務自動化の部品として使われている場合、管理者画面だけでなく、APIエンドポイントやリバースプロキシの公開範囲も確認対象になる。

開発者・SRE

開発者が確認すべき中心は、バージョン、CORS許可オリジン、Cookie属性、認証プロキシ、セッション失効、LLM APIキーの管理だ。CORSは「ブラウザが守ってくれる設定」ではあるが、認証や認可の代替ではない。

SameSite=None のCookieや資格情報付きCORSを使っている場合は、なぜ必要なのか、許可先が広すぎないか、検証環境と本番環境で同じ設定になっていないかを見直す。

セキュリティ担当・CSIRT

CSIRTは、更新適用だけで完了にしない方がよい。対象期間のアクセスログ、認証ログ、セッション発行、APIキー利用、LLMプロバイダの課金・利用量、管理操作ログを突き合わせる。

不審利用が確認できない場合でも、外部公開かつ未更新、またはCORSやCookie設定が広すぎる環境は、短期的には「侵害未確認の高リスク」として扱うのが現実的だ。

まず確認すること

以下は、防御側の初動確認チェックリストとして使える。

Langflowを利用している環境を、開発、検証、本番、部門利用、個人検証まで含めて棚卸しする。
対象インスタンスのバージョンを確認し、公式リリースで示されている更新先に到達しているか確認する。
インターネットから到達できるLangflow、AI Gateway、リバースプロキシ、管理画面を分けて一覧化する。
CORSの許可オリジンが * や広いワイルドカードになっていないか、資格情報付きリクエストを許していないか確認する。
refresh token CookieやセッションCookieの SameSite、Secure、HttpOnly、有効期限を確認する。
IdP、SSO、VPN、Zero Trust Access、リバースプロキシなど、Langflowの前段にある認証境界を確認する。
管理者アカウント、APIキー、LLMプロバイダキー、DB接続情報、Webhook連携の一覧を作る。
対象期間のログで、通常と異なる送信元、異常なトークン再発行、管理操作、想定外のLLM API利用がないか確認する。
更新・設定変更・セッション失効・キー再発行を実施した時刻と担当者を記録する。

関連する実務チェックには、AIプロキシ・LLM APIキー漏えい確認チェックリストと CVE初動対応チェックリストが使いやすい。

初動対応：やること、やらないこと、記録すること

やること

Langflow公式リリースを確認し、対象環境を修正版へ更新する。
外部公開されている場合は、必要最小限の接続元に絞る。少なくとも管理画面とAPIを無制限に公開しない。
CORSの許可オリジンを、業務で必要なフロントエンドの正規ドメインに限定する。
refresh tokenやセッションCookieの属性を確認し、広すぎる設定を見直す。
不審なセッション再発行や管理操作がある場合は、セッション失効、APIキーのローテーション、該当ユーザーのパスワード変更やIdP側の再認証を検討する。
LLM APIキー、Webhook Secret、GitHub Tokenなど、Langflowから呼び出せる外部サービスの資格情報を影響範囲として扱う。
ログ、設定値、更新前後のバージョン、判断理由をインシデント記録に残す。

やらないこと

本番環境に対して、攻撃再現や不審リクエストの試行を行わない。
「更新したので問題なし」として、セッションやAPIキーの確認を省略しない。
CORSを一時的に * に戻して動作確認するような、再発リスクのある運用をしない。
影響範囲が不明なまま、関連するLLM APIキーを削除だけして証跡を失わない。
未確認の攻撃者名、被害規模、侵害経路を社内外に断定して共有しない。

記録すること

対象インスタンス名、ホスト名、公開範囲、責任者、利用部門。
更新前後のバージョン、変更したCORS・Cookie・認証設定。
確認したログソース、対象期間、異常の有無。
失効・再発行したセッション、トークン、LLM APIキー。
エスカレーション判断、残る例外、次回確認日。

判断基準：どこまでを重大扱いにするか

状況	優先度	判断の目安
インターネット公開、未更新、資格情報付きCORSや広い許可オリジンが残っている	高	直ちに更新、公開制限、セッション・キー確認を実施し、CSIRTへ共有する
社内限定だが、複数部門が利用し、LLM APIキーや業務データを扱っている	中	更新と設定見直しを優先し、利用ログとAPIキーの所有者を確認する
検証環境のみで、外部公開なし、サンプルデータのみ	低〜中	更新し、同じ設定が本番に流用されていないか確認する
不審なセッション再発行、APIキー利用、管理操作がある	高	更新だけでなく、証跡保全、キー失効、影響調査、報告判断へ進む

エスカレーション条件は、技術的な深刻度だけで決めない。顧客情報、社内機密、業務自動化、外部APIキー、課金影響が絡む場合は、法務、広報、顧客対応、事業責任者も早めに巻き込む。

よくある誤解

CORSを設定していれば認証も守られる

CORSはブラウザのクロスオリジン通信を制御する仕組みであり、認証や認可そのものではない。認証済みCookieを含む通信を広いオリジンに許している場合、セッション境界の設計を見直す必要がある。

関連用語は CORS とセッション管理を確認すると理解しやすい。

SameSite=Noneは常に悪い設定である

SameSite=None 自体が常に誤りというわけではない。正規のクロスサイト連携に必要な場合もある。ただし、refresh tokenのような強い資格情報に使うなら、許可オリジン、CSRF対策、認証境界、ログ監視をセットで確認する必要がある。

AIツールは検証環境だから優先度が低い

AIワークフロー基盤は、APIキー、プロンプト、社内データ、Webhook、GitHub連携、SaaS連携を集約しやすい。検証環境でも、本番相当のキーや社内データを扱っているなら、影響は検証環境だけで閉じない。

CVSSだけで対応順を決めればよい

CVSSは重要な指標だが、実務ではKEV掲載、外部公開、対象資産の重要度、代替策の有無、ログ確認の難しさも合わせて判断する。脆弱性対応の考え方は脆弱性管理の基礎も参考になる。

公式情報・参考情報

まとめ

Langflow CVE-2025-34291は、単に「Langflowを更新する」だけでなく、AIワークフロー基盤の公開範囲、CORS、Cookie、セッション、APIキー、ログをまとめて見直すきっかけになる。

外部公開している環境、LLM APIキーや業務データを扱う環境、部門主導で運用されている環境では、更新、公開制限、セッション失効、キー確認、証跡保全を同じ手順に入れておきたい。まずは AIプロキシ・LLM APIキー漏えい確認チェックリストで、対象環境と資格情報を棚卸しするところから始める。

Langflow CVE-2025-34291がKEV追加：AI基盤のCORSとセッションを確認する

冒頭要約