情報取得日: 2026/07/17/最終確認: 2026/08/01・本ページは公開情報の非公式まとめです
| CVE ID | CVE-2026-9198 |
|---|---|
| 製品 | IBM / Langflow OSS(1.0.0 以上 1.10.1 未満) |
| CVSS | 9.8(Critical) CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| 種別 (CWE) | CWE-94(生成するコードの制御が不適切=コードインジェクション) |
| 登録/公開日 | 2026/07/17 |
| KEV 期限 | 2026/08/07 まで(米国連邦機関向け目安) |
| 推奨対応 | ベンダーの指示に従って緩和策を適用し、CISA の BOD 26-04(リスクに基づくセキュリティ更新の優先順位付け)と「Forensics Triage Requirements」に従うこと。クラウドサービスについては BOD 26-04 の該当ガイダンスに従い、緩和策が無い場合は当該製品の使用を停止すること。資産のインターネット露出の評価と BOD 26-04 のパッチ適用ガイドラインの遵守は各利用者の責任とされている。 |
| 出典 | https://nvd.nist.gov/vuln/detail/CVE-2026-9198 |
IBM Langflow に、**認証なしで到達できる2つの API エンドポイントを連鎖させることで、既定構成のままリモートからコードを実行できる**欠陥がある。NVD の説明は「IBM Langflow OSS versions 1.0.0 through 1.10.0 contain a vulnerability allowing unauthenticated attackers to chain two API endpoints to achieve remote code execution on default deployments.」である。 Langflow は、大規模言語モデル(LLM)を使ったアプリケーションを、画面上でノードをつないで組み立てるための OSS のツールである。この種のツールは性質上、利用者が書いた式やコードを実行する機能を内側に持っている。本件はその実行経路が、認証を通さずに外から叩けるエンドポイントの組み合わせで到達できてしまう、という形の脆弱性である。 CVSS は 9.8 CRITICAL(CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)で、評価元は IBM である。ベクタを読むと、攻撃はネットワーク経由(AV:N)で、条件は容易(AC:L)、**権限は不要(PR:N)**、利用者の操作も不要(UI:N)、機密性・完全性・可用性のすべてに高い影響がある。前提条件がほぼ何も無い型であり、露出していれば踏まれると考えるべき水準である。 **「default deployments(既定構成)で成立する」と明記されている点が重要である。** 設定を誤った環境だけの話ではない。ドキュメントどおりに立てた環境が、そのまま対象になる。開発中に手元で立てて、そのままどこかのネットワークに置き去りにされた個体が最も危ない。 CISA KEV には 2026年8月4日に追加され、**是正期限は 2026年8月7日**である。KEV に載っているということは、**実際に悪用が観測されている**という意味である。ランサムウェアでの利用は「Unknown(不明)」とされている。 影響を受けるのは NVD の版レンジで **1.0.0 以上 1.10.1 未満**、すなわち 1.0.0 から 1.10.0 までである。**修正版は 1.10.1** である。
各ベンダー公式アドバイザリで確認できた事実に基づき整理しています。確認できていない項目は「情報確認中」と明記し、存在しないパッチ番号・バージョンは記載しません。
| 環境 | 対応状況 | 対応方法・備考 |
|---|---|---|
| AWS (ECS/EC2) | 情報確認中 |
EC2 / ECS / EKS 上の Langflow を 1.10.1 以降へ更新する。コンテナはイメージタグを差し替えて再作成する
更新までの緩和として、セキュリティグループで 7860 への送信元を運用者の IP に限定する。ALB を前段に置いている場合はリスナーの認証(OIDC)を必須にできる。棚卸しは ECR のイメージ一覧と SSM Inventory の pip パッケージ収集が使える
|
| GCP | 情報確認中 |
Compute Engine / GKE / Cloud Run 上の Langflow を 1.10.1 以降へ更新する
更新までの緩和として、VPC ファイアウォールで 7860 への到達を制限する。Cloud Run で公開している場合は未認証の呼び出しを無効化し、IAP を前段に置く。棚卸しは Artifact Registry のイメージ一覧が入口になる
|
| Azure | 情報確認中 |
Azure VM / AKS / Container Apps 上の Langflow を 1.10.1 以降へ更新する
更新までの緩和として、ネットワークセキュリティグループで 7860 への受信を制限する。Application Gateway や Front Door を前段に置いている場合は Entra ID 認証を必須にできる
|
| Linux | 情報確認中 |
pip 導入なら `pip install --upgrade 'langflow>=1.10.1'`、コンテナならイメージを 1.10.1 以降へ差し替える
ディストリビューションのパッケージではなく PyPI / コンテナイメージで配布される製品なので、OS のパッケージ更新では直らない。`pip list | grep -i langflow` を全ホストで実行して版を集計するのが確実
|
最初にやることは、パッチではなく**棚卸し**である。Langflow は基盤に組み込まれる製品ではなく、検証や試作のために個人が立てることが多い。したがって、資産台帳に載っていない個体が存在する前提で探す必要がある。 探し方は3つある。第一に、コンテナのイメージ名で探す。`docker ps` や Kubernetes の Pod 一覧から `langflow` を含むイメージを洗い出す。第二に、Python の環境から探す。`pip list | grep -i langflow` を配布して集計する。第三に、公開されているポートから探す。Langflow の既定ポートは 7860 で、社内・クラウド双方で 7860 が外に出ていないかを確認する。 バージョンの確認は `pip show langflow` の Version、またはコンテナのイメージタグで行う。**1.10.1 未満であれば対象**である。 恒久対応は **1.10.1 以降への更新**である。IBM のアドバイザリ(https://www.ibm.com/support/pages/node/7278927)が一次情報になる。pip 導入なら `pip install --upgrade 'langflow>=1.10.1'`、コンテナならイメージタグを 1.10.1 以降に差し替えて再作成する。 更新までの緩和策は、**到達経路を断つこと**に尽きる。認証が不要な脆弱性なので、アプリケーション側の設定で塞ぐ手立ては期待できない。具体的には、7860 を含む待ち受けポートをインターネットから見えない位置へ移す、セキュリティグループやファイアウォールで送信元を運用者の IP に限定する、リバースプロキシの前段で認証を必須にする、のいずれかである。**それも難しい個体は、更新まで停止するのが最も確実である。** CISA の要求アクションが挙げる「緩和策が無ければ使用を停止する」は、この製品については現実的な選択肢になる。試作用のインスタンスを止めて困る人は少ない。 侵害の有無を見るなら、着目点は「コードが実行された痕跡」である。Langflow のプロセス(Python)から、想定外の子プロセスが生えていないかを確認する。具体的には `sh` / `bash` / `curl` / `wget` / `python -c` の起動、および外向きの新しい通信先である。コンテナで動かしている場合は、イメージに含まれないバイナリがファイルシステムに書かれていないかも見る。加えて、Web アクセスログで **認証を伴わない POST が2つのエンドポイントに連続して届いている**パターンを探す。 優先順は明確である。**インターネットから到達できる個体が最優先**で、これは是正期限(2026年8月7日)を待たずに今日中に塞ぐ対象である。次が社内ネットワークに露出している個体、最後がローカル専用の個体になる。棚卸しの網羅性のほうが、パッチ作業そのものより難しい点であることを見誤らないほうがよい。
Critical(CVSS 9.8)に分類されるIBM Langflow OSS(1.0.0 以上 1.10.1 未満)の脆弱性です。IBM Langflow に、**認証なしで到達できる2つの API エンドポイントを連鎖させることで、既定構成のままリモートからコードを実行できる**欠陥がある。NVD の説明は「IBM Langflow OSS versions 1.0.0 through 1.10.0 contain a vulnerability allowing unauthenticated attackers to chain two API endpoints to achieve remote code execution on default deployments.」である。 Langflow は、大規模言語モデル(LLM)を使ったアプリケーションを、画面上でノードをつないで組み立てるための OSS のツールである。この種のツールは性質上、利用者が書いた式やコードを実行する機能を内側に持っている。本件はその実行経路が、認証を通さずに外から叩けるエンドポイントの組み合わせで到達できてしまう、という形の脆弱性である。 CVSS は 9.8 CRITICAL(CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)で、評価元は IBM である。ベクタを読むと、攻撃はネットワーク経由(AV:N)で、条件は容易(AC:L)、**権限は不要(PR:N)**、利用者の操作も不要(UI:N)、機密性・完全性・可用性のすべてに高い影響がある。前提条件がほぼ何も無い型であり、露出していれば踏まれると考えるべき水準である。 **「default deployments(既定構成)で成立する」と明記されている点が重要である。** 設定を誤った環境だけの話ではない。ドキュメントどおりに立てた環境が、そのまま対象になる。開発中に手元で立てて、そのままどこかのネットワークに置き去りにされた個体が最も危ない。 CISA KEV には 2026年8月4日に追加され、**是正期限は 2026年8月7日**である。KEV に載っているということは、**実際に悪用が観測されている**という意味である。ランサムウェアでの利用は「Unknown(不明)」とされている。 影響を受けるのは NVD の版レンジで **1.0.0 以上 1.10.1 未満**、すなわち 1.0.0 から 1.10.0 までである。**修正版は 1.10.1** である。
最初にやることは、パッチではなく**棚卸し**である。Langflow は基盤に組み込まれる製品ではなく、検証や試作のために個人が立てることが多い。したがって、資産台帳に載っていない個体が存在する前提で探す必要がある。 探し方は3つある。第一に、コンテナのイメージ名で探す。`docker ps` や Kubernetes の Pod 一覧から `langflow` を含むイメージを洗い出す。第二に、Python の環境から探す。`pip list | grep -i langflow` を配布して集計する。第三に、公開されているポートから探す。Langflow の既定ポートは 7860 で、社内・クラウド双方で 7860 が外に出ていないかを確認する。 バージョンの確認は `pip show langflow` の Version、またはコンテナのイメージタグで行う。**1.10.1 未満であれば対象**である。 恒久対応は **1.10.1 以降への更新**である。IBM のアドバイザリ(https://www.ibm.com/support/pages/node/7278927)が一次情報になる。pip 導入なら `pip install --upgrade 'langflow>=1.10.1'`、コンテナならイメージタグを 1.10.1 以降に差し替えて再作成する。 更新までの緩和策は、**到達経路を断つこと**に尽きる。認証が不要な脆弱性なので、アプリケーション側の設定で塞ぐ手立ては期待できない。具体的には、7860 を含む待ち受けポートをインターネットから見えない位置へ移す、セキュリティグループやファイアウォールで送信元を運用者の IP に限定する、リバースプロキシの前段で認証を必須にする、のいずれかである。**それも難しい個体は、更新まで停止するのが最も確実である。** CISA の要求アクションが挙げる「緩和策が無ければ使用を停止する」は、この製品については現実的な選択肢になる。試作用のインスタンスを止めて困る人は少ない。 侵害の有無を見るなら、着目点は「コードが実行された痕跡」である。Langflow のプロセス(Python)から、想定外の子プロセスが生えていないかを確認する。具体的には `sh` / `bash` / `curl` / `wget` / `python -c` の起動、および外向きの新しい通信先である。コンテナで動かしている場合は、イメージに含まれないバイナリがファイルシステムに書かれていないかも見る。加えて、Web アクセスログで **認証を伴わない POST が2つのエンドポイントに連続して届いている**パターンを探す。 優先順は明確である。**インターネットから到達できる個体が最優先**で、これは是正期限(2026年8月7日)を待たずに今日中に塞ぐ対象である。次が社内ネットワークに露出している個体、最後がローカル専用の個体になる。棚卸しの網羅性のほうが、パッチ作業そのものより難しい点であることを見誤らないほうがよい。
IBM Langflow OSS(1.0.0 以上 1.10.1 未満) を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報(https://nvd.nist.gov/vuln/detail/CVE-2026-9198)で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド/OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。
はい。CISA の既知の悪用された脆弱性カタログ(KEV)に登録されており、実環境での悪用が確認されています。米国連邦機関向けの対応期限の目安は 2026/08/07 です。推奨される対応: ベンダーの指示に従って緩和策を適用し、CISA の BOD 26-04(リスクに基づくセキュリティ更新の優先順位付け)と「Forensics Triage Requirements」に従うこと。クラウドサービスについては BOD 26-04 の該当ガイダンスに従い、緩和策が無い場合は当該製品の使用を停止すること。資産のインターネット露出の評価と BOD 26-04 のパッチ適用ガイドラインの遵守は各利用者の責任とされている。
本ページの記載は下記の一次情報に基づく非公式まとめです。数値・対応状況は各出典元で最終確認してください(最終確認: 2026/08/01)。