はじめに
2025 年以降、多くの組織が検証目的で LLM ワークフロー構築ツールを立ち上げ、そのまま運用へ移行しています。Langflow はその代表格ですが、この 15 か月あまりで 10 件の CVE が公表され、うち複数が実環境での悪用を理由に CISA の KEV カタログへ登録されています。 2026 年 8 月 4 日には、CVE-2026-9198 が新たに追加されました。
問題は件数そのものではありません。これらが同じ構造から繰り返し生じており、修正のたびに別の経路で迂回されてきた点にあります。個別の CVE を追いかけて修正版を当てる対応では、次の CVE が公表された時点で同じ作業に戻ることになります。
- CVE-2026-9198 の内容と、同日公表の CVE-2026-9103 との関係
- これまでに公表された Langflow の CVE 10 件と、CISA による判定値の一覧
- 修正が繰り返し迂回されてきたパターンの整理
- 個別対処ではなく、既定設定と配置で押さえるという対処の考え方
- BOD 26-04 の枠組みで評価した場合の対応期限
結論として、Langflow の脆弱性に対しては、バージョン追随を主軸に据えるより、既定で有効なオートログインの無効化とネットワーク面の到達制限を恒久的な前提条件として組み込むほうが実効性があります。 公表済み 10 件のうち、CISA が技術的影響を判定している全件が Total control、すなわちホストの完全な制御を奪われ得ると評価されている点も、この判断を裏づけます。
なお、具体的な設定値や緩和策の優先順位は、関連記事『Langflow CVE-2026-0770｜認証不要 RCE のリスクと緊急緩和策』で詳しく扱っています。本記事は、その前提となる構造の理解に焦点を当てます。
CVE-2026-9198 の概要と KEV 登録
CVE-2026-9198 は、認証を経ずに取得したスーパーユーザートークンを用いて、コード検証エンドポイントで任意の Python コードを実行できる脆弱性です。採番元は IBM で、2026 年 7 月 17 日に公表されました。
| 項目 | 内容 |
|---|---|
| CVE ID | CVE-2026-9198 |
| CWE | CWE-94（コード生成の不適切な制御） |
| CVSS v3.1 | 9.8（AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H、評価元は IBM） |
| 影響バージョン | Langflow OSS 1.0.0 から 1.10.0 |
| 修正版 | 1.10.1 |
| 公表日 | 2026 年 7 月 17 日 |
| KEV 登録日 | 2026 年 8 月 4 日 |
IBM のセキュリティ速報では、回避策および緩和策の欄が「None」とされています。この記載は、製品側の設定で本脆弱性そのものを無効化する手段が提供されていないことを意味します。後述するとおり、実際には到達経路を断つ形での緩和は可能です。
auto_login を認証迂回として CVE 化した意味
本脆弱性は、2 つのエンドポイントの連鎖として成立します。
/api/v1/auto_login: 認証なしでスーパーユーザーのトークンを発行する/api/v1/validate/code: 受け取った Python コードをexec()で実行する
後者は Langflow のカスタムコンポーネント機能を支える処理で、利用者が記述したコードの妥当性を検証するために存在します。過去の CVE-2025-3248 では、このエンドポイントが未認証で到達可能であったことが問題となり、認証の追加によって修正されました。
CVE-2026-9198 が示したのは、その認証そのものを正規の機能で迂回できるという事実です。 オートログインは既定で有効なため、攻撃者はネットワークに到達できさえすれば、認証を突破する必要すらなくトークンを取得できます。認証を追加した修正は、認証機構が実質的に機能していることを前提としていましたが、その前提が既定設定によって崩れていた形になります。
なお、コードを実行するのは関数の「定義」の段階です。Python では関数定義時にデコレーターやデフォルト引数の式が評価されるため、関数を呼び出さなくてもコード実行が成立します。この点は既存記事でも触れているとおりで、「検証しているだけ」という理解が成り立たない理由です。
CVE-2026-9103 と 2 件に分けられた構造
見落とされやすいのが、同日に CVE-2026-9103 が別途公表されている点です。両者の関係を整理すると、この脆弱性の性質がより明確になります。
| CVE-2026-9103 | CVE-2026-9198 | |
|---|---|---|
| 内容 | オートログインによるトークン発行 | トークン取得とコード実行の連鎖 |
| CWE | CWE-306（重要な機能の認証欠如） | CWE-94（コード生成の不適切な制御） |
| CVSS v3.1 | 9.8 | 9.8 |
| 影響バージョン | 1.0.0 から 1.10.0 | 1.0.0 から 1.10.0 |
| KEV 登録 | なし | 2026 年 8 月 4 日 |
CVE-2026-9103 は、CVE-2026-9198 の前半部分を単独で切り出したものです。 IBM は、トークンが認証なしで発行されること自体を独立した脆弱性として採番し、それを悪用してコード実行に至る連鎖を別の CVE としています。
CVE-2026-9103 の説明では、次のように記述されています。
参考: CVE-2026-9103（CVE Program）
“issues long-lived superuser bearer tokens without requiring authentication”
（認証を要求せずに、長期間有効なスーパーユーザーのベアラートークンを発行する）
https://www.cve.org/CVERecord?id=CVE-2026-9103
同記述では、AUTO_LOGIN の設定が既定で有効であることが明示されています。あわせて、緩いオリジン間リソース共有（CORS）の設定により、トークンが意図しないオリジンへ露出し得る点にも言及されています。
2 件に分かれていることは、対処を検討するうえで実務的な意味を持ちます。トークン発行の欠陥そのものを塞がない限り、コード実行側のエンドポイントを 1 つ修正しても、別のエンドポイントとの新たな連鎖が成立し得るためです。実際、CVE-2026-5027 のパストラバーサルでも、同じオートログインが前段の到達手段として利用されることが指摘されています。
また、CISA の判定にも差があります。CVE-2026-9103 は悪用状況が none とされ KEV に登録されていない一方、連鎖である CVE-2026-9198 は active と判定され登録されました。単独の欠陥ではなく、連鎖して成立する経路が実際に狙われていることを示しています。
KEV 登録された Langflow 脆弱性の系譜
個別の CVE を並べるだけでは構造が見えません。公表順に判定値とあわせて整理すると、繰り返しの輪郭が浮かび上がります。
10 件の CVE と判定値の一覧
以下は、CVE レコードの CISA-ADP コンテナに記録されている判定値です。悪用状況、自動化可能性、技術的影響はいずれも CISA の Vulnrichment による評価です。
| CVE | 公表 | KEV 登録 | 悪用 | 自動化 | 技術的影響 | 概要 |
|---|---|---|---|---|---|---|
| CVE-2025-3248 | 2025-04-07 | 2025-05-05 | active | yes | total | validate/code の未認証 RCE |
| CVE-2026-0770 | 2026-01-23 | 2026-07-21 | active | yes | total | exec_globals の制限不備 |
| CVE-2026-33017 | 2026-03-20 | 2026-03-25 | active | yes | total | 公開フロー構築エンドポイント経由の RCE |
| CVE-2026-5027 | 2026-03-27 | — | none | no | total | ファイルアップロードのパストラバーサル |
| CVE-2026-6543 | 2026-04-30 | — | none | no | total | 認証済みでのコード実行 |
| CVE-2026-10561 | 2026-06-22 | — | none | yes | total | PythonREPL の組み込み関数注入 |
| CVE-2026-7664 | 2026-06-22 | — | none | yes | total | Webhook 経由の未認証フロー実行 |
| CVE-2026-55255 | 2026-06-23 | 2026-07-07 | active | no | total | responses エンドポイントの IDOR |
| CVE-2026-9103 | 2026-07-17 | — | none | yes | total | auto_login のトークン発行 |
| CVE-2026-9198 | 2026-07-17 | 2026-08-04 | active | yes | total | 上記トークンとコード実行の連鎖 |
15 か月で 10 件が公表され、うち 5 件が KEV に登録されています。 2026 年 7 月だけで 3 件が登録されており、頻度は上がっています。
この表を読むにあたって、2 つの注意点があります。
1 つ目は、ADP の判定値がすべてを反映しているとは限らない点です。CVE-2026-55255 は CISA が 7 月 7 日に KEV 追加を告知していますが、CVE レコードの ADP コンテナに KEV のブロックが確認できません。同様に CVE-2026-5027 は悪用状況が none と記録されている一方、複数のセキュリティベンダーがハニーポットでの悪用観測を報告しています。判定値は KEV 登録に連動する形で更新されるため、第三者の観測がそのまま反映されるわけではありません。
2 つ目は、CVSS スコアが情報源によって大きく割れている点です。CVE-2026-55255 については、6.1、8.4、9.9 という 3 通りのスコアが流通しています。同じ脆弱性でありながら評価元によって「中程度」から「緊急」まで振れる状況は、スコアを優先順位付けの主軸に据えることの難しさを示しています。
全件が Total control と判定されている意味
表を通して見たとき、最も注目すべきは技術的影響の列です。10 件すべてが Total control と判定されています。
CISA の判定基準では、攻撃者が任意のソフトウェアを実行できるか、対象コンポーネントの完全な権限を持つアカウントを取得できるかといった問いのいずれかに該当すれば Total control となります。IDOR やパストラバーサルのように、一見すると影響が限定的に見える脆弱性まで含めて全件がこの判定になっている事実は、Langflow というアプリケーションの性質を反映しています。
Langflow は、LLM プロバイダーの API キー、データベース接続情報、外部サービスの認証情報をフロー定義の中に保持します。加えて、フローの実行そのものが任意のコードを動かす行為に近い設計です。したがって、どの経路であれ内部へ到達できれば、結果として得られるものは同じという構造になっています。
実際の攻撃でも、この性質が利用されています。Sysdig の調査によると、2026 年 6 月 25 日にインターネットへ公開された Langflow インスタンスに対し、認証周りの偵察、フローの列挙、CVE-2026-55255 による他ユーザーのフロー実行、CVE-2026-33017 による RCE の反復という一連の流れが観測されました。目的は LLM プロバイダーの鍵と AWS の鍵の窃取とされています。
参考: The Hacker News（Sysdig の見解を引用）
“AI orchestration platforms are a trove of credentials in their own right”
（AI オーケストレーション基盤は、それ自体が認証情報の宝庫である）
https://thehackernews.com/2026/07/cisa-adds-4-actively-exploited-adobe.html
攻撃者は 1 つの CVE を狙っているのではなく、到達できた経路を順に試しています。 個別の CVE への対処を積み上げる発想が機能しにくい理由がここにあります。
修正が繰り返し迂回されるパターン
10 件を修正の系譜として並べ直すと、2 つのパターンが見えてきます。
認証を足す修正と、その認証を迂回する脆弱性
1 つ目は、認証の追加をめぐる循環です。
出発点は CVE-2025-3248 でした。 /api/v1/validate/codeが未認証で到達可能であったため、任意の Python コードを実行できる状態にありました。修正は 1.3.0 で行われ、当該エンドポイントに認証が追加されています。
ところが、この修正は 2 つの前提の上に成り立っていました。1 つは「認証済みユーザーは信頼できる」という前提、もう 1 つは「認証が実際に機能している」という前提です。その後の CVE は、この 2 つの前提をそれぞれ崩しています。
前者を崩したのが CVE-2026-6543 です。認証済みであればコード実行が可能な状態は残っており、認証の追加は実行そのものを止める措置ではありませんでした。多くの組織で Langflow が複数の利用者で共有されていることを踏まえると、認証済みであることは信頼の根拠になりません。
後者を崩したのが CVE-2026-9103 と CVE-2026-9198 です。オートログインが既定で有効である以上、認証機構は攻撃者にとって障壁になりません。認証を追加した修正から 1 年あまりを経て、実質的には未認証で到達できる状態に戻っています。
この構造は、設定によっても補強されています。認証設定の切り替えには後方互換性のための変数が絡み、片方だけを無効化しても従来の挙動が維持される場合があります。具体的な環境変数の組み合わせと確認方法は、次章で示す関連記事で扱っています。
実行環境を制限する修正と、その外側を突く脆弱性
2 つ目は、コード実行の制限をめぐる循環です。
exec()によるコード実行を残したまま安全性を確保するには、実行時の名前空間を制限する必要があります。CVE-2026-0770 は、この制限が施されていなかったこと自体を突いたものです。 実行時に渡されるグローバル名前空間から標準ライブラリへ到達できるため、OS コマンドの実行に至ります。分類が CWE-829（信頼できない制御領域からの機能の取り込み）である理由もここにあります。
これを受けて名前空間を限定する対応が入りましたが、CVE-2026-10561 は、限定した辞書を構成する際に組み込み関数が無効化されていない点を突いています。 許可リストの設計そのものは導入されたものの、その外側に抜け道が残っていた形です。
さらに、実行処理そのものではなく到達経路を変えるという方向の脆弱性も並行して現れています。CVE-2026-33017 は公開フロー構築エンドポイントから、CVE-2026-7664 は Webhook エンドポイントから、それぞれ同じコード実行へ到達します。入口を 1 つ塞いでも、同じ処理へ通じる別の入口が残っているという構図です。
2 つのパターンを重ねると、対処の方針が導かれます。認証の追加も名前空間の制限も、いずれも「アプリケーションの内部で安全性を確保する」アプローチであり、その都度別の経路で迂回されてきました。 バージョン追随を主軸に据える限り、この循環から抜けられません。次章では、この前提に立った対処の考え方を整理します。
対処の考え方
前章までの整理を踏まえると、対処の方針は「個別 CVE への追随」から「前提条件の固定」へ移すことになります。ここでは考え方のみを扱います。具体的な環境変数、設定値、緩和策の優先順位については、関連記事『Langflow CVE-2026-0770｜認証不要 RCE のリスクと緊急緩和策』で詳しく整理しています。
認証の追加も名前空間の制限も、いずれもアプリケーション内部で完結する対策であり、その都度迂回されてきました。一方、ネットワーク層で到達できる範囲を絞る措置は、どのエンドポイントに新しい欠陥が見つかっても効果が変わりません。インターネットからの直接到達をなくし、VPN や踏み台、あるいは前段で認証を行うリバースプロキシを経由する構成へ寄せることが、最も費用対効果の高い措置になります。
オートログインが既定で有効である以上、構築時にこれを無効化していない環境は、公表済みの脆弱性の多くについて前提条件を満たした状態にあります。ただしこれは必要条件であって十分条件ではありません。 CVE-2026-6543 のように認証済みでも成立する脆弱性が存在するため、認証を有効にしたことをもって対処完了とはできません。
公表済み 10 件すべてが Total control と判定されている以上、侵害を防ぎきる前提には立てません。プロセスの実行権限を下げること、フロー定義に認証情報を直接持たせずシークレット管理サービスへ分離すること、ホストからの外向き通信を必要な宛先に限ることが、実際の被害の大きさを左右します。クラウド上で稼働している場合は、インスタンスメタデータへのアクセス制限も同様に効きます。
修正版の適用には当然価値がありますが、公表から KEV 登録までの間隔が短くなっている状況では、追随だけで先回りすることは困難です。
そして前提として、資産の棚卸しが必要になります。 検証目的で立ち上げたインスタンスが、担当者の異動や案件の終了を経て残っているケースは珍しくありません。どこで何が動いているかを把握できていない状態では、上記のいずれの措置も適用できません。
BOD 26-04 で評価すると 3 日＋フォレンジック調査
CVE-2026-9198 は KEV に登録されているため、CISA の BOD 26-04 における対応期限を判定できます。ADP コンテナに記録されている値は次のとおりです。
| 変数 | 値 |
|---|---|
| KEV 掲載 | Yes（2026 年 8 月 4 日追加） |
| 悪用の自動化可能性 | Yes |
| 技術的影響 | Total control |
| 外部公開 | 自組織で判定 |
この組み合わせでは、外部公開の有無にかかわらず 3 日＋フォレンジック調査という最も厳しい階層に入ります。 KEV に掲載され、技術的影響が Total control であり、外部公開または自動化可能のいずれかを満たす場合が該当するためで、自動化可能が Yes である本脆弱性は、閉じたネットワークにあっても同じ扱いになります。
この判定は、実際の運用とも符合しています。CISA が示した是正期限を見ると、CVE-2026-55255 は KEV 登録が 7 月 7 日で期限が 7 月 10 日、CVE-2026-0770 は登録が 7 月 21 日で期限が 7 月 24 日と、いずれも 3 日です。Table 1 の最上位階層が、そのまま現実の期限として運用されていることが確認できます。
先に扱った Apache Tomcat の CVE-2026-34486 と比べると差が明確です。あちらは技術的影響が Partial control と判定されているため 14 日の階層に入りますが、Langflow の各脆弱性は Total control であるため 3 日となります。同じ KEV 登録であっても、技術的影響の判定次第で期限が 3 日と 14 日に分かれます。 判定の枠組みと 16 通りの組み合わせの全体像は、関連記事『BOD 26-04 とは｜KEV と外部公開で決まる対応期限の読み方』で整理しています。
フォレンジック調査が要件となる点も見過ごせません。これは修正の適用と並行して、既に侵害を受けていないかを確認することを求めるものです。Langflow については実際の悪用が観測され、認証情報の窃取が目的とされている以上、この要件は形式的なものではありません。公開状態で運用していた期間がある場合は、修正版の適用だけで完了とせず、アクセスログの確認と保持していた認証情報の失効・再発行を検討することをおすすめします。
まとめ
Langflow では 15 か月で 10 件の CVE が公表され、うち 5 件が KEV へ登録されています。認証の追加と実行環境の制限という 2 系統の修正が、その都度別の経路で迂回されてきた経緯があり、バージョン追随を主軸に据える対処は機能しにくい状況です。公表済み 10 件すべてが Total control と判定されていることを踏まえ、到達経路の制限と既定設定の是正を恒久的な前提条件として組み込む方針をおすすめします。
- 15 か月で 10 件公表、うち 5 件が KEV 登録
- CVE-2026-9198 は auto_login とコード実行の連鎖
- 前段の欠陥は CVE-2026-9103 として別途採番
- 公表済み 10 件すべてが Total control と判定
- 認証追加も名前空間制限もその都度迂回されてきた経緯
- 最優先はネットワーク層での到達経路の制限
- BOD 26-04 では 3 日＋フォレンジック調査の階層に該当
以上、最後までお読みいただきありがとうございました。
