← 記事一覧に戻る

AIエージェント基盤を直撃——Langflow深刻脆弱性CVE-2026-33017、公開20時間で実攻撃確認

2026年3月17日、AIエージェント構築フレームワーク「Langflow」に致命的な脆弱性が報告された。CVE-2026-33017、CVSSスコア9.3のクリティカル評定。認証なしでリモートコード実行（RCE）が可能なこの欠陥は、脆弱性情報の公開からわずか20時間以内に実際の攻撃として観測された。3月25日にはCISA（米サイバーセキュリティ・インフラセキュリティ庁）がKEV（既知の悪用済み脆弱性）カタログに正式追加。AI開発ツールを狙うサイバー攻撃が新たな局面に入ったことを示す事例となった。

この記事のポイント

欠陥の核心：exec()にサンドボックスなし

技術的な問題の所在は、一点に集約される。

対象エンドポイントは POST /api/v1/build_public_tmp/{flow_id}/flow。パブリックフローをビルドするためのAPIで、設計上は認証不要だ。このエンドポイントがオプションパラメータ data を受け付けた場合、データベースに保存された正規のフロー定義ではなく、攻撃者が送り込んだフローデータを使って処理を実行する。そのデータに含まれる任意のPythonコードが、サンドボックスもなく exec() に直接渡される。つまり「1回のHTTPリクエストで、認証なしに任意コードが実行できる」という状態だ。

さらに厄介なのがデフォルト設定だ。多くのLangflowインスタンスでは AUTO_LOGIN=true が有効になっている。この設定下では GET /api/v1/auto_login を叩くだけでスーパーユーザーのトークンが取得でき、攻撃者は自前のパブリックフローを作成して脆弱性を突くことができる。ここで気になるのは、このようなデフォルト構成が長期間、問題なく使われてきたという事実だ。セキュリティよりも導入容易性が優先されてきた結果と言えるだろう。

影響を受けるバージョンは1.8.1以前のすべて。広く報告された修正版「1.8.2」は、JFrogのセキュリティリサーチチームの検証により依然として脆弱であることが判明した。実際の修正が施されたのは1.9.0からである。

20時間、そして3フェーズの攻撃

Sysdigの脅威リサーチチームが観測した攻撃の進行は、段階的かつ組織的だった。

公開PoC（実証コード）は存在しなかった。にもかかわらず攻撃者たちは、アドバイザリの記述だけから動くエクスプロイトを構築し、インターネット上の脆弱なインスタンスをスキャンし始めた。最初の48時間で観測されたのは6つのユニークなソースIPからの攻撃試行。第1フェーズは4つのIPによる自動スキャンで、同一ペイロードを大量配布する形だった。第2フェーズでは別のIPが事前構築済みのインフラを使って偵察を実施。そして第3フェーズで、データ窃取が確認された。

奪われた情報は深刻だ。LangflowのインスタンスにはOpenAI、Anthropic、AWSのAPIキーや各種認証情報が環境変数として格納されていることが多い。これらが一度奪われると、接続先データベースへのアクセスや、ソフトウェアサプライチェーン全体への侵害へと話が広がる。AIエージェントのバックエンドを丸ごと掌握されるリスク——これがLangflowのようなオーケストレーション層を狙う攻撃の本質的な怖さだ。

CISAの対応と連邦機関への期限

CISAは3月25日、CVE-2026-33017をKEVカタログに追加した。これは単なる注意喚起ではなく、法的拘束力を持つ指示だ。

連邦民間行政機関（FCEB機関）に対し、2026年4月8日までの修正適用が義務づけられた。約2週間という期限は、KEVに追加される脆弱性の中でも厳格な部類に入る。同日のアナウンスでは、コンテナセキュリティツール「Trivy」のサプライチェーン侵害（CVE-2026-33634）についても同様の警告が出されており、AIおよびDevOpsツールチェーン全体を標的にした攻撃の広がりが見てとれる。

民間企業に対してCISAの命令に法的拘束力はないが、KEV追加は事実上の「直ちに対応すべき」シグナルとして機能する。脆弱性管理チームがパッチ優先度を判断する際の重要な指標となるため、実質的な影響は連邦機関にとどまらない。

構造的問題：同じ exec() での2度目の失敗

率直に言えば、今回の脆弱性を特に問題視すべき理由がある。これはLangflowにとって、exec() 起因のRCEとしては2件目の重大脆弱性だからだ。

前回のCVE-2025-3248（CVSSスコア9.8）は、別のエンドポイント /api/v1/validate/code を対象とし、同様の安全でないPython評価パターンを悪用したものだった。バージョン1.3.0で修正されている。同一コードベース内で、異なるエンドポイントが同じ根本的設計の欠陥を持っていたという事実は、「パッチを当てれば解決する」話ではないことを示している。JFrogは「1.8.2は修正済みとされながら依然として脆弱だった」という調査結果とともに、アーキテクチャ上の根本的な再設計が必要だと指摘している。

類似のAIツール脆弱性という文脈では、AnyscaleのRay（CVE-2023-48022）が参照事例として挙げられることが多い。あの事例も、分散AIワークロード基盤のAPIが認証なしでコードを実行できる状態に置かれ、大規模な悪用が起きた。LangflowとRayのいずれも、「AIのインフラを構築するツール自体」が攻撃対象になったという共通点を持つ。AIスタックが複雑化するほど、攻撃対象面（アタックサーフェス）は広がっていく。

対処と今後の視点

対応の優先順位は明確だ。現在使用中のLangflowインスタンスをバージョン1.9.0以上に更新すること。1.8.2への更新では不十分なため、特に注意が必要だ。修正内容はシンプルで、問題の data パラメータをエンドポイントから完全に削除し、パブリックフローが必ずデータベース上の正規設定のみを参照するよう変更された。

インターネットに直接公開されたLangflowインスタンスを運用している組織は、即時対応が求められる。即時アップデートが困難な場合は、ネットワークレベルでの当該エンドポイントへのアクセス制限が次善策となる。また、インスタンスに設定されていたAPIキーや認証情報はすべてローテーション（再発行・無効化）することを強く推奨する。侵害の痕跡確認（IOC）としては、/api/v1/build_public_tmp/ へのPOSTリクエストのログを遡って確認することが有効だ。

個人的に注目するのは、この事件が「AIツールのセキュリティ評価」という議論を加速させる契機になるかどうかだ。AIエージェントフレームワークは急速に普及しているが、それらのセキュリティ品質を評価する共通基準はまだ存在しない。LangflowのRCEが2度繰り返された事実は、AI基盤ソフトウェアに対してもソフトウェアサプライチェーンセキュリティと同様の厳格な審査が必要であることを、改めて突きつけている。

Sources: