Langflowに新たに14件 CVE-2026-8182は認証不要、1.10.3も対象

【2026年8月6日 追記】さらに14件、今度はAI連携機能そのものが標的に。1.10.3も対象

2026年8月5日から6日にかけて、IBMがLangflow OSSの脆弱性をさらに14件公開しました。影響を受けるのは1.0.0から1.10.3まで。本記事がこれまで「更新先」として案内してきた1.10.1も1.10.2も、この14件では対象のままです。

最も重いのは CVE-2026-8182（CVSS 8.8）です。NVDの説明文はこう書いています。「インターネット上の誰もが、いかなる資格情報もなしに、2回のHTTPリクエストでサーバー上で任意のコードを実行できる」。IDもパスワードも要らず、たった2往復です。

そして、この14件には共通する性格があります。AIに外部ツールをつなぐ仕組み（MCP）と、AIが自動でフローを組み立てる支援機能に集中していることです。Langflowが売りにしている機能そのものが、そのまま攻撃の入口になっています。

CVE-2026-9196: AIが書いたコードを、人が見る前に走らせていた

14件のうち、最も性格を表しているのがこれです。CVSSは8.1で最上位ではありませんが、中身は他と質が違います。

Langflowには、やりたいことを伝えるとAIがフローの部品を自動で組み立ててくれる支援機能があります。NVDの説明によると、この機能はAIが生成したPythonコードを、利用者が内容を確認して承認する前に、検証と称してサーバー側で実行していました。

つまり、AIに悪意ある指示を紛れ込ませることができれば、人間が「これでいいですか」と聞かれる前に、そのコードはもう動き終わっています。外部への通信、ファイルの読み書き、データの持ち出しが、Langflowの権限で実行されます。

AIエージェントに作業を任せる仕組みが広がるなかで、「AIの出力を、人が見る前に実行してよいか」という問いが、そのまま脆弱性として番号を振られた形です。

AI連携（MCP）まわりで3件

MCPは、AIに外部のツールやデータをつなぐための共通の作法です。Langflowはこれに対応していますが、その設定の受け取り方に3件の欠陥がありました。

CVE-2026-17623（8.8）は、MCPサーバーの設定にある「実行するコマンド」の欄が検証されておらず、そのままOSのコマンドとして走ってしまうもの。CVE-2026-17626（8.8）は、Docker経由でMCPを動かすときの「どのフォルダを見せるか」「どの装置を使わせるか」の指定を十分に絞っておらず、サーバー本体のファイルまで読み書きできてしまうもの。CVE-2026-9077（8.5）は、本来その端末からしか触れないはずの制限を破って、開発者が使うエディタの設定ファイルにMCPの設定を勝手に書き込めるものです。

3件目は、影響が開発者の手元まで届く点で厄介です。書き込まれた設定は、そのエディタを次に立ち上げたときに読み込まれます。

上げる先が、また分からない

本記事はこれまで何度も、Langflowの「修正版がどこにも書かれていない」問題を扱ってきました。今回も同じです。

確実に言えるのは、1.10.3以下は全部対象だということだけです。1.10系を使い続ける限り、この14件は残ります。したがって現時点の行動としては、1.11系の最新（8月6日時点で1.11.2）へ上げるほかありません。ただしこれは「1.11.2で直っている」と確認できたという意味ではなく、「対象と明記された範囲の外に出る」という意味です。この違いは正直に書いておきます。

なお、8月4日に実際に攻撃されている脆弱性リスト（KEV）へ登録されたCVE-2026-9198の期限は8月7日、つまり明日です。同じ週に、同じ製品で、14件が積み増されました。

すぐに上げられない場合の応急策は、後半の「いま何をすべきか」がそのまま当てはまります。とくに今回はMCP連携とAI支援機能を使っていない環境なら、影響する範囲は狭くなります。使っていない機能は止めておくのが、いちばん確実です。

【2026年8月5日 追記】7月17日公開のCVE-2026-9198が実際の攻撃に ― 期限は8月7日

米CISAは2026年8月4日、LangflowのCVE-2026-9198（CVSS 9.8）を「実際に攻撃されている脆弱性リスト（KEV）」へ追加しました。米連邦機関に課された是正期限は8月7日で、登録から3日しかありません。本記事が7月17日のIBM一括公開分として扱ってきた1件で、そのときは「攻撃に使われた報告もKEV登録もない」と書いていました。状況が変わったため、本文の該当箇所も書き改めています。

目を引くのは、この欠陥の入り口が本記事の主題であるCVE-2026-0770と同じ場所だという点です。NVDの説明は、資格情報なしで管理者級のトークンを配ってしまう入り口（/api/v1/auto_login）と、送られたコードをそのまま実行してしまう検証用の入り口（/api/v1/validate/code）をつなぐだけで、初期設定のLangflowを丸ごと乗っ取れる、と書いています。後者は、本記事が各版のソースコードを取り寄せて「1.10.1から実行しなくなった」ことを確かめた、まさにその入り口です。

結果として今回のKEV登録は、本記事の実査を裏づける形になりました。NVDはCVE-2026-9198の影響範囲を1.0.0〜1.10.0、修正版を1.10.1と明記しています（8月4日に解析完了）。ところが同じ入り口の欠陥でありながら、CVE-2026-0770のほうはいまも「修正版なし」のままです。しかもKEVがCVE-2026-0770の是正先として唯一挙げているのは1.9.0で、そこにこの穴が残っていることは本記事が実査で確認したとおりです。同じ場所の欠陥について、公的な記録が「1.10.1で直る」と「1.9.0へ上げよ」を同時に示している状態が続いています。

誰がいつ悪用を観測したのかは公表されていません。CISAはKEVへ載せる根拠を「実際の悪用の証拠」とだけ示す運用で、本稿の執筆時点では観測の詳細を伝えた報道も見つかりませんでした。KEVの記録上、ランサムウェアに使われたかどうかは「不明」とされています。

やるべきことは変わりません。最新版1.11.1以降へ上げれば、CVE-2026-9198もCVE-2026-0770も影響範囲から外れます。すぐ上げられない場合は自動ログインを無効にし、インターネットへの直接公開をやめてください。公開したまま運用していたのであれば、/api/v1/auto_loginと/api/v1/validate/codeへの過去のアクセス記録、身に覚えのないフローやアカウント、不審な外部通信を点検し、そのサーバーに置いていた鍵やAPIキーは入れ替えておくのが安全です。攻撃中の脆弱性の最新状況はCISA KEV一覧（日本語版）でも追えます。

攻撃されている欠陥の修正は、6月23日の版にすでに入っていた

実際に攻撃されているLangflowの欠陥CVE-2026-0770について、修正そのものは2026年6月23日に公開された1.10.1に、すでに入っていました。公開されている各版のソースコードを取り寄せて確かめた結果です。ところがこの事実は、どの脆弱性データベースにも「CVE-2026-0770の修正」として登録されていません。本記事も前回（7月29日）の更新までは、公開されている記録に従って「修正版は確定していない」と書いていました。

経緯はこうです。開発元は2026年6月18日、「検証用の入り口でコードを実行しない」という修正（PR #13696）を取り込み、これが1.10.1として6月23日に公開されました。修正後のコードには、送り込まれた関数の初期値や装飾（デコレータ）が定義しただけで動いてしまうこと、つまりこの欠陥そのものを説明した注意書きが添えられています。ただしそこで引かれている勧告番号GHSA-2wcq-pvw2-xh7vは、今も公開されていません（開発元が公開している勧告25件のどこにもなく、参照ページは見つからない状態です）。CVE番号との対応づけもありません。

結果として、公開されている記録はすべて「修正版なし」のままです。GitHubの公開勧告は修正版の欄が空（2026年2月19日から更新なし）、OSVも「修正された版」ではなく「影響を受ける最後の版は1.7.3」という書き方で止まり、NVDにも修正版の記載はありません（最終更新は7月22日）。

本記事では、公開されている各版のコードを実際に取り寄せて、検証用の入り口が送られたコードを実行するかどうかを1つずつ確かめました。結果は次のとおりです。

この表がはっきり示すのは、対処の案内先が食い違っているという点です。米政府のKEV（実際に攻撃されている脆弱性リスト）がCVE-2026-0770の是正先として唯一挙げているのは1.9.0のリリースページですが、その1.9.0には、この穴がまだ空いたままです。米連邦機関に7月24日までの対応が義務づけられた案件で、案内どおりに1.9系へ上げた組織は、対処したつもりのまま狙われ続けることになります。

日付の並びも厄介です。修正が公開されたのは6月23日。実際の攻撃が観測され始めたのは6月27日で、KEVに載ったのは7月21日でした。攻撃が始まる4日前に、直った版はもう世に出ていたことになります。それが番号を配る側の記録に最後まで反映されず、守る側は約1か月間「修正版は存在しない」という前提で動いていました。外部でこの対応関係に触れたのは、Resecurityが7月29日に公開した解析記事だけです。

ただし本記事は、「1.10.1でCVE-2026-0770は解決した」とまでは書きません。開発元も、番号を採番したZDIも、脆弱性データベースのいずれも、この対応づけを公式には認めていないためです。本記事が自分の目で確かめられたのは「検証用の入り口からコードの実行が消えたこと」までで、同じ番号の欠陥に別の到達経路が残っていないことまでは確認できません。実務上の推奨は変わりません。最新版へ更新したうえで、インターネットへ直接公開しない・アクセス元を絞る・自動ログインを無効にする——この3つを併せて行ってください。

なお、この欠陥が今後30日以内に攻撃に使われる確率の推定値（EPSS）は、8月2日時点で0.56、全体の上位1%に入る水準です。すでに実際の攻撃が観測されている以上、数値以前に対処が必要な段階にあります。

【2026年8月3日 追記】さらに9件、AI連携（MCP）の窓口が新たな標的に

前回の更新以降、Langflowにはさらに脆弱性が積み上がりました。開発元IBMは7月28日から30日にかけて8件をNVDへ登録し、加えて8月1日には開発元のGitHubで1件が公開されています。合計9件です。目立つのは、これまで狙われてきた「コード検証の入り口」や「公開フローの窓口」ではなく、AIに外部のツールやデータをつなぐ共通の仕組み「MCP」まわりが標的になっている点です。

CVE-2026-12940（CVSS 9.8・無認証）: AI連携の起動処理に環境変数を紛れ込ませて乗っ取り

今回の9件で唯一、ログインなしでサーバーの乗っ取りに至るとされるのがこれです。NVDの説明によれば、MCPの外部ツールをコマンドとして起動する処理で、攻撃者が環境変数を注入できてしまいます。プログラムの動作を外から決める値に手が入るため、そのままOSのコマンド実行（CWE-78）につながります。対象は1.0.0から1.10.1まで。開発元IBMは個別の勧告を出しています。

CVE-2026-8446（CVSS 8.6・無認証）: AI連携の窓口が認証を素通しし、管理者のファイルまで読まれる

8月1日に開発元が公開したセキュリティ勧告です。MCPの連携機能を有効にし、対象のプロジェクトを外部の認証（OAuth）に設定していると、通常のログイン確認の経路が飛ばされ、認証していない相手がMCPの窓口に到達できます。勧告によれば、実際の検証で外部からファイル一覧の取得と読み出しが通り、管理者を含む他の利用者のファイルの中身まで取り出せたとされています。原因の一つとして挙げられているのが、後述する自動ログインが有効なときに管理者アカウントへ読み替える作りで、既定値の危うさがそのまま新しい欠陥を生んだ形です。修正は1.11.0。なお、この番号は執筆時点でNVDにはまだ載っておらず、開発元のGitHub側にだけ記載があります。

残る7件は悪用にログインが必要で、多くは「他人のデータに手が届く」種類のものです。ただしLangflowを複数人・複数チームで共有している環境では、一般権限のアカウントが1つあれば、他人の社内文書や検索用データ、実行履歴に触れられることを意味します。8件についてはNVDの解析がまだ終わっておらず、修正版の欄も空のままです。影響範囲が1.10.1までとされていることから、少なくとも最新版1.11.1まで上げておくのが現実的な対応になります。MCPの窓口をめぐる欠陥は、6月のCVE-2026-7664・CVE-2026-7663（いずれも認可の確認不足）から続いており、この記事の後半でも扱っています。

KEVに載ったLangflowの脆弱性は計6件（CVE-2026-9198を含む）

CVE-2026-0770に先立ち、2026年7月7日にはCVE-2026-55255もKEVへ登録されていました（是正期限7月10日）。ログイン済みの利用者が他人のフローIDを指定して、そのフローを実行できてしまう欠陥（Authorization Bypass Through User-Controlled Key）で、本記事後半の「NVDに登録された4件」でも扱っているものです。この7月7日のバッチが、Adobe ColdFusion（CVE-2026-48282）やJoomla系の2件とあわせた計4件でした。

さらに2026年8月4日、7月17日バッチのCVE-2026-9198も追加されました（是正期限8月7日）。結果として、KEVに掲載されているLangflowの脆弱性は6件にのぼります。ここまで同一製品の欠陥が積み上がっている例は多くありません。

※CVE-2026-55255の是正先としてKEVが指しているのは開発元のセキュリティ勧告（GHSA-qrpv-q767-xqq2）で、修正は1.9.1です（本記事は従来1.9.2と記載していましたが、勧告本文が「1.9.1で修正」と明記し、NVDの影響範囲も1.9.1未満となっているため訂正しました）。

【2026年7月17日 追記】Langflowに一挙十数件、多くが乗っ取りに（CVE-2026-8505・8476ほか）

開発元IBMは2026年7月17日、Langflowに十数件もの脆弱性をまとめて公開しました。大半はサーバーを乗っ取る（RCE）か認証を迂回するもので、影響を受けるのは基本的に1.10.0以前（一部は1.10.1まで）です。修正版は1件ごとに異なり、1.10.1で直ったものと、1.10.2まで待たねばならなかったものに分かれます（次項の表を参照）。取り違えを避けるなら、最新版1.11.1（2026年7月28日公開）まで上げてしまうのが確実です。すぐ上げられない場合は、後述の応急策のうち自動ログインの無効化と、インターネットへの直接公開の停止が特に効きます。数が多いので、まずログイン不要で悪用できる（＝とくに危険な）ものと4件中最高の危険度9.9を個別に解説し、悪用にログインが要るものは後半の一覧にまとめます。

CVE-2026-8505（CVSS 9.8・無認証）: 初期設定のWebフック認証オフを突いてフロー実行から乗っ取りへ

Langflowの外部連携（Webフック）は、1.9.x以前では初期設定で認証がかかっていませんでした。この状態だと、攻撃者はフローのUUID（識別番号）さえ分かれば、ログインなしでそのフローを実行できてしまいます。フローの内容次第では、そこからサーバー上でのプログラム実行（RCE）に至る恐れがあり、今回追加された中でもとくに注意すべき無認証の欠陥です。危険度は9.8とされています。

この既定値は1.10.0で是正済みです。Langflowの認証設定のソースコードを各版で確認すると、Webフックの認証を要求する設定（WEBHOOK_AUTH_ENABLE）は1.9.0ではFalse、1.10.0以降は「安全な既定にするため」Trueに変わっています。1.9.x以前を動かしたままなら、更新するか、この設定を明示的に有効化してください。

CVE-2026-9103（CVSS 9.8・無認証）: 自動ログインが管理者級の入場券を無認証で配ってしまう

初期設定で自動ログインが有効なとき、認証用の入り口（/api/v1/login/auto_login）が有効期限の長い管理者級トークン（入場券）を、資格情報なしの相手にそのまま発行してしまいます。さらに外部サイトからの読み取りを緩く許す設定（CORS）が重なると、このトークンが意図しない相手に渡る恐れもあります。結果として、ログインしていない外部の攻撃者が全管理権限を握れるため、危険度は9.8とされています。

Webフックと違い、自動ログイン（AUTO_LOGIN）の既定値は最新の1.11.1でもTrueのままです。ソースコードには「認証を迂回する設定であり、開発環境でのみ使うこと」「v2.0で既定をFalseにする」という注意書きが添えられているだけで、既定値そのものは変わっていません。更新しても自動的に安全側へ倒れないため、自動ログインの無効化は今も必須の作業です。ひとつだけ例外があり、公式のDockerイメージはイメージ側でLANGFLOW_AUTO_LOGIN=falseを指定して無効にしています。危ないのはpipなどで直接入れた場合で、そのときは有効のまま起動します。8月1日に公開されたCVE-2026-8446も、この自動ログイン時に管理者アカウントへ読み替える作りが原因の一つに挙げられています。

CVE-2026-9198（CVSS 9.8・無認証）: 自動ログインとコード検証をつないだ認証なしのコード実行

攻撃者はまず、認証なしで管理者級のトークンを配ってしまう入り口（/api/v1/auto_login）から正規の入場券を手に入れます。続いて、送り込んだコードをそのまま実行してしまう検証用の入り口（/api/v1/validate/code）を突き、Pythonの実行機能（exec）で任意のコマンドを走らせます。この2つをつなぐだけで、初期設定のままのLangflowを認証なしで丸ごと乗っ取れるため、危険度は9.8とされています。IBMの勧告では、最新版への更新が案内されています。

CVE-2026-9202（CVSS 9.8・無認証）: 認証なしで利用者を無制限に作られ、そのまま乗っ取りへ

Langflowの設定で新規利用者を即座に有効化するオプション（NEW_USER_IS_ACTIVE=true）が有効になっていると、攻撃者はログインなしで利用者アカウントをいくつでも作れてしまい、作った直後からコード実行の入り口へ到達できます。結果として、こちらも認証の壁を越えてサーバーを乗っ取る足がかりになります。

CVE-2026-13446（CVSS 9.8・無認証）: 認証や暗号化に使う鍵がソフトに直書きされていた

Langflow本体に、ログイン認証やデータの暗号化に使う鍵（合言葉）が、誰でも同じ値としてプログラム内にそのまま埋め込まれていました（ハードコード）。全利用者で共通の鍵のため、攻撃者がこの値を知っていれば、ログインなしで認証を偽装したり、暗号化されたデータを解いたりできる恐れがあります。影響は1.10.1までなので、1.10.1へ上げただけでは残ります。1.10.2以降への更新が必要です。

CVE-2026-8476（CVSS 9.9・要認証）: ディスク上のキャッシュを検証せず読み込み、任意コード実行

こちらは今回のバッチで最も高いCVSS 9.9です。Langflowがディスクに保存したキャッシュを読み戻す際、Pythonのpickle.loads()という仕組みで中身を検証せずに復元していました。細工したキャッシュを送り込めれば任意のコードが実行されます。悪用にはログイン済みのアカウントが要りますが、成立したときの被害は極めて大きくなります。

CVE-2026-9135（CVSS 9.9・要認証）: 部品のコード欄からバックエンドでPython実行

悪用にはフローを作成できるログイン済みのアカウントが必要ですが、Langflowの安全装置「ToolGuard」部品で動的に指定できるコード欄の検証が不十分だったため、カスタム部品に課された制限をすり抜けてバックエンドで任意のPythonコードを実行できます。さらにMCP（AIツール連携の仕組み）の更新機能を通じて、他の利用者（テナント）のフローに手を出せる場合もあります。

上記のほか、同じ7月17日には悪用にログイン（フロー作成などの権限）が要る欠陥も多数公開されています。前提が付くぶん無認証の欠陥より切迫度は下がりますが、正規アカウントを1つ用意できれば乗っ取りに至るものが並びます。

修正版は1.10.1系と1.10.2系に分かれる

7月17日バッチでつまずきやすいのが、修正版が1つに揃っていない点です。IBMの勧告を確認すると、1.10.1でふさがったものと、影響範囲が1.10.1まで及んでいて1.10.2を待つ必要があったものが混在しています。1.10.1へ上げたから全部済んだ、とはなりません。

前述のCVE-2026-13446も影響範囲が1.10.1までで、同じく1.10.2以降が必要です。版ごとの確認が煩わしければ、1.11.1まで一気に上げてしまえば7月17日バッチはすべて範囲外になります。なお、これらのIBM勧告はいずれも改訂履歴が「初版公開」の1行だけで、7月21日以降に内容が改められた事実はありません。

これら十数件は、Langflowが繰り返し狙われてきた「認証の穴＋サーバー上でのコード実行」という同じ系統の欠陥です（本記事後半の「Langflowは何度も同じ穴を狙われてきた」も参照）。公開ソフトの部品として広く取り込まれる製品だけに影響範囲を把握しにくく、こうしたリスクの見つけ方は公開ソフトの部品に潜むリスクをまとめた記事でも扱っています。このうちCVE-2026-9198は2026年8月4日にKEVへ登録され、実際の攻撃に使われていることが確認されました（是正期限8月7日。冒頭の追記を参照）。残る各CVEについては、現時点で攻撃に使われたという報告もKEV登録も確認されていません。Langflowは過去に公開直後の攻撃が観測されており、更新は急ぐべきです。実際の攻撃が始まっていないかは攻撃中の脆弱性を追う一覧（日本語版）で確認できます。

AIエージェントやチャットボットを、プログラムをほとんど書かずに画面上の部品をつなぐだけで作れる人気ツール「Langflow（ラングフロー）」で、深刻な脆弱性の公開が止まりません。2026年7月17日にはさらに十数件（CVE-2026-8505・8476ほか、記事冒頭で解説）が加わりました。その少し前、6月30日にも開発元IBMが8件をまとめて公開しており、そのなかでいちばん危険なものはログインも利用者の操作も不要で、ネットワーク越しにサーバーを乗っ取れるCVSS 10.0のコード実行（CVE-2026-10134）です。ほかにも認証不要でサーバー上のプログラムを実行できる欠陥が2件（CVE-2026-7803・CVE-2026-7871、いずれもCVSS 9.8）、保存していた認証情報がまとめて漏れる欠陥（CVE-2026-7874）などが並びます。

これらは、2026年6月に立て続けに公開された一連の欠陥（CVE-2026-10561ほか、本記事の後半で詳しく解説）に続くものです。Langflowは「サーバー上で利用者のコードを実行する」設計ゆえに、認証の穴がそのまま全面的な乗っ取りに直結しやすく、過去には実際の攻撃が公開直後に観測されてきました。ここから先は、6月30日に公開された8件と、それに先立つ6月の欠陥群を、新しい順にたどります。対象は脆弱性ごとに異なりますが、6月30日公開の8件は最大で1.10.0までが影響を受け、1.10.1以降への更新で解消できます（7月17日のバッチには1.10.2まで要るものがあり、7月末以降に公開された9件は1.11.1まで上げる必要があります。さらに8月5〜6日公開の14件は1.10.3までが対象で、1.10系では対処できません。CVE-2026-0770の扱いとあわせて、いずれも冒頭で扱っています）。すぐに上げられない場合の応急策は、後半の「いま何をすべきか」がそのまま当てはまります。

※上の表は、6月に公開された一連の欠陥のうち代表的なCVE-2026-10561の概要です。まずは下記の「7月に公開された新たな8件」から確認してください。

2026年6月30日に公開された8件（CVE-2026-10134ほか）

2026年6月30日、IBMはLangflowについて新たに8件の脆弱性を公開しました。危険度の高い順に整理すると、特に注意すべきはログインも利用者の操作も不要でサーバーを乗っ取れる、あるいは保存情報を丸ごと奪われる「認証不要の致命傷」5件です。残る3件はログイン済みの利用者による悪用が前提ですが、多人数で共有する環境では見過ごせません。まず全体を一覧で示し、主要なものを補足します。

CVE-2026-10134（CVSS 10.0）: 公開フローのPython部品で認証なしコード実行

今回の8件で最も深刻な、最高ランクの欠陥です。NVDの説明によると、フローに置ける「PythonCodeStructuredTool」という部品が、攻撃者の送り込んだPythonコードをサーバー上で実行してしまいます。正規の利用者がフローを「公開（PUBLIC）」に設定していると、認証なしで利用できる窓口（/api/v1/build_public_tmp）からこのコード実行に到達でき、そのフローのIDが分かれば誰でも、サーバー上の秘密情報の読み取り、保存データの読み書き、内部サービスへのアクセス、居座り（永続化）まで行えます。CWE分類は「コードインジェクション（CWE-94）」。これは6月のCVE-2026-10561やCVE-2026-33017と同じ「公開フロー＋Python実行」の系統で、Langflowが繰り返し狙われてきた弱点そのものです。対象は1.9.3まで。

CVE-2026-7803 / CVE-2026-7871（ともにCVSS 9.8）: 認証なしのコード実行

CVE-2026-7803は、種類の欄が空だったり欠けていたりするフロー部品の検証が甘く、認証なしで任意のコードを実行できる欠陥です（入力検証の不備、CWE-20）。CVE-2026-7871は、Langflowが内部で使うデータ保管庫「Redis」に到達できる相手が、安全でないデータの復元処理（デシリアライズ、CWE-502）を突いて、アプリの全権限でコードを実行できるものです。Redisを外部からアクセスできる状態にしないことが、この欠陥への有効な備えになります。いずれも対象は1.10.0まで。

CVE-2026-7874（CVSS 9.1）: 保存していた認証情報がまとめて漏れる

CVE-2026-7874は、保存時の暗号化に弱く元に戻せてしまう鍵の作り方（脆弱な擬似乱数、CWE-338）を使っていたために、Langflowに保管されていたすべての認証情報（APIキーやアクセストークン）が解読・開示され得る欠陥です。つないでいたAIモデルや外部サービスの鍵が漏れると、それを使った不正利用や課金の被害に直結します。更新したあとも、念のため保管していたAPIキー・トークンは失効させて再発行しておくのが安全です。あわせてCVE-2026-7663（CVSS 9.1）は、AIに外部ツールをつなぐ「MCP」の窓口で認可の確認が不十分なため、認証なしの相手が保護されたMCPの情報や操作にアクセスできてしまう欠陥です（不適切な認可、CWE-285）。

ログインが前提の3件（CVE-2026-7873ほか）

残る3件は、悪用にログインが必要です。CVE-2026-7873（CVSS 9.9）は、ログイン済みの攻撃者がコード検証の窓口を突いてOSコマンドを実行し、認証情報の読み取りや横移動に至るもの。CVE-2026-10140（CVSS 9.6）は、音声モードの内部キャッシュの管理に不備があり、利用者（テナント）どうしのリクエストが取り違えられて、他人のAPI鍵で処理が走る・課金が混乱するというもの。CVE-2026-10129（CVSS 8.5）は、外部リクエストを送る部品でSSRF（サーバーを踏み台にして内部に手を伸ばす攻撃）の保護をすり抜けられるものです。いずれも多人数で共有するLangflow環境では、一般権限のアカウントから影響が広がり得ます。

対応は共通です。1.10.1以降へ更新すれば、この8件はまとめて解消されます。各脆弱性の詳細と修正版は、Langflowのリリース一覧と各IBMのセキュリティ情報で確認できます。すぐに上げられない場合は、後述の「いま何をすべきか」にある外部公開の遮断・アクセス制限がそのまま有効です。

この欠陥は誰に、どんな被害をもたらすのか

まず狙うのは、特定の誰かを定めて攻める相手ではありません。インターネット上に公開されたLangflowのサーバーを、自動のプログラムでひたすら探し回る攻撃者です。AI開発ブームで手早く立ち上げた検証用の環境が、そのまま外から見える状態で放置されている、というのがいちばん危ない形です。

見つけたサーバーに対して、攻撃者はログインを飛び越えてそのサーバーの中で好きなコマンドやプログラムを実行します。ID・パスワードも、利用者のうっかりクリックも要りません。穴の空いた窓口にデータを送りつけるだけで、サーバーが言うことを聞いてしまいます。

乗っ取られたあとの被害は重く、二段構えです。Langflowの中には、つないだAIモデルや外部サービスのAPIキー、各種のアクセストークンがそのまま保管されていることが多く、これらが一気に盗まれます。サービスを使う側のエンドユーザーは個人情報や会話内容が漏れる恐れがあり、運用する企業・組織は、盗んだ鍵を使った不正な課金、保存データの破壊、社内の別システムへ侵入するための踏み台化といった連鎖的な被害を負います。だからこそ、後述する更新と公開範囲の見直しが急がれます。

これは机上の心配ではありません。Langflowの同種の欠陥は過去に、感染を広げる「Flodrix」と呼ばれるボットネットや、イランとの関係が指摘される攻撃集団「MuddyWater」に実際に悪用され、米政府の「実際に攻撃されている脆弱性リスト（CISA KEV）」にも繰り返し載ってきました。同じ仕組みの最新版が、今回のCVE-2026-10561です。

そもそもLangflowとは何か

Langflowは、AIエージェントや、社内文書を読ませて答えさせる仕組み（RAGと呼ばれます）を、画面上で部品をドラッグして線でつなぐだけで組み立てられるツールです。プログラムを書き慣れていない人でもAIの処理の流れを作れるため、急速に広がりました。GitHub上の公開リポジトリには15万近い「スター（お気に入り登録）」が付き、オープンソースのAIツールの中でも特に勢いのある存在です。現在はIBMの傘下で開発が続いています。

便利さの裏で、Langflowには構造的な弱点があります。画面で組んだ部品の中には、利用者が自分でPython（パイソン、AI開発で広く使われるプログラミング言語）のコードを書いて実行できるものが含まれており、そのコードはLangflowのサーバー上でそのまま動きます。つまり「サーバー上でプログラムを実行できる」機能が、設計として最初から備わっているのです。便利な反面、入口の鍵が外れた瞬間に、それがそのまま乗っ取りの道具に変わります。開発側もこの危うさは認識しており、利用者のコードをハードウェアで隔離した仮想マシン内で動かすといった抜本対策が議論されています。

技術的に何が起きているのか

今回のCVE-2026-10561は、脆弱性データベースの記載によると、Pythonコードを実行する部品（PythonREPLComponent）で、本来触れられないはずの内部機能（builtins）に手を伸ばす「ビルトイン・インジェクション」と、ログインの確認をすり抜ける「認証バイパス」が組み合わさったものです。CWE分類では「コード生成の不適切な制御（コードインジェクション、CWE-94）」にあたります。

Langflowの根の問題は一貫しています。利用者が書いたPythonコードを、隔離（サンドボックス）の仕組みなしにサーバー本体のプロセスでそのまま実行してしまう点です。本来、外部に開かれた窓口は必ずログインを求めるべきですが、認証チェックが抜け落ちた経路が存在すると、攻撃者はその窓口に細工したデータを送るだけで、サーバー上でコードを実行できてしまいます。CVSSのベクトルは AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H で、「ネットワークから・低い難度で・権限もユーザー操作も不要・影響は本体を越えて波及」という、最悪の組み合わせがすべて揃っています。

参考までに、2026年3月に公開された別のLangflowの欠陥（CVE-2026-33017）では、認証不要の「公開フロー構築」窓口に送り込んだコードが、グラフ構築の途中で exec() によって無防備に実行される経路が解析されています。窓口や部品は違っても、「ログインを抜けてPython実行にたどり着く」という筋道は共通しています。

同じ日に公開された、もう1件の重大欠陥（CVE-2026-7664）

実は2026年6月22日、IBMはLangflowについてもう1件の重大な欠陥（CVE-2026-7664、CVSS 9.8）も同時に公開しています。こちらは「MCP」と呼ばれる窓口で、誰に何を許すかの確認（認可）が不十分だった、という問題です。MCP（Model Context Protocol）は、AIエージェントに外部のツールやデータを安全につなぐための共通の仕組みで、Langflowもこれに対応しています。

この欠陥では、本来ログインした人しか触れないはずのMCPプロジェクトの情報や操作に、認証なしの第三者がそのままアクセスし、操作を実行できてしまいます。分類は「不適切な認証（CWE-287）」です。CVE-2026-10561のような任意コードの実行とは種類が違いますが、AIワークフローの内部情報や接続先が認証なしで触られる以上、深刻さは変わりません。対象はバージョン1.0.0〜1.8.4で、こちらは1.9.1以降で修正されています。

つまり6月22日のLangflowは、コード実行まわり（CVE-2026-10561）と認証・認可まわり（CVE-2026-7664）で、2件の重大欠陥が同時に出た形です。幸い、後述する1.9.4への更新は両方を同時にふさぎます。新しい版へ上げてしまえば、どちらもまとめて解消できます。

さらにNVDに登録された4件の欠陥（CVE-2026-48519ほか）

2026年6月24日には、Langflowについてさらに4件の重大な脆弱性が脆弱性データベース（NVD）に登録されました。いずれもCVSSが9点台で、どれも1.9.4より前のバージョンが対象です。つまり、本記事がすすめる1.9.4以降への更新で、CVE-2026-10561・CVE-2026-7664と合わせて、これら4件もまとめて解消されます。中でもCVE-2026-48519は、ここまで見てきたのと同じ「認証なしの遠隔コード実行（RCE）」で、実証コード（PoC）も公開されています。

CVE-2026-48519（CVSS 9.6）: 認証なしでサーバー上のコードを実行

「共有プレイグラウンド（公開フロー）」用の窓口 /api/v1/build_public_tmp が、認証なしのまま攻撃者の送り込んだフローデータを処理してしまう欠陥です（開発元のセキュリティ勧告）。公開フローが1つでもあり、そのID（UUID）が共有リンクなどから分かると、第三者が任意のコードをサーバー上で実行できます。前述のCVE-2026-33017と同じ「公開フロー構築」窓口の系統で、Langflowが繰り返し狙われてきた弱点そのものです。修正は1.9.2。

CVE-2026-55255（CVSS 9.9）: 他人のAIフローを横取りして実行

ログイン済みの利用者が、本来は触れないはずの他人のフローIDを指定して、そのフローを実行できてしまう欠陥です（権限の横取り＝IDOR、CWE-639）。窓口は /api/v1/responses。多人数で共有するLangflow環境では、一般権限のアカウントから他人の処理や接続先に手が届く点が危険です。修正は1.9.1。この欠陥は2026年7月7日にCISA KEVへ登録され、実際の攻撃で使われていることが確認されています（是正期限7月10日）。

CVE-2026-55447（CVSS 9.6）: 読み込ませたファイル経由でサーバー内を盗み見

社内文書を読ませる仕組み（RAG）に取り込ませるファイルを攻撃者が用意することで、サーバー内の本来読めないはずのファイルを絶対パスで読み出させる欠陥です（シンボリックリンク悪用、CWE-61/200）。ファイルを読み込むタイプの部品（BaseFileComponent系）が広く対象になります。修正は1.9.2。

CVE-2026-55450（CVSS 9.3）: 認証なしの無制限アップロードでサービス停止

認証なしでファイルを無制限にアップロードできてしまう欠陥です（認証欠落・リソース枯渇、CWE-306/400）。サーバーのストレージを使い尽くしてサービスを止めたり、保存先のパス情報を漏らしたりするのに使われ得ます。乗っ取りそのものではありませんが、可用性を損なう点で深刻です。修正は1.9.1。

いずれも、対応は同じです。1.9.4以降へ更新すれば4件ともふさがります。すぐに上げられない場合の応急処置（外部公開の遮断・アクセス制限）も、後述の「いま何をすべきか」がそのまま当てはまります。

Langflowは何度も同じ穴を狙われてきた

今回が初めてではない、というのが怖いところです。Langflowの重大な遠隔コード実行の欠陥は、ここ1年あまりで繰り返し見つかり、しかもそのいくつかは公開直後に実際の攻撃が観測されています。主な経緯を時系列で並べます。

← スワイプで移動

この経緯が示すのは、Langflowが「たまたま一度狙われた」のではなく、攻撃者にとって公開直後から狙う価値のある常連の標的になっているという事実です。新しい欠陥が公開されるたびに、攻撃側は数時間〜1日のうちに動き出してきました。CVE-2026-10561についても、本記事の執筆時点で「この番号の欠陥が実際に悪用された」とまでは確認できていませんが、過去の反応速度を踏まえれば、対応に使える猶予は長くないと考えるのが妥当です。なお、Langflow を含む IBM 製品の重大な脆弱性は、IBM の脆弱性まとめ記事でも横断的に追っています。

いま分かっていること・まだ分からないこと

いま何をすべきか

最優先は、Langflowを最新版の1.11.1（2026年7月28日公開、PyPIの最新も同じ）へ更新することです。6月の欠陥だけなら1.9.4以降、7月17日バッチまで含めるなら1.10.2以降が必要で、版を数えるより最新へ上げるほうが確実です。1.0.0から1.9.3までを使っているなら、検証用・社内用を問わず例外なく対象だと考えてください。なお1.11.2は7月31日に印（タグ）が付いた段階で、リリースとしてもPyPIにもまだ出ていません（配布されているのは試験版の1.11.2rc2までです）。執筆時点で入れるべき最新は1.11.1になります。

ただし、更新だけでは足りない点が2つあります。1つはCVE-2026-0770で、修正コード自体は1.10.1に入っていることを確認したものの、開発元も番号を配る側もそう認めていないため、更新だけで片づいたとは見なせません（冒頭を参照）。もう1つは自動ログイン（AUTO_LOGIN）で、1.11.1でも既定が有効のままです。本番運用ではAUTO_LOGIN=falseを明示し、管理者アカウントのパスワードを自分で設定してください。1.9.x以前から上げていない場合は、Webフックの認証（WEBHOOK_AUTH_ENABLE）も既定オフのままなので、あわせて有効化が必要です（1.10.0以降は既定で有効）。設定項目はLangflow公式の認証ドキュメントにまとまっています。

すぐに更新できない場合は、応急処置として外部からの接続を断つのが現実的です。Langflowはそもそも、不特定多数がアクセスできるインターネットに直接公開して使う設計ではありません。社内ネットワークやVPNの内側に閉じ込める、アクセス元のIPアドレスを制限する、前段に認証を必須とする仕組み（リバースプロキシなど）を挟む、といった対策で攻撃の窓口そのものをふさげます。すでに公開状態で運用していた場合は、更新だけで安心せず、保管していたAPIキーやアクセストークンを失効・再発行し、不審なプロセスや通信の痕跡がないかも確認しておくべきです。

自社の資産にLangflowのサーバーがインターネットへ露出していないかは、資産の棚卸しツールやネットワークスキャンでも洗い出せます。AI開発の勢いで増えた検証環境ほど、誰も管理していないまま外に開いているケースが多く、まずは「自分たちのLangflowがどこで、どんな公開状態で動いているか」を把握することが出発点になります。

まとめ

人気のAI開発ツールLangflowでは、深刻な脆弱性の公開が止まりません。直近では2026年8月5日から6日にかけて、さらに14件が公開されました。影響範囲は1.0.0から1.10.3までで、これまで更新先として案内されてきた1.10.1も1.10.2も対象に含まれます。最も重いCVE-2026-8182は、資格情報なしにHTTPリクエスト2回でサーバー上のコードを実行できるものです。14件はAI連携（MCP）とAI支援機能に集中しており、なかでもCVE-2026-9196は、AIが生成したコードを利用者が承認する前に実行してしまうという内容でした。その前日の8月4日には、7月17日に公開されたばかりのCVE-2026-9198が米CISAのKEVへ登録されています（是正期限8月7日）。7月21日のCVE-2026-0770、7月7日のCVE-2026-55255と合わせ、KEVに載るLangflowの脆弱性は計6件です。CVE-2026-9198はCVE-2026-0770と同じ検証用の入り口を突くもので、NVDは修正版を1.10.1と明記しています。7月17日にはIBMが十数件をまとめて公開し、その修正版は1.10.1系と1.10.2系に分かれます。6月30日公開の8件（最悪はCVSS 10.0のCVE-2026-10134）は1.10.1以降、6月22日のCVE-2026-10561ほかは1.9.4以降で解消するため、版を数えるより最新版へ上げるのが確実です（2026年8月6日時点の最新は1.11.2）。さらに7月28日から8月1日にかけて9件が加わり、うちCVE-2026-12940とCVE-2026-8446はログイン不要で悪用できます。8月5〜6日の14件については、修正版がNVD・GitHub・OSVのいずれにも記載されていません。確実に言えるのは1.10.3以下が対象だということだけで、1.11系へ上げるのは「直ったと確認できたから」ではなく「対象と明記された範囲の外に出るため」です。CVE-2026-0770については、修正コードが6月23日公開の1.10.1にすでに入っていたことを各版のソースコードで確認しましたが、公的な記録はいまも「修正版なし」のままで、KEVが案内する1.9.0には穴が残っています。自動ログインの既定有効も未是正のため、更新に加えて公開範囲の見直しと設定変更が要ります。Langflowは「サーバー上で利用者のコードを実行する」設計ゆえに、認証の穴がそのまま全面的な乗っ取りに直結しやすく、過去にも同種の欠陥が公開直後から狙われ続けてきました。

AIアプリ開発の現場では、手早く立てた便利なツールが、いつの間にかインターネットに露出したまま放置されがちです。今回をきっかけに、更新と公開範囲の見直し、そして「どこで動いているかの把握」をまとめて点検しておくことをおすすめします。

参照元

• ・NVD — CVE-2026-10134（7月公開・CVSS 10.0・認証なしコード実行）
• ・NVD — CVE-2026-7803（CVSS 9.8・認証なしコード実行）
• ・NVD — CVE-2026-7871（CVSS 9.8・Redis経由のコード実行）
• ・NVD — CVE-2026-7874（CVSS 9.1・保存済み認証情報の漏洩）
• ・NVD — CVE-2026-7663（CVSS 9.1・MCP認可不備）
• ・NVD — CVE-2026-7873（CVSS 9.9・認証済みのOSコマンド実行）
• ・NVD — CVE-2026-10140（CVSS 9.6・テナント間のキャッシュ混線）
• ・NVD — CVE-2026-10129（CVSS 8.5・SSRF保護のすり抜け）
• ・IBM Security Bulletins（Langflow・7月公開分）
• ・CISA — Known Exploited Vulnerabilities Catalog（版数2026.07.27で実査）
• ・NVD — CVE-2026-0770（無認証でroot権限のRCE） / ZDI-26-036
• ・GitHub Security Advisory — CVE-2026-55255（GHSA-qrpv-q767-xqq2）
• ・Langflow — 認証設定のソースコード（AUTO_LOGIN・WEBHOOK_AUTH_ENABLEの既定値）
• ・Langflow 1.11.1 リリース（2026年7月28日・最新版） / リリース一覧
• ・NVD — CVE-2026-10561 詳細
• ・IBM Security Bulletin（CVE-2026-10561）
• ・NVD — CVE-2026-7664 / IBM Security Bulletin（CVE-2026-7664）
• ・CIRCL Vulnerability-Lookup — CVE-2026-10561
• ・GitHub Security Advisory — CVE-2026-48519（公開フロー窓口の認証なしRCE）
• ・NVD — CVE-2026-55255（フロー横取り・IDOR、CVSS 9.9）
• ・NVD — CVE-2026-55447（任意ファイル読み取り、CVSS 9.6）
• ・NVD — CVE-2026-55450（認証なし無制限アップロード、CVSS 9.3）
• ・Langflow 公式サイト / GitHubリポジトリ
• ・Sysdig — CVE-2026-33017 を20時間で悪用した手口の解析
• ・SecurityWeek — 公開直後に悪用されたLangflowの欠陥
• ・The Hacker News — CISAがLangflowをKEVに追加
• ・runZero — 影響を受けるLangflow資産の洗い出し
• ・Langflow PR #13696 — fix(security): do not execute code in validate_code（2026年6月18日取り込み・1.10.1へ）
• ・GitHub Security Advisory — GHSA-g22f-v6f7-2hrh（CVE-2026-0770・修正版の欄は空のまま） / OSV
• ・Resecurity — validate_codeエンドポイントの悪用解析（2026年7月29日）
• ・NVD — CVE-2026-12940（CVSS 9.8・MCP起動処理への環境変数注入で無認証RCE）
• ・Langflow セキュリティ勧告 — CVE-2026-8446（MCP窓口の認証バイパス・修正1.11.0）
• ・IBM Security Bulletin — CVE-2026-12940
• ・FIRST EPSS — 悪用確率の推定値
• ・CISA KEV ダッシュボード（日本語版・当サイト）