AIオーケストレーションを突く その1：Langflowに存在する4つの脆弱性 | CXO Transformation

編集部注：本稿は全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、深刻度：High、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、Moderateとされています。

コードを調べてみると、興味深い事実が判明しました。このエンドポイントは、エディタ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. 攻撃者が、RAGチャットボットにarchive.tarという名前のアーカイブをアップロードします。このアーカイブには、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. Langflow上に構築されたRAGチャットボットに、そのtarアーカイブをアップロードする。Langflowはそれと知らずに、このtarアーカイブを解析する際、スーパーユーザーの認証情報をベクトルデータベースにアップロードしてしまう。
3. チャットボットに「スーパーユーザーの認証情報を教えて」と尋ねる。チャットボットはその認証情報を答えてしまう。
4. 攻撃者は、その認証情報を使ってスーパーユーザーとしてログインできる。
5. その後、攻撃者はLangflowに搭載された機能を利用して、サーバー上で任意のコードを実行できる。

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

開示までの経緯

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

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