Langflow CVE-2026-0770｜認証不要 RCE のリスクと緊急緩和策

はじめに

Langflow は LLM アプリケーションやエージェントワークフローを GUI で構築できる OSS として広く利用されていますが、2026 年に入り、認証不要で遠隔からコード実行（RCE）に至る深刻な脆弱性 CVE-2026-0770 が公表されました。本脆弱性は Zero Day Initiative（ZDI）によって 0-day として公開され、2026 年 7 月 21 日には CISA の Known Exploited Vulnerabilities（KEV）カタログに登録されています。悪用が確認されており、是正期限も短く設定されているため、公開環境で Langflow を運用している場合は早急な確認が求められます。

CVE-2026-0770 は、Langflow のコード検証エンドポイント（/api/v1/validate/code）が受け取った Python コードをサンドボックスなしで実行してしまう問題に起因します。CVSS スコアは 9.8（Critical）で、成功すると root 権限での任意コード実行につながります。修正版の扱いには後述する不確実性があるため、バージョンアップだけに頼らず、ネットワーク隔離や既定設定の見直しといった緩和策を並行して検討することをおすすめします。

Langflow とは — 用途と攻撃対象領域

Langflow は、LangChain をベースに LLM を用いたアプリケーションやエージェントのワークフローを、ドラッグ＆ドロップの GUI で構築できる OSS です。プロトタイピングの容易さから、検証環境やクラウド上に手軽にデプロイされるケースが多く見られます。

デフォルトでは TCP ポート 7860 で Web UI と API を公開します。AWS EC2 や Kubernetes などのクラウド・コンテナ環境に配置される事例も多く、この場合、単一サービスの侵害がクラウド基盤全体へのリスクに波及する可能性があります。

攻撃対象領域として特に注意が必要なのは、次の 2 点です。

• API エンドポイントがインターネットに直接公開されやすい構成であること
• 既定で AUTO_LOGIN=true となっており、既定資格情報が有効な状態で稼働しがちであること

この 2 点が組み合わさると、後述するコード検証エンドポイントへ外部から到達可能となり、CVE-2026-0770 の悪用条件が成立しやすくなります。

CVE-2026-0770 の概要

CVE-2026-0770 は、Langflow のコード検証処理に存在する任意コード実行の脆弱性です。CWE 分類は CWE-829（信頼できない制御領域からの機能の取り込み）で、CVSS 3.0 スコアは 9.8（Critical）、ベクトルは AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H です。攻撃元区分がネットワーク（AV:N）、攻撃条件の複雑さが低（AC:L）、必要な権限なし（PR:N）、利用者関与なし（UI:N）という、遠隔から容易に悪用可能な性質を示しています。

本脆弱性は ZDI-26-036（ZDI-CAN-27325）として、Trend Research の研究者により報告されました。認証を必要とせずに悪用可能である点について、ZDI は次のように記載しています。

参考: Zero Day Initiative（ZDI-26-036）
“Authentication is not required to exploit this vulnerability.”
（この脆弱性の悪用に認証は必要ありません。）
https://www.zerodayinitiative.com/advisories/ZDI-26-036/

ZDI による 0-day 公開の経緯

本件は、ベンダーとの調整期間内に修正が提供されなかったため、0-day として公開された経緯があります。ZDI の開示タイムラインによると、報告から公開までの流れは次のとおりです。

• 2025 年 7 月 18 日: ZDI がベンダーへ報告
• 2025 年 9 月〜10 月: ZDI が状況確認・修正状況を照会
• 2025 年 12 月 10 日: ZDI が 0-day として公開する意向を通知
• 2026 年 1 月 9 日: 調整済み公開（Coordinated public release）として公開

ZDI 自身は緩和策について、製品との対話（アクセス）を制限すること以外に有効な策はない、という趣旨の見解を示しています。この点は、後述する「修正版の不透明さ」とあわせて、緩和策を重視すべき根拠となります。

CISA KEV 登録と是正期限

CVE-2026-0770 は、2026 年 7 月 21 日に CISA の KEV カタログへ登録されました。KEV への登録は、実環境での悪用が確認されていることを意味します。CISA の評価（SSVC）でも、悪用状況は「active（悪用中）」、自動化可能性は「yes」と判定されています。

連邦機関向けの是正期限は 2026 年 7 月 24 日と、極めて短く設定されています。民間組織に法的拘束力はありませんが、悪用中かつ自動化が容易な脆弱性であることを踏まえ、同等の緊急度で対応を検討することをおすすめします。

脆弱性の技術的詳細

CVE-2026-0770 の本質は、ユーザーから送信された Python コードを、権限制限のない状態で実行してしまう実装にあります。Langflow はカスタムコンポーネント機能を備えており、利用者が記述した Python コードの妥当性を検証する処理が組み込まれています。この検証処理が攻撃の起点となります。

validate/code エンドポイントと exec() の問題

問題の処理は、コード検証を担う validate_code() 関数（src/lfx/src/lfx/custom/validate.py）に存在します。この関数は受け取ったコードを AST として解析し、関数定義（ast.FunctionDef）をコンパイルしたうえで、exec() によって実行します。

# validate.py（該当箇所の概念図）
for node in tree.body:
    if isinstance(node, ast.FunctionDef):
        code_obj = compile(ast.Module(body=[node], type_ignores=[]), "<string>", "exec")
        exec(code_obj, exec_globals)  # ← ここで任意コードが実行される

CVE 名称にもなっている exec_globals は、exec() に渡されるグローバル名前空間です。ここに importlib や Python の組み込み関数へのアクセスが含まれているため、実行されるコード側から os・subprocess・socket といったモジュールを読み込むことが可能になります。サンドボックスや名前空間の制限が施されていないことが、CWE-829（信頼できない制御領域からの機能の取り込み）に分類される理由です。

なお、validate_code() が実行するのは関数の「定義」であり、関数の「呼び出し」ではありません。ただし、Python では関数定義時にデフォルト引数の式が評価される仕様があるため、この挙動を利用することで定義のみでもコード実行が成立します。「関数を呼び出していないから安全」という前提は成り立たない点に注意が必要です。

対象となるエンドポイントは POST /api/v1/validate/code で、既定では TCP ポート 7860 で待ち受けます。

参考: NVD（CVE-2026-0770）
“The specific flaw exists within the handling of the exec_globals parameter”
（本脆弱性は exec_globals パラメーターの取り扱いに存在します。）
https://nvd.nist.gov/vuln/detail/CVE-2026-0770

「認証不要」の実態と AUTO_LOGIN

ZDI および NVD は本脆弱性を「認証不要（PR:N）」と分類していますが、実際の到達経路については補足が必要です。公開されている検証コードの多くは、Langflow の API に対してログイン処理を行ったうえで検証エンドポイントへ到達する構成をとっています。

ここで鍵となるのが、Langflow の既定設定である AUTO_LOGIN=true です。この設定が有効な場合、認証を経ずにセッションが確立され、既定資格情報が変更されていない環境では、外部の攻撃者が容易にトークンを取得できます。結果として、認証機構が実質的に機能せず、無認証と同等の状態で悪用が成立します。

この構造は、対策を検討するうえで重要な意味を持ちます。 バージョンを断定できない状況であっても、AUTO_LOGIN の無効化と既定資格情報の変更は、攻撃者の到達経路を狭める実効性のある措置となります。

なお、/api/v1/validate/code に認証を追加する修正は、過去の CVE-2025-3248（Langflow 1.3.0 で修正）で既に実施されています。CVE-2026-0770 は、認証の有無とは別に、実行環境そのものが制限されていない点を突く脆弱性であり、両者は別個の問題として区別する必要があります。

具体的なリスク

本脆弱性の悪用が成立した場合、影響は Langflow 単体に留まりません。実務上想定されるリスクを整理します。

root 権限での任意コード実行と横展開

ZDI のアドバイザリでは、攻撃者がコードを実行する権限のコンテキストとして root が挙げられています。コンテナイメージや簡易的なデプロイ構成では root 実行のまま稼働している事例が少なくないため、この前提は現実的です。

root 権限を奪取された場合、次のような影響が想定されます。

• Langflow が保持する API キー・LLM 認証情報・データベース接続情報の窃取
• 環境変数やインスタンスメタデータ経由でのクラウド認証情報の窃取
• 同一ネットワークセグメント内の他ホストへの横展開
• 永続化（バックドア設置、cron やサービス登録）による長期的な侵害

特に注意したいのは、クラウドやコンテナ環境で稼働している場合です。インスタンスメタデータサービスへアクセスされると、IAM ロールの一時認証情報が取得され、被害が Langflow のホストを越えてクラウド基盤全体に及ぶ可能性があります。初期侵入口として悪用された後、ランサムウェア展開の足掛かりとされる懸念もあるため、侵害を前提とした多層防御の整備をおすすめします。（多層防御の考え方は関連記事『ランサムウェア対策の実務ポイント』もあわせて参照ください）

公開 PoC の存在と悪用の現状

CVE-2026-0770 については、複数の検証コードが GitHub や Exploit-DB といった公開プラットフォームに掲載されています。攻撃に高度な技術を要さないため、無差別なスキャンによる日和見的な攻撃の対象となりやすい状況です。

Langflow はインターネット検索エンジン（Shodan、FOFA 等）で容易に特定できる特徴を持つため、インターネットに公開されているインスタンスは探索対象になり得ます。

前述のとおり、CISA は本脆弱性の悪用状況を「active」、自動化可能性を「yes」と評価しています。実環境での悪用が確認されている以上、「公開していないつもり」の環境も含め、到達可能性の実地確認をおすすめします。

影響を受けるバージョンと修正版の注意点

本記事の執筆時点において、影響バージョンと修正版の情報には、公開情報間で不整合が確認されます。この点は正確に把握しておく必要があります。

情報源ごとの記載は次のとおりです。

また、ベンダーの GitHub Security Advisory においても、本 CVE に対する修正済みバージョンは明示されていません。v1.9.0 のリリースノートを確認しましたが、exec_globals および validate/code に対する修正としての記載は見当たりませんでした。同リリースには多数のセキュリティ修正が含まれるものの、本 CVE との対応関係を公式に確認できる記述はありません。

さらに注意が必要なのは、Langflow では過去に「修正済みとされたバージョンが実際には未修正だった」事例が報告されている点です。CVE-2026-33017 に関する JFrog Security Research の調査では、修正済みとされたバージョンにおいても RCE が成立する状態が残っていたと報告されています。

参考: JFrog Security Research
“remains vulnerable to remote code execution, creating a dangerous gap”
（リモートコード実行に対して脆弱なままであり、危険な乖離が生じています。）
https://research.jfrog.com/post/langflow-latest-version-was-not-fixed/

以上を踏まえると、現時点で取るべき方針は次のように整理できます。

• 最新版へのアップグレードは実施する価値があるが、それだけで本 CVE が解消されたと断定することは避ける
• 公式アドバイザリで本 CVE の修正が明示されるまでは、緩和策を主軸に据える
• アップグレード後も、実際に検証エンドポイントへ到達可能かを自組織で確認する

確認できない情報を推測で補うことは避け、公式の更新情報を継続的に確認することをおすすめします。次章では、修正版が不透明な現状で実行できる緩和策と緊急対策を具体的に整理します。

緩和策と緊急対策

前章のとおり、本 CVE に対する修正版を公式情報から断定できない状況にあります。したがって対策は、バージョンアップの可否にかかわらず実行できる緩和策を主軸に据えることをおすすめします。ここでは優先度順に、当日中に着手できる緊急対策から段階的に整理します。

優先度 1: ネットワークレベルでの到達制限

ZDI が示す見解のとおり、本脆弱性に対して最も確実性の高い措置は、製品への到達経路そのものを断つことです。

• インターネットに公開されている Langflow インスタンスの棚卸しを行う（既定の TCP 7860 に加え、リバースプロキシ経由の公開も対象とする）
• セキュリティグループ、ファイアウォール、Ingress の設定を見直し、アクセス元を業務上必要な送信元 IP アドレスに限定する
• 業務要件上、公開が不要な検証環境は一時的に停止することも選択肢となる
• VPN や踏み台経由のアクセスに切り替え、インターネットからの直接到達をなくす

クラウド上で稼働している場合は、インスタンスメタデータサービスへのアクセス制限（AWS であれば IMDSv2 の強制）も併せて検討すると、侵害時の被害範囲を限定できます。

優先度 2: 認証設定の見直し

前述のとおり、既定の自動ログイン設定は攻撃者の到達を容易にします。公式ドキュメントでは、自動ログインを無効化する場合に管理者資格情報を明示的に設定することが推奨されています。

参考: Langflow Documentation（API keys and authentication）
“the Langflow team recommends that you also explicitly set LANGFLOW_SUPERUSER”
（Langflow チームは LANGFLOW_SUPERUSER を明示的に設定することを推奨しています。）
https://docs.langflow.org/api-keys-and-authentication

.env ファイルまたは環境変数で、次の設定を検討します。

LANGFLOW_AUTO_LOGIN=False
LANGFLOW_SKIP_AUTH_AUTO_LOGIN=False
LANGFLOW_SUPERUSER=<推測されにくい管理者名>
LANGFLOW_SUPERUSER_PASSWORD=<十分な長さと複雑さを持つパスワード>
LANGFLOW_SECRET_KEY=<ランダム生成した秘密鍵>
LANGFLOW_NEW_USER_IS_ACTIVE=False

特に見落としやすいのが LANGFLOW_SKIP_AUTH_AUTO_LOGIN です。 Langflow 1.5 では後方互換性を保つ目的で、この変数が既定で有効となっており、LANGFLOW_AUTO_LOGIN の値にかかわらず従来の無認証挙動が維持される場合があります。認証を有効に機能させるためには、両方を無効化する構成が適切です。

設定変更後は、外部から認証なしで API に到達できないことを実際に確認することをおすすめします。

優先度 3: 実行権限とコンテナの見直し

本脆弱性は root コンテキストでのコード実行につながる点が深刻度を押し上げています。実行権限を落とすことで、侵害時の影響を軽減できます。

• コンテナを非 root ユーザーで実行する（USER 指定、Kubernetes では runAsNonRoot: true）
• 読み取り専用ルートファイルシステム、no-new-privileges などの制約を付与する
• Langflow ホストからの外向き通信を必要な宛先に限定し、外部への接続や情報送出を抑止する
• Langflow が保持する API キーや認証情報を、シークレット管理サービスへ分離する

優先度 4: エンドポイント制限と WAF による仮想パッチ

修正版の提供が不透明な期間は、リバースプロキシや WAF による経路制限が実務的な緩和策となります。

• リバースプロキシで POST /api/v1/validate/code へのアクセスを遮断、または送信元を限定する
• 業務で利用しない API パスを閉じ、公開範囲を必要最小限に絞る
• WAF で、リクエストボディに __import__、subprocess、os.system などのパターンを含む通信を検知・遮断するルールを検討する

パターンマッチによる遮断は回避される可能性があるため、あくまでネットワーク制限を補完する多層防御の一要素として位置づけることをおすすめします。（WAF の選定や運用の考え方は関連記事『WAF の基礎と選定のポイント』もあわせて参照ください）

優先度 5: 侵害有無の確認と監視

KEV 登録は実環境での悪用を意味するため、対策と並行して、既に侵害を受けていないかの確認をおすすめします。確認したい観点は次のとおりです。

• アクセスログにおける /api/v1/validate/code への POST リクエストの有無と、その送信元
• ログインエンドポイントに対する既定資格情報での試行
• Langflow プロセスから発生した想定外の外向き通信（C2 通信、暗号資産マイナーのダウンロード等）
• cron、systemd ユニット、authorized_keys など永続化の痕跡
• 環境変数やメタデータ経由で取得され得るクラウド認証情報の利用履歴

侵害の可能性が確認された場合は、当該ホストの隔離と、Langflow が保持していた API キー・認証情報の失効および再発行を検討します。認証情報が窃取された前提で対応することが、被害の拡大を抑えるうえで有効です。

まとめ

CVE-2026-0770 は、Langflow のコード検証エンドポイントが受け取った Python コードをサンドボックスなしで実行する問題に起因する、CVSS 9.8 の任意コード実行の脆弱性です。ZDI により 0-day として公開され、CISA KEV にも登録されているため、悪用が現実に進行している前提での対応が求められます。修正版の情報が公式に明示されていない現状では、バージョンアップのみに依存せず、到達経路の制限を中心とした緩和策を組み合わせる方針が現実的です。

• exec() によるサンドボックスなしのコード実行に起因する RCE
• CVSS 3.0 で 9.8、認証不要かつ root 権限での実行が成立
• 既定の自動ログイン設定が実質的な無認証状態を招く要因
• CISA KEV 登録済みで、是正期限は 2026 年 7 月 24 日
• 影響バージョンの記載が情報源間で不整合、修正版も未確定
• 最優先はインターネットからの到達経路の遮断と送信元の限定
• 認証設定の見直しでは LANGFLOW_SKIP_AUTH_AUTO_LOGIN の扱いに留意

以上、最後までお読みいただきありがとうございました。