Langflowに重大な脆弱性6件、IBMが発見-未認証RCEからAPIキーの越境流用まで広範囲に影響(CVE-2026-10134、CVE-2026-7803、CVE-2026-7871、CVE-2026-7873、CVE-2026-10140、CVE-2026-7663)|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年07月09日更新日時: 2026年07月09日

IBMのセキュリティ研究者は、AIアプリケーション開発プラットフォームであるLangflow OSSに、重大度の高い脆弱性を6件発見したと公表しました。2026年7月4日にセキュリティメディアのsecurityonline.infoが報じたもので、任意のコード実行を許すものから、認可の不備によってAPIキーがテナントをまたいで流用されてしまうものまで、影響範囲の異なる複数の問題が一度に明らかになった形です。

当サイトでも以前、LangflowのCSV Agentに存在した未認証RCEの脆弱性(CVE-2026-27966)や、Langflowの脆弱性を起点にエージェント型AIが自律的にランサムウェア攻撃を実行したJADEPUFFERの事例を取り上げましたが、Langflowはこうしたコード実行に関わる脆弱性がたびたび報告されているプロダクトであり、今回の6件もその延長線上にあります。

1 サマリー
2 何が起きたか
3 コード実行に直結する4つの脆弱性
4 APIキーの越境流用とアクセス制御の不備
5 情報システム部門への示唆
6 出典

サマリー

IBMのセキュリティ研究者は、Langflow OSSに6件の重大な脆弱性を発見し、2026年7月4日にsecurityonline.infoが報じた
CVE-2026-10134は、公開フロー内のPythonCodeStructured Toolを通じて悪意あるPythonコードを注入し、ビルド処理の際にexec()関数で実行させる未認証のリモートコード実行の脆弱性
CVE-2026-7803は、コンポーネントの種別を空欄にしたノードを送信することで、無効化されているはずのカスタムコンポーネントの検証をすり抜けさせ、ビルド時に悪意あるコードを静かに実行させる検証バイパスの脆弱性
CVE-2026-7871は、キャッシュ用のRedisバックエンドがdill.loads()を整合性検証なしに使っていることに起因する安全でないデシリアライズの脆弱性で、汚染されたペイロードをキャッシュへ注入すると、それを読み取った任意のワーカー上でコードが実行される
CVE-2026-7873は、コード検証エンドポイントにおいてPythonのデフォルト引数の評価タイミングを悪用し、関数を実際に呼び出さなくてもOSコマンドを実行できてしまうコードインジェクションの脆弱性
CVE-2026-10140とCVE-2026-7663は認可に関する不備で、音声モードのサブシステムがAPIキーをプロセス全体で共有されるシングルトンに不適切にキャッシュすることでテナントをまたいだAPIキーの流用や課金詐欺につながる問題と、Streamable MCPトランスポートのエンドポイントがプロジェクトの所有権チェックを行わず保護されたリソースへ認証なしにアクセスできてしまう問題がそれぞれ該当する
本稿執筆時点で実際の悪用は確認されていないが、MCPの認可バイパスについては研究者が4件の概念実証シナリオの成立を検証済み
大部分の脆弱性はバージョン1.10.1で修正されており、1.10.0の時点でMCP認可バイパスと未認証RCEの脆弱性には対応済みとされている

項目	内容
発見者	IBMのセキュリティ研究者
公表日	2026年7月4日(securityonline.info)
脆弱性件数	6件
主なCVE番号	CVE-2026-10134、CVE-2026-7803、CVE-2026-7871、CVE-2026-7873、CVE-2026-10140、CVE-2026-7663
影響を受けるバージョン	多くはLangflow OSS 1.0.0〜1.10.0(個別に範囲が異なる。CVE-2026-10134は1.9.3まで、CVE-2026-7663は1.9.6まで)
修正バージョン	1.10.1(大部分に対応)、1.10.0の時点でMCP認可バイパスと未認証RCEには対応済み
悪用実績	本稿執筆時点で確認なし。MCP認可バイパスについては4件のPoCシナリオを研究者が検証済み

何が起きたか

Langflowは、ビジュアルなドラッグ&ドロップ形式でAIエージェントやワークフローを構築できるオープンソースのプラットフォームで、モデルやツール、業務データを連携させる用途で広く使われています。今回IBMのセキュリティ研究者が発見した6件の脆弱性は、いずれも異なる箇所に起因していますが、共通しているのはLangflowが利用者から渡されたコードやデータを、実行時に十分検証しないまま扱ってしまう場面が複数残っていたという点です。この種の問題はLangflowにとって今回が初めてではなく、当サイトで既報のCSV Agentの脆弱性や、JADEPUFFERのランサムウェア攻撃で悪用された脆弱性など、これまでにも繰り返し報告されてきました。

コード実行に直結する4つの脆弱性

今回の6件のうち4件は、最終的に任意のコードが実行されてしまう点で共通しています。CVE-2026-10134は、公開フローの中で使われるPythonCodeStructured Toolというコンポーネントを通じて悪意あるPythonコードを注入し、フローのビルド処理の過程でexec()関数によってそのコードを実行させるというもので、認証を必要としない点が特に深刻です。CVE-2026-7803は、送信するノードのコンポーネント種別のフィールドを空欄にするという単純な細工によって、本来であれば無効化されているはずのカスタムコンポーネントに対する検証をすり抜けさせ、ビルドの際に悪意あるコードを静かに実行させてしまう検証バイパスの問題です。

CVE-2026-7871は、Langflowがキャッシュのバックエンドとして利用しているRedisに関する問題で、dill.loads()というPythonのシリアライズ復元処理を、内容の整合性を確認しないまま使っていることに起因します。攻撃者が細工したペイロードをキャッシュへ注入できれば、それを後から読み取る任意のワーカープロセス上でコードが実行されてしまいます。CVE-2026-7873は、コードを検証するためのエンドポイントに存在する問題で、Pythonにおける関数のデフォルト引数がどのタイミングで評価されるかという仕様を悪用し、その関数を実際に呼び出さなくてもOSコマンドを実行できてしまうというものです。いずれも呼び出し元や経路は異なりますが、Langflowというプラットフォームがユーザー由来のコードを扱う機会の多さが、こうした問題が繰り返し見つかる背景にあると考えられます。

APIキーの越境流用とアクセス制御の不備

残る2件は、コード実行ではなく認可の仕組みに起因する問題です。CVE-2026-10140は、Langflowの音声モード機能に関するもので、APIキーをプロセス全体で共有されるシングルトンという形でキャッシュしてしまう実装上の不備により、本来は分離されているべき別のテナントのAPIキーが誤って再利用されてしまう恐れがあります。マルチテナント環境でLangflowを提供している事業者にとっては、他の利用者のAPIキーを使って課金が発生してしまう、いわゆる課金詐欺のリスクに直結する問題です。CVE-2026-7663は、Streamable MCPトランスポートと呼ばれるエンドポイントに関するもので、プロジェクトの所有権を確認する処理が欠けているため、本来は保護されているはずのリソースへ、認証を経ずにアクセスできてしまう問題です。IBMの研究者はこのMCP認可バイパスについて、実際に4件の概念実証シナリオが成立することを検証したとしています。

情報システム部門への示唆

自組織でLangflowを運用している場合、まずバージョンを確認し、可能な限り最新の1.10.1へアップデートすることをお勧めします。IBMの説明によれば、1.10.0の時点でMCP認可バイパスと未認証RCEの脆弱性には対応済みとのことですが、残るコード実行系の脆弱性を含めて包括的に対処するには1.10.1が必要です。あわせて、アップデート後はプロセスの再起動を行い、不適切にキャッシュされたAPIキーを確実にクリアしてください。単にファイルを差し替えるだけでは、メモリ上に残ったキャッシュの問題が解消されない可能性があります。

特にマルチテナント環境でLangflowを外部提供している事業者は、CVE-2026-10140によるAPIキーの越境流用が実際に発生していなかったかを、利用ログや課金記録を遡って確認することをお勧めします。公開フロー機能を利用している場合は、CVE-2026-10134やCVE-2026-7803が示すように、認証を経ずに到達できるエンドポイントの露出範囲を今一度点検し、必要のない公開フローは無効化しておくことが望まれます。当サイトで以前紹介したJADEPUFFERの事例のように、Langflowの脆弱性は単体の情報漏えいにとどまらず、そこを起点にした横展開や本番環境への侵害にまでつながった前例があります。今回のような複数件の脆弱性が一度に公表された際は、影響範囲を個別に評価するだけでなく、Langflowをインターネットに公開したまま運用していないか、公開する必要のあるコンポーネントを最小限に絞れているかという、運用全体の見直しの機会として捉えることをお勧めします。