脆弱性対応ウォッチ重大・クリティカル脆弱性のクラウド別対応まとめ
最新更新履歴CriticalHigh回避策のみパッチありAWSGCPAzureLinux
Critical CVSS 9.8 KEV 悪用確認
CVE-2026-9198

IBM Langflow の未認証リモートコード実行(KEV 収載・是正期限 2026-08-07)

情報取得日: 2026/07/17/最終確認: 2026/08/01・本ページは公開情報の非公式まとめです

CVE IDCVE-2026-9198
製品IBM / Langflow OSS(1.0.0 以上 1.10.1 未満)
CVSS9.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** である。

クラウド/OS 別の対応状況

各ベンダー公式アドバイザリで確認できた事実に基づき整理しています。確認できていない項目は「情報確認中」と明記し、存在しないパッチ番号・バージョンは記載しません。

AWS / GCP / Azure / Linux いずれも対応区分は同じです: 情報確認中 下の表は環境ごとの補足です。
環境対応状況対応方法・備考
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日)を待たずに今日中に塞ぐ対象である。次が社内ネットワークに露出している個体、最後がローカル専用の個体になる。棚卸しの網羅性のほうが、パッチ作業そのものより難しい点であることを見誤らないほうがよい。

よくある質問(CVE-2026-9198)

CVE-2026-9198(Langflow OSS)の影響は?

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** である。

CVE-2026-9198 の対応方法・回避策は?

最初にやることは、パッチではなく**棚卸し**である。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日)を待たずに今日中に塞ぐ対象である。次が社内ネットワークに露出している個体、最後がローカル専用の個体になる。棚卸しの網羅性のほうが、パッチ作業そのものより難しい点であることを見誤らないほうがよい。

自分の環境が CVE-2026-9198 の影響を受けるか確認するには?

IBM Langflow OSS(1.0.0 以上 1.10.1 未満) を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報(https://nvd.nist.gov/vuln/detail/CVE-2026-9198)で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド/OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。

CVE-2026-9198 は実際に悪用されている?

はい。CISA の既知の悪用された脆弱性カタログ(KEV)に登録されており、実環境での悪用が確認されています。米国連邦機関向けの対応期限の目安は 2026/08/07 です。推奨される対応: ベンダーの指示に従って緩和策を適用し、CISA の BOD 26-04(リスクに基づくセキュリティ更新の優先順位付け)と「Forensics Triage Requirements」に従うこと。クラウドサービスについては BOD 26-04 の該当ガイダンスに従い、緩和策が無い場合は当該製品の使用を停止すること。資産のインターネット露出の評価と BOD 26-04 のパッチ適用ガイドラインの遵守は各利用者の責任とされている。

参考情報(出典)

本ページの記載は下記の一次情報に基づく非公式まとめです。数値・対応状況は各出典元で最終確認してください(最終確認: 2026/08/01)。

CISA KEV(悪用確認・対応期限・ランサム利用の出典)
NVD(CVE 基本情報・CVSS スコアの出典)
免責: 本ページは CISA KEV・NVD・各ベンダー公式アドバイザリ等の公開情報をもとにした非公式まとめです。修正バージョンや対応可否は変更される場合があります。実際の対応は必ず 出典元および各ベンダー公式情報・自環境で確認してください。

« 一覧に戻る