Langflow の未認証リモートコード実行 CVE-2026-9198 - 2つの「便利な機能」が連鎖してCVSS 9.8になった話

「ログイン不要でスーパーユーザーのトークンを配るエンドポイント」と、「コードを検証するはずが実行してしまうエンドポイント」。この2つが同じアプリの中に、しかも既定構成で同時に有効な状態で存在していました。片方だけでも十分に危険ですが、順番につなぐと認証情報を一切持たない攻撃者がホスト上で任意コマンドを実行できます。それがLangflowのCVE-2026-9198です。

Langflowは、LLMを使ったRAGやエージェントのワークフローをブラウザ上のノードエディタで組み立てられるオープンソースのローコード基盤です。もともとはLogspaceが開発し、その後DataStaxが取得、さらにIBMがDataStaxを買収した経緯があり、現在この脆弱性のセキュリティ速報を発行しているのはIBMです。CISA KEVカタログでもベンダー名は「IBM」、製品名は「Langflow」として登録されています。

米CISAは2026年8月4日、CVE-2026-9198をKnown Exploited Vulnerabilities(KEV)カタログへ追加しました。実際の攻撃で悪用されている証拠があるという判断です。連邦民間行政機関(FCEB)向けの是正期限は2026年8月7日、追加からわずか3日という短さです。

本記事では、IBMのセキュリティ速報、NVD、CISA KEVカタログのJSONデータ、そしてLangflowリポジトリの修正プルリクエストという一次情報を基に、何が起きたのか、なぜ既定構成で成立してしまうのか、そして運用者が今すぐ何をすべきかを整理します。

概要(まず結論)

CVSSベクタの前半AV:N/AC:L/PR:N/UI:Nは、ネットワーク越しに、特別な条件も権限も、利用者の操作すら不要で成立することを意味します。後半のC:H/I:H/A:Hは機密性・完全性・可用性のすべてが最大影響。S:U(Scope Unchanged)のため満点10.0ではありませんが、単一コンポーネント内で完結する攻撃としては最高クラスの9.8です。

もう一点、この脆弱性を特徴づけているのが「既定構成で成立する」という条件です。管理者が何かを設定ミスしたわけではなく、インストールしてそのまま起動した状態が攻撃可能でした。IBMの速報も「default-configured instances」「default deployments」という表現を繰り返し使っています。

何が起きたか(タイムライン)

順番を追うと、コード上の修正はKEV入りの1か月半以上前に完了していたことがわかります。にもかかわらずKEV入りしたということは、パッチが公開されてから実環境への適用が進むまでの間に、攻撃者が先回りしたことを示しています。

なお、修正リリース(6月23日)、IBM速報の初版公開(7月2日)、NVDへの登録(7月17日)がそれぞれ2週間前後ずれている点には注意が必要です。二次情報のなかには「7月17日に修正版がリリースされた」と読める記述も見られますが、GitHubのリリースAPIで確認する限りv1.10.1のリリース日時は2026年6月23日です。

技術的な中身: 2つの欠陥がつながって未認証RCEになる

IBMの速報は、この脆弱性を「2つの別個の問題の組み合わせ」と説明しています。片方だけでは(理屈の上では)ここまで深刻になりません。順に見ていきます。

第1段: /api/v1/auto_login が超長期のsuperuserトークンを配っていた

LangflowにはAUTO_LOGINという設定があります。これは「認証画面を出さずに、常に設定済みのスーパーユーザーとしてサインインさせる」ためのもので、ローカルで一人が試すときの体験を良くする開発者向けの配慮です。そしてこの設定はOSS版のアプリケーション既定値としてTrueでした。

修正プルリクエスト#13699の説明によれば、AUTO_LOGINがTrueのとき、未認証のGET /api/v1/auto_loginが内部のcreate_user_longterm_tokenに到達し、有効期限365日のスーパーユーザーアクセストークンを、リフレッシュトークンなしで発行していました。つまり、そのエンドポイントにネットワーク到達できる相手なら誰にでも、1年間有効な管理者相当のBearerトークンを渡していたことになります。

修正ではcreate_user_longterm_tokenがcreate_user_tokensに委譲する形に変更され、短命のアクセストークン(既定1時間)とリフレッシュトークンの組み合わせになりました。あわせて、auto_loginがセッションを発行するたびに警告ログを出すようになっています。なおAUTO_LOGINの既定値自体はTrueのまま据え置かれており、これを反転させるのは破壊的変更としてv2.0へ持ち越すとプルリクエストに明記されています。1.10.1へ上げても、この設定を意識的にオフにしなければ「誰でもログイン扱い」という性質そのものは残るという点は理解しておく必要があります。

第2段: /api/v1/validate/code が「検証」と称してexec()していた

もう一方のPOST /api/v1/validate/codeは、その名の通りユーザーが書いたコンポーネントのコードを検証するためのエンドポイントです。ところが修正プルリクエスト#13696の説明によれば、この実装は送られてきたソース内のすべての関数定義をコンパイルしたうえでexec()していました。

ここが直感に反するポイントです。「関数を定義するだけなら中身は動かないはずでは」と思うかもしれませんが、Pythonでは関数定義そのものの評価時点で、デコレータとデフォルト引数の式が実行されます。プルリクエストに掲載されている例はこうです。

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

fは一度も呼び出されません。それでも、この定義文が評価された瞬間にデフォルト引数の式が評価され、os.systemが動きます。型アノテーションの式も同様に定義時に評価されうるため、攻撃者が任意コードを潜り込ませる経路は1つではありません。

修正後のvalidate_codeは各FunctionDefをコンパイルするだけにとどめ、exec()しなくなりました。構文エラーやインポートエラーを検出するという本来の目的はコンパイルだけで達成できるためです。正規のコンポーネント実行を担うヘルパー群は、別途allow_custom_componentsという設定で保護されており、今回の修正では触れられていません。

2段を連結すると

IBMおよびNVDの記述をそのまま整理すると、攻撃の流れはこうなります。

1. 攻撃者が認証なしで/api/v1/auto_loginを叩き、スーパーユーザーのBearerトークンを受け取る。
2. そのトークンを添えて/api/v1/validate/codeへ、デコレータやデフォルト引数に細工したPythonソースをPOSTする。
3. Langflowプロセスの権限でホスト上のコマンドが実行される。

validate/code側は本来「認証済みユーザーによるRCE」に相当する問題ですが、既定のシングルユーザーAUTO_LOGIN構成では認証の壁が事実上存在しないため、結果として完全な未認証RCEになります。修正プルリクエスト#13696がまさに「authenticated RCEだが、Langflowの既定のシングルユーザーAUTO_LOGIN構成では実質的に未認証」と表現しているとおりです。

未認証で到達できる入口とコード実行が結びつくと何が起きるかという構図は、Arista VeloCloud Orchestratorの未認証OSコマンドインジェクションでも整理しています。製品カテゴリは違いますが、「認証を要求しない入口」が最優先の対応対象になる理由は共通です。

影響範囲と対象バージョン

IBMの速報が示す影響範囲は明快です。

1.0.0以降のすべての系列が対象なので、実務上は「1.10.1より前のLangflowはすべて危ない」と考えて差し支えありません。

現時点(2026年8月6日)でのLangflow OSSの公開リリースを確認すると、1.10.1(2026年6月23日)の後に1.10.2、1.10.3、そして1.11系(1.11.0/1.11.1/1.11.2)が出ています。1.11.2は2026年8月4日リリースです。新規に構築するなら最新の安定版へ、既存環境なら少なくとも1.10.1以降へ、というのが基本方針になります。

なお、Langflowを組み込んだ商用サービスやマネージド提供形態が本CVEの影響を受けるかどうかについては、IBMの速報が対象を「Langflow OSS」と限定しているため、本記事では判断できません(未確認)。自社が利用しているのがOSS版のセルフホストなのか、ベンダー提供のマネージド版なのかを最初に切り分けてください。

AUTO_LOGIN という設計判断をどう見るか

この事案でいちばん考えさせられるのは、AUTO_LOGINの既定値がTrueであることそのものです。

Langflowの公式ドキュメントは、LANGFLOW_AUTO_LOGINがTrueのとき「すべての利用者をパスワードなしで設定済みスーパーユーザーとして自動サインインさせる」と説明したうえで、「適切なセキュリティ対策なしにLangflowのポートを直接インターネットへ公開してはならない」「LANGFLOW_AUTO_LOGIN=Falseを設定せよ」と明記しています。Falseにする場合はLANGFLOW_SUPERUSER_PASSWORDの設定が必須で、未設定ならフェイルクローズする設計です。また、公式のDockerイメージ側ではLANGFLOW_AUTO_LOGIN=falseが既に設定されているとドキュメントに書かれています。

つまりドキュメントは正しいことを書いており、公式コンテナは安全側に倒している。それでもなお、アプリケーションのコード上の既定値がTrueである以上、pip installしてそのまま起動した環境や、独自のコンテナイメージを組んだ環境は素の状態で露出します。「ドキュメントに書いてある」と「既定で安全」の間にある距離が、そのまま被害の面積になった格好です。開発者体験を優先した既定値が本番へ持ち込まれて事故になるパターンは、AWS Kiroのプロンプトインジェクション経由RCE CVE-2026-10591など、AI関連ツールで繰り返し観測されています。

悪用状況とCISA KEV

CISA KEVカタログのJSONデータから、CVE-2026-9198のエントリを整理します。

同日付のCISAアラート「CISA Adds Three Known Exploited Vulnerabilities to Catalog」(公開日2026年8月4日)は、追加の根拠を「evidence of active exploitation(積極的な悪用の証拠)」としています。ただし誰がいつからどのように悪用しているかについて、CISAもIBMも具体的な内容を公表していません。攻撃者の身元、初回悪用の時期、被害を受けた組織の数、実際に観測されたペイロードは、本記事執筆時点の公開情報では確認できていません(未確認)。

一方で、攻撃コードの入手性については客観的な材料があります。2026年8月4日、Metasploit Frameworkのリポジトリにexploit/multi/http/langflow_unauth_rce_cve_2026_9198という攻撃モジュールを追加するプルリクエストが提出されています(本記事執筆時点でオープン状態)。KEV追加と同日に主要な攻撃フレームワークへのモジュール化が動き出したという事実は、悪用の敷居がすでに相当低いことを示しています。

補足として、この時点でのEPSS(悪用可能性の予測スコア)はGitHub Advisory API上でおよそ1.9パーセント、パーセンタイルは約77でした。これは「予測モデル上は突出して高いわけではない」値です。しかし現実にはKEV入りしている。EPSSは予測、KEVは観測という性質の違いであり、EPSSが低いことをパッチ先送りの根拠にはできない、という実例として覚えておく価値があります。

同日にKEV追加された他の2件

2026年8月4日のCISAアラートでは、Langflowと合わせて計3件が追加されました。文脈として簡単に触れておきます。

NVDの記述によれば、これはCVE-2026-29146の修正に起因してEncryptInterceptorのバイパスが可能になるという、機微データの暗号化欠落(CWE-311)の問題です。影響を受けるのはApache Tomcat 11.0.20、10.1.53、9.0.116で、11.0.21 / 10.1.54 / 9.0.117へのアップグレードが推奨されています。NVDにはスコア提供元の異なる2つのCVSS v3.1評価(7.5と9.8)が併記されており、参照する情報源によって数値が食い違って見える点に注意が必要です。前の修正が新しい問題を生んだという構図です。

NVDによれば、代替パスまたはチャネルを用いた認証バイパス(CWE-288)で、N-central 2026.1までが影響を受けます。CVSSはv4.0で8.2、v3.1で7.4。MSP(マネージドサービスプロバイダ)が顧客環境を一括管理するRMMプラットフォームであるため、1つの侵害が下流の多数の顧客へ波及しうる構造を持ちます。詳細な修正経緯は本記事では追い切れていません(未確認)。

対応策: パッチ・緩和・侵害確認

まず稼働中のLangflowのバージョンを確認します。

# pip / uv でインストールしている場合
pip show langflow | grep -i version
 
# Dockerで動かしている場合(イメージタグを確認)
docker ps --format '{{.Image}}' | grep -i langflow

1.10.1より前であれば影響を受けます。IBMは1.10.1へのアップグレードを推奨しており、回避策は「None」と明記しています。実際の運用では、後続の安定版(1.10.x系の最新、または1.11.x系)への追随も検討してください。

• LANGFLOW_AUTO_LOGIN=Falseを設定する。あわせてLANGFLOW_SUPERUSER_PASSWORDを設定します(未設定だとフェイルクローズします)。本番ではLANGFLOW_SECRET_KEYも明示的に設定してください。
• リバースプロキシで問題のエンドポイントを遮断する。信頼できない送信元からの/api/v1/auto_loginと/api/v1/validate/codeへのアクセスをブロックします。

# nginx でのアクセス制限の例(信頼できる管理ネットワークのみ許可)
location ~ ^/api/v1/(auto_login|validate/code) {
    allow 10.0.0.0/8;
    deny  all;
    proxy_pass http://langflow_backend;
}

• そもそもインターネットへ直接公開しない。LangflowのUIとAPIは、VPNや踏み台、あるいは認証プロキシの背後に置くのが基本です。
• 実行ユーザーの権限を絞る。コンテナを非rootで動かし、不要な権限やホストマウントを外します。仮にコード実行を許してしまっても、その後の被害範囲を狭められます。

具体的な攻撃ペイロードは公開されていないため、以下は一般的な観点です。

• アクセスログに/api/v1/auto_loginや/api/v1/validate/codeへの、想定外の送信元からのリクエストがないか。特に短時間で両者が連続して呼ばれているパターンは要注意です。
• Langflowプロセスからの予期しない子プロセス生成がないか(シェル、curl、wget、パッケージマネージャの起動など)。
• Langflowホストからの予期しないアウトバウンド通信がないか。
• 見覚えのないファイルの作成、cronやsystemdのユニット追加、SSH公開鍵の追加がないか。
• Langflow内に保存されているLLMプロバイダのAPIキーやデータベース接続情報など、認証情報への予期しないアクセスがないか。

Langflowは性質上、多数の外部サービスの認証情報を抱え込みます。侵害の可能性がある場合、優先度が最も高いのは資格情報のローテーションです。

• Langflowに登録済みのすべてのAPIキー(LLMプロバイダ、ベクトルDB、外部SaaS)を無効化して再発行する。
• LANGFLOW_SECRET_KEYを再生成し、暗号化保存されている値を再登録する。
• Langflowのユーザーアカウントとトークンを棚卸しする。前述のとおり脆弱な版は365日有効なトークンを発行していたため、パッチ適用だけでは既に配られたトークンが失効しない可能性があります。
• ホスト自体をクリーンな状態から再構築することも検討する。任意コード実行が成立していた場合、アプリのアップグレードだけでは永続化を除去できません。なお、ログとディスクイメージは封じ込めの前に保全してください。

Langflowが繰り返しKEVに載っている事実

見過ごせないのが、LangflowのKEV掲載回数です。CISA KEVカタログのJSONを検索すると、Langflow関連のエントリは本CVEを含めて次のとおりです。

2026年3月以降だけで5件、しかも2026年7月7日、7月21日、8月4日と、直近1か月で3件が立て続けにKEV入りしています。さらに注目すべきは、2025年5月にKEV入りしたCVE-2025-3248がまさに同じ/api/v1/validate/codeエンドポイントの問題だったことです。1年以上の間隔をおいて、同じエンドポイントが再び実悪用される事態になっています。

v1.10.1のリリースノートを読むと、今回の2件以外にも「Tweaks API経由のコードインジェクション遮断」「公開ユーザー自己登録の制限」「/api/v2/registration/への認証必須化」「ワイルドカードCORSでのクレデンシャル無効化」「PythonREPL実行のallow_custom_componentsによるゲート」など、セキュリティ修正が大量に並んでいます。1つのリリースでこれだけの修正が入るということは、製品全体のセキュリティレビューが集中的に行われたことを意味します。裏を返せば、それ以前のバージョンには類似の問題が広く残っていた可能性が高いということです。

AIワークフロー基盤やエージェント実行環境が新たな攻撃面になっている構造については、AIエージェントとMCPを狙うプロンプトインジェクションからRCEへの経路でも扱っています。

教訓: 「コードを実行するのが仕事」の製品をどう守るか

Langflowのようなワークフロー基盤は、ユーザーが書いたPythonコードをコンポーネントとして実行することが機能そのものです。「任意コード実行」がバグではなく仕様である以上、守り方は一般的なWebアプリとは変わってきます。

• 実行できる人を厳密に絞る。コード実行に到達できる経路すべてに、例外なく認証と認可を課します。「検証だけ」「プレビューだけ」と称するエンドポイントも、内部でコードを触るなら実行系として扱う必要があります。今回はまさにその境界が崩れました。
• 実行そのものを隔離する。アプリケーションプロセスと同じ権限・同じネットワーク名前空間でユーザーコードを走らせない。コンテナやサンドボックスへ分離し、egressも制限します。
• 既定値を本番前提で決める。開発体験のための緩い既定値は、必ず本番へ漏れ出します。緩い挙動を採用するなら、起動時に警告を出す、あるいは明示的なオプトインを要求するのが安全側です。
• 秘密情報の集中を前提に設計する。この種の基盤は多数の外部サービス認証情報を保持します。侵害時のブラスト半径は、Langflowホスト1台の話では終わりません。

LangChainなどのフレームワークを使った自前実装でも、ユーザー入力からコード実行経路へ到達しうる設計になっていないかは点検する価値があります(LangChain.jsの入門解説)。

まとめ

CVE-2026-9198は、Langflow OSSの2つのエンドポイントを連鎖させることで成立する未認証リモートコード実行です。CVSS v3.1で9.8、CWE-94、影響範囲は1.0.0から1.10.0まで、修正は1.10.1、IBMによれば回避策はありません。CISAは2026年8月4日にKEVへ追加し、是正期限を8月7日に設定しました。

• 今すぐ確認: 稼働中のLangflowが1.10.1より前でないか。LANGFLOW_AUTO_LOGINの値と、UIやAPIがインターネットから到達可能かどうか。
• 修正: Langflow OSS 1.10.1以降へアップグレードする。回避策はない。
• 緩和: LANGFLOW_AUTO_LOGIN=FalseとLANGFLOW_SUPERUSER_PASSWORDを設定し、リバースプロキシで/api/v1/auto_loginと/api/v1/validate/codeを信頼できるネットワークに限定する。
• 侵害確認: 両エンドポイントへのアクセスログ、Langflowプロセスからの子プロセス生成と外向き通信、認証情報への異常なアクセスを点検する。侵害が疑われる場合は保持しているAPIキーを全面的にローテーションする。

攻撃者の身元、悪用開始の正確な時期、被害組織数、実際に観測されたペイロードは一次情報で確認できなかったため、本文で「未確認」と明示しました。確定情報は必ずIBMのセキュリティ速報とCISA KEVカタログでご確認ください。2026年の主要なセキュリティ事案を横断的に振り返るには、2026年の主要セキュリティインシデントまとめもあわせてどうぞ。

参考リンク

• IBM Security Bulletin: Unauthenticated Remote Code Execution via Auto-Login Bypass and Code Validation
• NVD: CVE-2026-9198
• CISA: Adds Three Known Exploited Vulnerabilities to Catalog(2026年8月4日)
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: BOD 26-04 Prioritizing Security Updates Based on Risk
• Langflow OSS v1.10.1 リリースノート
• langflow-ai/langflow PR #13696: do not execute code in validate_code
• langflow-ai/langflow PR #13699: stop issuing 365-day superuser token via auto_login
• Langflow ドキュメント: API keys and authentication
• Langflow 公式サイト
• NVD: CVE-2026-34486(Apache Tomcat)
• NVD: CVE-2026-18556(N-able N-central)
• Metasploit Framework PR #21753: Exploit module for CVE-2026-9198
• The Hacker News: CISA Flags Langflow RCE, Tomcat, and N-central Flaws as Actively Exploited
• BleepingComputer: CISA warns of hackers exploiting Langflow, N-central, Apache Tomcat flaws
• SecurityWeek: CISA Warns of Exploited Langflow, N-central, and Tomcat Vulnerabilities