LangflowのSSRF脆弱性、AI開発ツールの守り方

LangflowのSSRF脆弱性、AI開発ツールの守り方 脆弱性・脅威情報

何が起きたか：AIワークフロー構築ツール「Langflow Desktop」に、SSRF（サーバサイドリクエストフォージェリ）の脆弱性 CVE-2026-3341 が公表されました。
誰に影響するか：Langflow Desktop 1.0.0〜1.9.2 を社内で使っている組織。
今すぐ何をすべきか：利用の有無を棚卸しし、修正版へ更新。ネットワーク露出を絞る。

注目すべきは「DNSリバインディングでSSRF保護を回避できる」点です。一度は対策が入った機能が、別の手口ですり抜けられた格好で、AI開発ツールが攻撃対象として継続的に狙われている現状を象徴しています。

  • この記事でわかること
  • CVE-2026-3341 の概要と影響範囲（バージョン・深刻度）
  • 「DNSリバインディングによるSSRF回避」とは何か
  • Langflowが繰り返し狙われてきた背景（実悪用の事例）
  • 社内に増える「AIツール」を情シスがどう守るか

CVE-2026-3341とは何か

CVE-2026-3341とは、IBMが提供するAIワークフロー構築ツール「Langflow Desktop」に存在するSSRF（サーバサイドリクエストフォージェリ）の脆弱性です。認証済みの攻撃者が、Langflowのサーバに細工したリクエストを送らせることで、本来アクセスできない内部ネットワークやサービスへ到達できる恐れがあります。

影響範囲と深刻度

項目 内容
CVE番号 CVE-2026-3341
脆弱性の種類 SSRF（CWE-918）／DNSリバインディングによる保護回避
影響を受ける製品 IBM Langflow Desktop 1.0.0 〜 1.9.2
CVSS v3スコア 5.4（警告）AV:N/AC:L/PR:L/UI:N
必要な権限 あり（認証済みの利用者）
想定される影響 内部ネットワークの探索、機密情報への不正アクセス、他の攻撃の足がかり
公表日 IBMセキュリティ情報 2026年6月11日／JVNDB登録 2026年6月17日

深刻度はCVSS 5.4の「警告」レベルで、緊急という数値ではありません。ただし攻撃に高度な前提条件は不要で、認証さえ通れば成立する点には注意が必要です。社内の検証用途で「とりあえず動かしている」ようなインスタンスほど、認証や公開範囲が緩く、リスクが現実化しやすいといえます。

DNSリバインディングによるSSRF回避とは

SSRF対策の定番は「リクエスト先URLが内部アドレス（localhostやプライベートIP、クラウドのメタデータ等）でないかを検証する」ことです。Langflowにもこの種の保護が実装されていました。

DNSリバインディングは、この検証を時間差ですり抜ける手口です。具体的には次の流れになります。

  1. 攻撃者は自分が管理するドメインを指定する。
  2. 検証の瞬間、そのドメインは無害な外部IPを返す → チェックを通過する。
  3. 実際にリクエストする瞬間、DNSの応答を内部IP（例：169.254.169.254 などのメタデータ）に切り替える → 内部に到達する。

つまり「検証時」と「通信時」でDNSの答えが変わる時間差（TOCTOU）を突くわけです。URL文字列だけを見るブロックリスト方式では防ぎきれないため、対策が入った製品でも回避される例が後を絶ちません。

なぜAI開発ツールでSSRFが起きやすいのか

Langflowのように「指定したURLからデータを取り込む」機能を持つツールは、URLをユーザーが自由に与えられる以上、SSRFの素地を構造的に抱えています。AIエージェントやRAG（外部データ参照）の文脈では「外部サイトを読みに行く」動作そのものが機能の中核であり、ここを安全に作り込むのは想像以上に難しいのが実情です。

Langflowは繰り返し狙われてきた

今回のSSRFは単発の話ではありません。Langflowはここ数か月、複数の深刻な脆弱性が相次いで公表されています。情シスとして押さえておきたいのは、その一部が実際に攻撃へ悪用されたという事実です。

  • CVE-2026-33017（認証不要のリモートコード実行）：セキュリティ各社の報告によると、アドバイザリ公開からおよそ20時間後には実環境での攻撃が観測されました。公開PoC（実証コード）が出回る前の悪用で、環境変数やAPIキーの窃取、データベース接続情報の抽出などが狙われたとされます（※外部調査ベースの報告であり、被害範囲の全体像は限定的）。
  • CVE-2026-3340（URLコンポーネントのSSRF）：今回のCVE-2026-3341と同系統の問題で、より広い範囲のバージョンに影響しました。

RCE（コード実行）はSSRFより明確に危険ですが、両者は無関係ではありません。SSRFで内部の管理画面やメタデータに到達できれば、認証情報を得て次の攻撃（RCE含む）の足がかりになり得ます。「単体ではCVSS中程度」でも、攻撃連鎖の入口として軽視できないということです。

現場目線の課題：見えない「社内AIツール」

正直なところ、こうしたニュースで最初に困るのは「そもそも自社で使っているのか分からない」ことではないでしょうか。Langflowのようなツールは、開発部門やデータ分析の担当者が業務効率化のために個人判断で導入しているケースが少なくありません。情シスの管理台帳に載っていない、いわゆるシャドーAIです。

限られた人員で全端末・全サーバの導入物を把握しきるのは、現実には骨が折れます。ましてAI関連ツールは進化が速く、昨日まで存在を知らなかった製品が今日には社内で動いている、ということも起こり得ます。脆弱性が出るたびに「うちは大丈夫か？」を即答できる体制づくりは、多くの現場で積み残しになっているのが実感ではないでしょうか。

情シスはどうすべきか

個別ツールの設定を細かく追うより、まずは「棚卸し」と「公的指針の活用」を軸に据えるのが現実的です。自前で長大なチェックリストを抱え込むのではなく、整備された公式ガイドへ橋渡しする発想が、限られた工数では効きます。

まず確認すべきこと

  • 利用棚卸し：Langflow（および類似のAIワークフロー／RAG構築ツール）が社内で使われていないか、開発・分析部門にヒアリングする。
  • 更新：使っていれば、IBMのセキュリティ情報に従い修正版へ更新する。
  • 露出の最小化：検証用インスタンスを社外・社内広域に公開しない。認証を必須にし、到達できるネットワーク範囲を絞る。
  • 監視：内部宛て・メタデータ宛ての不審な通信や、見慣れない外部コールバックを監視対象に加える。

公的指針を起点にする

脆弱性対応の進め方や、利用者への注意喚起・教育については、IPAの公開資料が出発点として有用です。

技術的な防御策はもちろん重要ですが、「新しいツールを入れたら情シスに一報する」という地道な文化づくりこそ、シャドーAIの最良の歯止めになります。便利なAIツールを頭ごなしに禁止するのではなく、安全に使える土俵を一緒に整える姿勢が、結果的に現場との信頼関係と可視性を高めます。

まとめ

  • Langflow Desktop 1.0.0〜1.9.2にSSRF脆弱性 CVE-2026-3341（CVSS 5.4）。DNSリバインディングでSSRF保護を回避され、内部ネットワークへ不正アクセスされる恐れ。利用していれば修正版へ更新を。
  • Langflowは認証不要RCE（CVE-2026-33017）が公開後ごく短時間で実悪用された経緯があり、AI開発ツールは継続的な攻撃対象。SSRFも攻撃連鎖の入口として軽視できない。
  • 最大の課題は「社内で使われているか分からない」シャドーAI。まずは棚卸しと露出の最小化、そしてIPA等の公的指針を起点にした体制づくりを。

出典

コメント

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