Langflowに深刻なRCE3件、緩和設定も回避

AIエージェント開発ツール「Langflow」に、深刻度の高いリモートコード実行(RCE)の脆弱性が3件公表されました。影響を受けるのは 1.0.0 から 1.11.1 までの全バージョンで、修正版は 1.11.2 です。最大深刻度は CVSS 9.9。うち1件は認証なしで悪用可能です。

そして情シスにとって本当に厄介なのは、3件のうち2件が「カスタムコンポーネントを無効化する」という、これまで推奨されてきた緩和設定をすり抜ける点です。設定で守っていたつもりの環境も、今回は対象になります。

この記事でわかること

  • Langflowとは何で、なぜ「うちには無い」と言い切れないのか
  • 公表された3件のCVEの中身と、深刻度・認証要否の違い
  • 緩和設定 LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false が回避される意味
  • 自社に該当するかを確認する具体的な手順

Langflowとは何か（「うちは使っていない」と即断しないために）

Langflowとは、LLM(大規模言語モデル)を使ったAIエージェントやワークフローを、画面上でブロックをつなぐ操作で組み立てられるオープンソースの開発ツールです。プログラムを書かずにチャットボットや社内文書検索(RAG)の試作ができるため、開発部門だけでなく企画・情報システム部門の担当者が「まず触ってみる」用途で導入するケースが目立ちます。

問題は、これが資産管理台帳に載りにくいことです。Langflowは次の3通りで簡単に立ち上がります。

  • Python パッケージ：pip install langflow / uv pip install langflow で個人のPCやサーバに入る
  • Docker：langflowai/langflow イメージを docker run -p 7860:7860 で起動
  • デスクトップ版：Windows / macOS 向けのインストーラが公式配布されている

いずれも既定のポートは 7860、初期アクセス先は http://127.0.0.1:7860 です（公式インストール手順）。つまり、購買や稟議を通さずにエンジニアが検証用に立てた1台が、そのまま残っている――という形で社内に存在している可能性があります。なお本製品は現在 IBM が「IBM Langflow OSS」として自社のセキュリティ速報で情報を出す体制になっており、今回の情報もIBMから公開されました。

何が起きたのか

IBMは2026年8月24日、Langflowにコード実行に関する複数の脆弱性があるとしてセキュリティ速報を公開しました。内容は以下の3件です。

CVE番号 CVSS 種別 認証 概要
CVE-2026-19295 9.9（緊急） CWE-95 evalインジェクション 要（一般ユーザ） 細工した type フィールドを持つフローを保存し、それを参照するフローをビルドさせるとOSコマンドが実行される
CVE-2026-19286 9.8（緊急） CWE-94 コードインジェクション 不要 Agent-to-Agent(A2A)の公開エンドポイントでコード実行の検査が働かず、外部から任意のPythonが実行される
CVE-2026-18729 8.8（重要） CWE-94 コードインジェクション 要（一般ユーザ） PythonFunctionコンポーネントにコード実行の制限が掛かっておらず、任意コードが実行される

影響を受けるのは Langflow OSS 1.0.0 ～ 1.11.1。IBMは1.11.2 への更新を強く推奨しており、回避策(ワークアラウンド)は「なし」と明記しています。設定変更で凌ぐ選択肢は用意されていません。

なぜ「緩和設定を回避する」ことが問題なのか

Langflowには、利用者が任意のコードを書き込めるカスタムコンポーネント機能を止める LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false という設定があります。過去の悪用事例を受けて「とりあえずこれを切っておく」という運用をしていた組織は少なくないはずです。

しかし今回、CVE-2026-19295 と CVE-2026-18729 はこの設定を有効にしていても回避されるとIBMは説明しています。理由は、コード実行をブロックする検査が一部の経路にしか掛かっていなかったためです。たとえば CVE-2026-18729 では、別フローを呼び出す RunFlow コンポーネント経由の値の受け渡しで code というフィールド名だけを見て弾いていたため、共通の検査経路と同じ水準の遮断が効いていませんでした。CVE-2026-19295 では、フロー定義の型情報の文字列がPydanticの型解決処理を通じて eval() に到達していました。

いずれも「機能を止めるスイッチはあるが、抜け道が塞がれていなかった」という構図です。設定で緩和した気になっていた環境ほど、更新が後回しになっている恐れがあります。

Langflowは実際に狙われるのか

結論から言えば、狙われます。2025年にはLangflowの認証不備の脆弱性(CVE-2025-3248, CVSS 9.8)が悪用され、CISAの悪用が確認された脆弱性カタログ(KEV)に追加されました。その際は数百件規模のLangflowインスタンスがインターネットに露出していることがCensysの調査で確認され、その後ボットネットによる悪用も報じられています。

Langflowは「検証用だから」と社内の緩い環境に置かれがちですが、生成AIの試作環境という性質上、APIキーや社内文書の接続情報を抱えていることが多い点も見逃せません。踏み台にされるだけでなく、鍵と資料をまとめて持ち出される構図になり得ます。当メディアでも過去に WordPress・Langflowの脆弱性悪用でCISAが警告した件を取り上げましたが、同じ製品が繰り返し標的になっている事実は重く見るべきです。

自社に該当するか確認するには

台帳に載っていない前提で探すのが現実的です。次の順で当たりを付けてください。

  • ポート7860の待ち受けを探す：社内ネットワークのスキャン、およびインターネット側からの公開有無を確認する。公開されていれば最優先で遮断する
  • コンテナを確認する：稼働中のイメージ名に langflowai/langflow が無いか棚卸しする
  • Pythonパッケージを確認する：pip list / uv pip list の出力に langflow が無いか、開発用サーバや検証端末で確認する
  • A2A機能の利用有無：CVE-2026-19286 は A2A を有効にし、認証なし(auth_type=none)のエージェントフローを公開している場合に認証不要で悪用されます。該当するなら公開を即停止する
  • バージョンを見る：1.11.1 以下なら該当。uv pip install langflow -U 等で 1.11.2 以降へ更新する

現場目線の課題

正直なところ、この種のツールは情シスにとって一番見つけにくい部類です。サーバでもSaaSでもなく、誰かのPCやクラウドの検証インスタンスに、数分で立ち上がって残り続ける。稟議も申請も通らないので、こちらが能動的に探しに行かない限り存在に気づけません。生成AIの流行で「まず触ってみる」件数だけが増え、片付けは誰もしない、というのが実情ではないでしょうか。

加えて今回のように、緩和設定を入れていた環境まで対象になると、「対策済み」と記録していた台帳そのものが信用できなくなります。設定による緩和は更新までの時間稼ぎであって恒久対策ではない、という当たり前の原則を、あらためて社内で共有しておきたいところです。

情シスはどうすべきか

個別のチェックリストを長々と作るより、公的機関の指針に沿って「棚卸し」と「更新の仕組み」を回すほうが結果的に早く済みます。

関連して、社内のLLM基盤・AI連携部品の脆弱性は継続的に出ています。NVIDIA Dynamoの15件の脆弱性や、MCP Toolboxの認証回避のように、AIまわりの部品は「動かすこと」が優先され認証・権限の設計が後回しになる傾向があります。導入時点で公開範囲と認証を確認する習慣を付けておくと事故が減ります。

まとめ

  1. Langflow 1.0.0～1.11.1 に深刻なRCEが3件。1.11.2 へ更新する。回避策は提供されていません。
  2. 3件中1件(CVE-2026-19286)は認証不要。A2Aを有効にして認証なしフローを公開している環境は、更新前にまず公開を止めてください。
  3. カスタムコンポーネント無効化の設定は今回すり抜けられる。「設定済みだから安全」という記録は当てにせず、ポート7860とコンテナ・パッケージから実物を探し出しましょう。

出典

タイトルとURLをコピーしました