1.背景
トークンは、あなたやそれを持つ人のために扉を開くことができる。
新しいセールスロフト・ドリフトこの事件は、このような攻撃がもたらす被害の大きさを露呈している。攻撃者のUNC6395は、盗まれたOAuthトークンを使用して、Cloudflare、Zscaler、Palo Alto Networksなどの大手ハイテク企業を含む約700のSalesforce組織から大規模にデータを盗み出しました。
人工知能エージェントやワークフロープラットフォームは、外部サービスやデータシステムの統合センターとなっている。統合のたびに認証情報が追加され、機密性の高いアクセスが一箇所に集中する。この集中化により、攻撃者は価値の高い標的となります。たった一度のセキュリティ侵害で、攻撃者は接続されているすべてのシステムの「マスターキー」にアクセスできるようになります。
共有プラットフォームの場合、単一のセキュリティ侵害が複数の組織に影響を及ぼす可能性があります。セルフホスト型プラットフォームの場合、単一のセキュリティ侵害が単一の組織内の複数のサービスを暴露する可能性があります。このようなリスクを考慮して、私たちは、基盤システムの完全な破壊につながる可能性のある潜在的な脆弱性を特定するために、有名なオープンソースのAIエージェントとワークフロープラットフォームのセキュリティ評価を実施しました。
PythonとFastAPIで構築されたLangflowは、オープンソースで、AIワークフロー、RAGアプリケーション、マルチインテリジェンスシステムを構築するためのローコード可視化フレームワークです。PythonとFastAPIをベースに構築されたLangflowは、直感的なドラッグ＆ドロップのインターフェースを提供し、開発者は多くのコードを書くことなく複雑なAIアプリケーションを作成することができます。
注目すべきは、ラングフローは2024年4月にデータスタックスに買収されたことだ。データスタックスは現在IBMに買収されており（2025年2月に発表）、ラングフローはIBMの拡大するワトソンクスAIポートフォリオの一部となっている。
2、ラングフローの深さ分析と応用
2.1、CVE-2025-3248：2年間の歴史
Langflowはまだ若く、急速に開発が進んでいるプロジェクトである。その良い入り口は、脆弱性の歴史だ。ほんの数ヶ月前、CVE-2025-3248という脆弱性が表面化しました：1.3.0より前のバージョンに影響を及ぼす、深刻で認証されていないリモート・コード実行の脆弱性です。
本当に印象的なのは、問題の深刻さだけでなく、その背後にあるストーリーだ。最初の発見から最終的な修正まで約2年という、アーキテクチャ上のトレードオフとラングフローのセキュリティ態勢がどのように進化してきたかを露呈する、異例の長さである。
ディスカバリーと修復のスケジュール：
- 2023年7月27日GitHub ユーザー @Lyutoon が提出した Issue #696認証されていないコード検証エンドポイントは、関数定義のデフォルト・パラメータを経由してリモート・コード実行（RCE）に悪用される可能性があることに留意されたい。
- 2024年11月10日Github ユーザー @nimasteryang がプルリクエストを提出した。 #4488しかし、この脆弱性は既存の機能を壊してしまうため、修正は断念された。
- 2025年2月22日 ホライゾン3.aiセキュリティ研究者はGitHub Security Issuesを通じてLangflowの脆弱性を報告し、コード検証中に関数のデコレーターを利用してRCEを引き起こす、2つ目の別のRCEベクターを発見した。
- 2025年3月3日付の書簡脆弱なエンドポイントに関するLangflowチーム#6911CVE-2025-3248の脆弱性を正式に修正するために、認証要件を実装する。
この2年間のタイムラインは、お馴染みのトレードオフを浮き彫りにしている。特にAIの分野では、安全性が置き去りにされる一方で、チームは構築して採用を勝ち取ろうと躍起になっている。
2.2.脆弱性：クイックレビュー
この脆弱性がどのように機能するかを簡単におさらいしておこう。
核心的な問題は、ラングフローの/api/v1/validate/codeカスタムコンポーネントの Python コードスニペットを認証するために設計されたインターフェイスです。しかし、バージョン1.3.0以前は、このインターフェースは認証なしでアクセスできました：
src/backend/base/langflow/api/v1/validate.py
ねばならないvalidate_code()この関数は提供されたコードを解析し、その中に関数定義が含まれているかどうかをチェックし、それらの関数を実行して検証する：
src/backend/base/langflow/utils/validate.py
このコードでは、関数定義は実行しても安全であると仮定している。そうではありません。exec()`関数が関数定義を実行すると、即座にデフォルトの引数とデコレータの式を実行します。
サンドボックス・メカニズムがなければ、認証されていないユーザーなら誰でも、サーバーにPOSTリクエストを送ることでシステムを完全に侵害することができる。/api/v1/validate/code。
この脆弱性は、侵害されたLangflowインスタンスを通じてFlodricボットネットを展開する脅威者によって積極的に悪用されている。トレンドマイクロ調査これが記録された。
3.開放から閉鎖へ
CVE-2025-3248に対応して、/api/v1/validate/codeエンドポイントに認証機能を追加しました。リクエストがこのエンドポイントに到達すると、FastAPI の依存性注入メカニズムが自動的に認証プロセスをトリガーします。。
3.1.エンドポイント・ステートメント認証要件
3.2.ユーザーアカウントが有効であることを確認する
3.3. 物理的認証チェックの実施
get_current_user()関数は、優先順位の高い順に両方の認証ソースをチェックする：
そもそもAuthorization: Bearer ヘッダーのJWTトークン。
第二種: x-api-keyヘッダまたはクエリパラメータからのAPIキー
パッチリリース後、コード検証エンドポイントはデフォルトでは開かれなくなりました。このエンドポイントへのアクセスには、有効なJWTトークンまたは有効なAPIキーが必要になりました。
4.保護から漏洩へ：CVE-2025-34291
認証は理論的には完璧に見える。したがって現実的な問題は、有効なクレデンシャルにアクセスできるのか、あるいはそれを利用できるのか、ということになる。以下の3つの分野が注目される：
1) APIキー
APIキーはデフォルトでは自動的に設定されず、ユーザーが設定で明示的に作成する必要がある。攻撃対象が限定されている。
2) CSRFとCORS？
これは興味深いパスだ。適切なCSRF保護がなければ、攻撃者は次のことができる。クロスサイトライトユーザーとしてリクエストを行う。CORSポリシーが誤って設定されている場合、攻撃者が実行できるアクションは他にもある。クロスオリジンリード認証されたリクエストから返された機密性の高い応答を取得する。
3) XSSでJWTトークンを盗む
バックエンドはログイン中にJWT（HS256）を生成して署名し、それをHTTPレスポンスの一部としてaccess_token_lfクッキーSameSite=ラックス.同じトークンがレスポンス本文にも含まれる。
フロントエンドはこのクッキーを読み、標準の認可：ベアラ <トークンヘッダは、すべての API リクエストにこのトークンを含めます。
言い換えれば、JWTトークンの値は、JWTトークンの値と同じである。access_token_lfクッキーに保存される値は同じです。クッキーは暗号化されていないのでHttpOnlyそのため、クライアント側のJavaScriptはそれを読み取ることができるのですが、これにはLangflowに別のXSS脆弱性が必要です。
幸いなことに、方法2はうまくいった。2つのコンフィギュレーション・エラーを発見し、認証を完全にバイパスすることができたのだ。
4.1. CORSの設定ミス
デフォルトでは、Langflow は FastAPI の CORSMiddleware を使用し、どのようなソースからのリクエストも許可する緩やかな設定になっています。さらにallow_credentials攻撃者が認証情報を使ってクロスドメインリクエストを開始できるようにするには、この設定もTrueにする。
langflow/main.py#L292-L300
しかし、これ以上の利用を阻む2つの問題がある：
- 第1号認証クッキーaccess_token_lf設定済みSameSite=ラックスこれは、トップレベルのユーザーによる GET ナビゲーションを除き、ほとんどのクロスサイトコンテキスト (XHR/fetch/POST) から除外されます。
- 第2号Langflow1.5以降では、ほとんどのAPIエンドポイントは、Langflow APIキーの提供、またはAuthorisationヘッダーにJWTトークンを含めることで、追加の認証を要求します。
したがって、認証されたクロスドメイン・リクエストを送ることはできないはずだ。このCORSの設定は、十分に無害であるように思われる - 見落とされていた詳細が攻撃の連鎖を再燃させるまでは。
4.2. refresh_token_lf クッキー設定エラー
ねばならないリフレッシュ・トークンクッキーの設定SameSite=None; Secureこれは HTTPS 経由でクロスサイト・コンテキストにアクセスできるようにするものである。さらに、このパスワードは最長で 1 週間有効であるため、攻撃者はより長い攻撃期間を得ることができる。
ねばならない/api/v1/リフレッシュエンドポイントは認証メカニズムとしてこのクッキーのみに依存し、追加の CSRF 保護は実装していません。
その結果、攻撃者がコントロールするドメインからのクロスドメイン・リクエストは/api/v1/リフレッシュ新たなトークンのペアを獲得することができる。アクセストークンと新しいトークンリフレッシュ・トークンこれにより、セッションを完全にハイジャックすることができる。
有効なアクセストークンを所有する攻撃者は、単純に別のクロスドメインリクエストを発行することで、CVE-2025-3248の脆弱性を悪用し、リモートでコードを実行することが可能です。
5.再現ステップ
5.1 環境設定
1.Docker ComposeでLangflowをローカルに設定し、HTTPSを有効にする。:
2.ラングフロー訪問:https://:443ブラウザで開き、次のように置き換える。<サーバー・アドレスはLangflowがデプロイされているサーバーのIP/ホスト名です。
3.ログインデフォルトadmin:admin新しいユーザーセッションを開始するための認証情報。
5.2 概念実証
1.PoCページを開くナビゲーションhttps://www.pocs.app/langflow-cors-vul-poc.htmlまで
2.コンフィギュレーションの目的をクリックします。ローンチ・エクスプロイト。
3.奇跡を目撃する数秒後、以下のようになります：
- POST /api/v1/refreshブラウザは被害者クッキーを含むクロスドメイン・リクエストを送信する。
- 抽出されたPoCとaccess_tokenrefresh_token
- を渡す。/api/v1/validate/codeエンドポイントがリモートコード実行（RCE）を引き起こす。
4.結果環境変数やその他の機密データがPoCターミナルパネルに表示されます。
6.脆弱性の影響
Langflow はグローバル変数を使用して、認証情報やその他の共通値を保存し、プロセス間で再利用します。これらの変数は内部データベースに永続的に保存され、その値はキーを使用して暗号化されます。
いったんシステムが侵害されれば、攻撃者がこれらの値を解読するのは簡単だ。
完全なセッション・ハイジャックとリモート・コード実行 - システムの完全な制御は、1回の悪意のあるウェブ訪問で達成することができます。リクエストはCORSを介して被害者のブラウザから開始されるため、ローカルに配置された非公開インスタンスでさえ悪用される可能性があります。
リモート・コード実行（RCE）脆弱性は、AI エージェントおよびワークフロー・プラットフォームとしての Langflow の役割において特に危険です。攻撃者は、APIキー、データベースパスワード、SaaSやクラウド、その他の環境への接続に使用されるサービストークンなど、ワークスペースに保存されたプロジェクトフローや特権クレデンシャルにアクセスすることができます。これにより、攻撃の範囲がLangflowインスタンスそのものを超えて大きく拡大し、Langflowのようなエージェント構築プラットフォームが単一障害点となります。
6.1 セキュリティに関する推奨事項
Langflowが完全な修正版のリリースを遅らせているのは、Cookie/CORSの設定を厳しくすることで、フロントエンドとバックエンドの分離デプロイメントが壊れるかもしれないという懸念によるもののようです。
セキュリティの観点からは、「リフレッシュ・エンドポイントはどのように保護されるべきか？
1.認証がクッキーに基づく場合、適切な CSRF 保護が行われなければなりません。同じサイトへのデプロイメント(例えば、https://app.example.com → https://api.example.com。クロスドメインではあるが、同じサイトに属している)の場合、リフレッシュクッキーはSameSite=LaxかStrict(SecureとHttpOnlyの両方が有効になっていることが望ましい)で安全に使うことができます。フロントエンドとバックエンドが同じサイトにない場合フロントエンドとバックエンドが同じサイト上になく、いくつかの機能が SameSite=None を必要とする場合、明示的な CSRF トークン機構を追加する必要があります。
2.リフレッシュ・トークンは、クッキーではなくHTTPヘッダを介して送信されることが望ましい。Authorisation: Bearer ` の使用はCSRF脅威モデルを完全に排除し、ブラウザが管理する認証情報の添付を回避し、CORSのハードニングを単純化します。
最後になったが、この脆弱性はひとつの致命的な欠陥から生じたものではなく、一見無害に見えるコンフィギュレーションの選択が組み合わさって深刻な攻撃経路を形成した結果であった。この事件は重要な教訓を浮き彫りにしている。複雑なシステムでは、一見無害に見える設計上の決定でさえ、予期せぬ形で相互作用する可能性があるということだ。特に、AIプラットフォームが企業のワークフローにますます組み込まれ、機密データをますます扱うようになるにつれて、包括的なセキュリティレビューとデフォルトのセキュリティ設定の重要性が強調されている。
6.2 緩和措置プログラム
責任を持ってこの問題を公表した後、Langflowチームは問題を認め、一連の修正を開始しました。ラングフローの開発ログによると
- バージョン1.6.0新しい環境変数が導入され、ユーザーがLangflowのCORS設定を完全にカスタマイズできるようになりました。
- 次の1.7リリースでは以下は、CORSのプログラムと活動の一例である。リフレッシュ・トークンクッキーはすべて、より安全なデフォルト設定に設定されます：
- CORSは、明示的に指定されたソースからの認証されたリクエストのみを許可する。
- リフレッシュ・トークンクッキーはデフォルトでSameSite=ラックスクロスサイトエクスポージャーを減らす。
この記事を書いている時点で、最新の公式バージョンは1.6.9であり、1-click Remote Code Execution（1-clickRCE）はデフォルトの設定でまだ完全に利用可能である。
組織は次のことができる。CORS公式ガイド手動でデプロイを強化する。また、フロントエンドとバックエンドが同じサイトにある場合は、PRを適用することもできます。 #10139での復元手順リフレッシュ更新はソースコードレベルで行われる。ストリクトラックス
さらに、ラングフローチームは、コード検証エンドポイントに取り組んでいます。#10696開発サンドボックス。これで、潜在的なリモート・コード実行のリスクを一挙に解決できることを願っている。
6.3.脆弱性開示スケジュール
- 29 2025年7月- この脆弱性はGitHub Security Issuesを通じて提出されたもので、バックアップとしてHackerOneのDataStaxにも報告されている。
- 2025年7月29日付、駐日欧州委員会代表部からの書簡--ラングフローがPRを提出 #9240(「クッキーのセキュリティを改善する」)。このフロントエンドの変更はhttpOnlyクッキー(バックエンドで設定されなければならない)には影響しないので、問題は軽減されません。
- 2025年7月31日- HackerOneのレポートは分類されています。
- 2025年8月5日付、駐日欧州連合代表部からの書簡--GitHub のセキュリティ問題に関するアップデートのリクエスト。
- 2025年9月7日付、駐日欧州委員会代表部からの書簡--GitHub のセキュリティ問題に関するアップデートのリクエスト。
- 2025 年 9 月 11 日- ラングフローがPRを提出 #9441(また、「v1.7では、ワイルドカード・ソースを使用する場合、認証情報は自動的に無効になります。
- 2025年9月25日-- Langflow 1.6.0リリース：CORS許可ソースをカスタマイズするための環境変数を導入。しかし、デフォルトの設定はまだ脆弱である。
- 2025年9月26日--HackerOneの進捗状況のアップデートを要請する。
- 2025年10月3日付、駐日欧州委員会代表部からの書簡-- DataStaxは、"チームの問題だ "と答えた。
- 2025年10月22日- VulnCheckはCVE番号を割り当てるよう要請している。
- 2025年10月23日付、駐日欧州連合代表部からの書簡--CVE-2025-34291 脆弱性が割り当てられました。VulnCheck チームの迅速な CVE 対応に感謝する。
- 4 2025年11月--CORSの設定を調整することで、ユーザーが手動で問題を軽減することができたので、この研究を公表することにした。
Obsidian Security社のセキュリティ研究者が、Langflowに一連の深刻な脆弱性を発見した。
元記事はChief Security Officerによるもので、転載の際はhttps://www.cncso.com/jp/cve-2025-34291-langflow-ai-agent-workflow-platform-rce.html。
