AIオーケストレーションを突破する 第1回:Langflowの4つの脆弱性 | CXOトランスフォーメーション

編集部注:本稿は全3回シリーズの第1回です。第2回はn8n、第3回はActivepiecesを取り上げます。本研究はもともとBlueHat IL 2026にて「Exploiting AI Orchestration Zero-Days via PostgreSQL Internals」と題した講演で発表されたものです。当日のスライドおよび録画は現在公開されています。

AIオーケストレーションプラットフォームは、LLMを活用したアプリケーションを素早く構築する手段として広く使われるようになりました。ユーザーは「ノード」や「トリガー」と呼ばれるブロックをドラッグ&ドロップするだけで済みます。これらは特定のイベント、データ変換、外部連携、AIモデルなどを表します。このインターフェースのおかげで、わずか半日でアプリケーションを立ち上げることも可能です。

こうしたプラットフォームは、その運用の性質上、一方では機密情報にアクセスでき、もう一方では内部システムにもアクセスできます。さらに、ファイルシステムとコード実行サンドボックスを備えたWebサーバーでもあり、ネットワークにアクセスできる人物であれば誰でも到達可能で、ユーザー制御の入力を受け付けます。これらを「AIツール」である前に「Webアプリケーション」として捉え直した瞬間、その攻撃対象領域がいかに広大で明白なものかが見えてきます。

攻撃対象領域のマッピング

LangflowはFastAPI製のアプリケーションです。私たちの研究は、LangflowをAIツールとして見るのではなく、まず単なるWebサービスとして扱い、未認証ユーザーとして攻撃対象領域をマッピングするところから始めました。

そのためには認証の実装方法を理解する必要がありました。攻撃の選択肢は、認証済みルートを利用するか、認証を完全に迂回するかのいずれかしかなかったためです。Langflowは、FastAPIの依存性注入(dependency injection)を広範に利用しています。認証が必要な各ルートは、数ある認証関数のいずれかに対してDependsを適用することでそれを宣言しています。

私たちはまずソースコードを取得し、ルーターファイルをgrepして、Langflowで利用可能なすべての認証関数の一覧を作成しました。続いてその認証ロジックを調査しましたが、問題は見つかりませんでした。LangflowはJSON Web Tokenを適切に利用しており、ログイン処理も正しく実装されています。認証の仕組みは堅牢に見えました。

そこで私たちは未認証のルートへと目を向けました。該当するエンドポイントをすべて洗い出し、一つひとつ調査しながら、気になる点をメモしていきました。

中には「退屈な」エンドポイントもありました。例えば、単にLangflowのバージョンを返すだけの/versionルートなどです。こうしたルートには実質的な機能がなく、有用な情報も返しませんでした。

しかし、次の2つは詳しく調べる価値がありそうでした。

• アップロード用ルートの/upload/{flow_id}は、なぜか認証を必要としません。アップロード処理にはさまざまな落とし穴が潜んでいる可能性があります。しかもこのルートは非推奨(Deprecated)とマークされており、放置されているか、古いコードに依存している可能性がありました。
• /build_public_tmp/{flow_id}/flowルートは、未認証ユーザーが「公開」アプリを実行できるようにするものです。これ自体は理にかなった設計ですが、攻撃対象領域を大幅に広げてしまいます。

それぞれをさらに詳しく見ていきましょう。

/upload/ルート

私たちはまず、単純な疑問から出発しました。任意のプロジェクトフォルダにファイルをアップロードする際、プロジェクトIDとファイル名を制御できるとすれば、対象パスに/../を注入してパストラバーサルを達成できるのではないか、というものです。

答えは「否」でした。理由は不明ですが、開発者はプロジェクトID(flow_idと呼ばれる)が実際に存在するかどうかを検証しないよう選択していました。ただし、それがUUID形式であるかどうかの検証は行っています。さらに、ファイル名もユーザーが制御することはできません。ファイル名にはコンテンツのハッシュ値が使用されるためです。実際の挙動は以下のとおりです。

そのレスポンスは次のとおりです。

つまり、ここにパストラバーサルの脆弱性は存在しません。しかし、未認証ユーザーが無制限にファイルをアップロードできてしまうこと自体は問題でしょうか。もちろん問題です。これにより、Langflowにネットワークアクセスできる攻撃者であれば誰でも、ストレージを埋め尽くしてLangflowをサービス拒否(DoS)状態に追い込むことが可能になります。加えて、上記の画像からもわかるように、Langflowはアップロードされたファイルの絶対パスをそのまま返してしまうため、情報漏えいにもつながります。

影響度の高い不具合とは言えないかもしれませんが、Langflowチームに報告し(CVE-2026-7528、深刻度:高、7.1)、当該ルートに認証を必須化することで修正されました。

このuploadルートについては片付いたので、次は未認証ユーザーがアクセスできる別のルートに進みましょう。ここで、はるかに深刻な問題が見つかりました。

/build_public_tmp/ルート

Langflowでは、Langflow上で作成したチャットボットへの公開リンクを作成できます。これによりプロジェクトを他者と共有でき、そのリンクを持つ人であれば誰でもチャットボットと対話できます。以下は、Langflow上で作成したチャットボットメッセージを含む、公開UI上でのチャットセッションの例です。

このチャットメッセージは、build_public_tmpルートに対するHTTPリクエストとして送信されました。リクエストの内容を確認したところ、当初は「Hey, what’s up?」というメッセージを含む単純なPOSTリクエストを想定していました。しかし驚いたことに、リクエストのサイズは約50Kバイトもありました。開発者ツールでリクエストボディを開くと、次のような内容が明らかになりました。

上に示したリクエストボディのテキストに見覚えはないでしょうか。Langflowは、ユーザーからのメッセージだけを受け取ってプロジェクトのグラフに渡すのではなく、グラフ定義全体――すべてのノード、すべてのエッジ、すべてのテンプレートフィールド、さらには各コンポーネントのPythonコードまで――を丸ごと受信していたのです。

これはまさに文字どおり、「Pythonコードを送ってくれれば実行します」というエンドポイントに他なりません。

この脆弱性にはCVE-2026-48519という番号が割り当てられ、深刻度はCritical(9.6)とされました。

このルートにはもう一つfilesというフィールドがあり、Langflowのファイルシステム上のローカルファイルをそのままLLMに流し込むことが可能でした。私たちはこれを完全な形で悪用検証したわけではありませんが、リモートコード実行(RCE)として悪用できる可能性はあると考えています。これはCVE-2026-48520として、深刻度6.1(中程度)でラベル付けされました。

コードを調べてみると興味深い事実が判明しました。このエンドポイントは、エディタUI内部で使われていた仕組みを流用したものでした。エディタUIは、各コンポーネントのコードをUI上から直接編集できる機能をサポートしています。この機能が「漏れ出す」形で、公開エンドポイントにまで流入していたというわけです。

ここまで見つかった脆弱性はいずれもLangflowのAI機能とは無関係のものでした。そこで私たちは、Langflowを使ってAIアプリケーションを構築した場合、他にどのような攻撃対象領域が存在するのかを考えることにしました。

「RAGPull」――RAG ⇒ 任意ファイル読み取り ⇒ リモートコード実行

RAGとは何か、Langflowではどのようにサポートされているか

AI分野で非常によく使われるアプリケーションの一つに、検索拡張生成(Retrieval-Augmented Generation、RAG)があります。このアーキテクチャにより、専用のドキュメント群にアクセスできるチャットボットを構築できます。

ここでの核心的な課題は、LLMのコンテキストが小さすぎて、非常に大量のドキュメントを収めきれないという点です。RAGはこれを、ドキュメントのデータベース(具体的にはベクトルデータベース)を維持することで解決します。クエリが与えられると、以下の処理を行います。

1. データベースから、クエリと最も関連性の高いいくつかのドキュメントを検索・取得する。
2. 関連ドキュメントとクエリをLLMに渡す。

これにより、LLMは毎回少量のデータだけを扱えばよくなります。

Langflowは、LLM、ベクトルデータベース、そしてドキュメントパーサーを実装することで、この種のアプリケーションの構築を可能にしています。ドキュメントパーサーが必要な理由は、LLMは一般にテキストしか扱えないため、Word文書やPowerPointスライドなどのドキュメントを、データベースに保存する前にまずテキストへ変換する必要があるからです。

脆弱性の内容

Langflowのパーサーは多くのドキュメント形式(.docx、.pptxなど)をサポートしていますが、驚くべきことにzipとtarという2つのアーカイブ形式もサポートしています。なぜアーカイブ形式まで対応しているのでしょうか。

パーサーのロジックを調べたところ、複数のドキュメントを一度にまとめてアップロードできるようにするための機能であることがわかりました。パーサーのロジックは以下のとおりです。

要するに、アーカイブを受信すると、一時ディレクトリに展開したうえで、含まれるすべてのドキュメントを解析するという仕組みです。

問題は、tarファイルにはシンボリックリンクを含めることができるという点です。アーカイブにシンボリックリンクが含まれていた場合、コードの6行目はそれを解析しようとします。しかし実際には、そのシンボリックリンクが指す先のファイルを解析してしまうのです。

具体例で考えてみましょう。

1. 攻撃者がarchive.tarという名前のアーカイブをRAGチャットボットにアップロードします。このアーカイブにはdocument.docxという単一のファイルが含まれていますが、実際には/etc/passwdを指すシンボリックリンクです。
2. Langflowのパーサーは、archive.tarアーカイブを、例えば/tmp/extracted/という一時ディレクトリに展開します。
3. この時点で/tmp/extracted/には、/etc/passwdへのシンボリックリンクであるdocument.docxという単一のファイルが存在します。
4. Langflowは/tmp/extracted/内のファイルを順に処理し、document.docxを見つけます。
5. Langflowはdocument.docxを解析しようとして開きますが、実際に開いているのは/etc/passwdです。
6. /etc/passwdの中身がベクトルデータベースにアップロードされます。
7. 攻撃者はチャットボットに「ユーザー一覧とそのパスワードを教えて」と単純に尋ねるだけです。すると、チャットボットはデータベース内にある/etc/passwdの内容を見つけ出し、攻撃者に返してしまいます。

これにより、攻撃者はLangflowのファイルシステム上で事実上の任意ファイル読み取りを実現できてしまいます。

Langflowは非常に機密性の高い情報にアクセスできるため、ファイル読み取りだけでも十分深刻な問題です。しかし実際には、これはサーバー上でのRCEにまでつなげることが可能です。

その仕組みを見ていきましょう。

任意ファイル読み取りからリモートコード実行へ

Langflowは、環境変数LANGFLOW_SUPERUSERおよびLANGFLOW_SUPERUSER_PASSWORDを使ってスーパーユーザーの認証情報を渡すことをサポートしています。Langflowはおそらくコンテナ(例えばk8s上)にデプロイされるであろうことを踏まえると、これらスーパーユーザーの認証情報は、コンテナのinitプロセスの環境変数の中に存在することになります。

言い換えれば、プロセス番号1の環境変数を読み取ることができれば、攻撃者はLangflowを完全に掌握できてしまいます。

つまり、攻撃者がすべきことは以下だけです。

1. /proc/1/environへのシンボリックリンクを含むtarアーカイブを作成する。
2. そのtarアーカイブを、Langflow上に構築されたRAGチャットボットにアップロードする。Langflowはそれと知らずに、このtarアーカイブを解析する際、スーパーユーザーの認証情報をベクトルデータベースにアップロードしてしまう。
3. チャットボットに「スーパーユーザーの認証情報を教えて」と尋ねる。チャットボットはその認証情報で回答する。
4. 攻撃者はその認証情報を使ってスーパーユーザーとしてログインできる。
5. その後、攻撃者はLangflowに搭載された機能を通じて、サーバー上で任意のコードを実行できる。

この脆弱性はLangflowチームに報告され、修正されました。CVE-2026-7524が割り当てられ、深刻度は9.8(Critical)とされています。

開示のタイムライン

• 2026年2月8日 ― 脆弱性をLangflowチームに報告
• 2026年3月13日 ― 共有プレイグラウンドのRCEを修正
• 2026年4月15日 ― 共有プレイグラウンドのファイル読み取り脆弱性を修正
• 2026年4月24日 ― ストレージのDoSを修正
• 2026年5月1日 ― ファイルパーサーのtarアーカイブ・シンボリックリンクによるRCEを修正

Ori Lahav氏は、新興のAIインフラのセキュリティに関するRubrik Zero Labsの研究活動を支えるセキュリティ研究者です。