こんにちは、ひろかずです。
前回のブログ記事「NHIの脆弱性に組織はどう向き合うか」に関連する事案が起きましたので紹介します。
この記事が気になった方は上記リンクから閲覧してもらえると嬉しいです。
忙しい人向けの要約
- Q. Langflowを使っていない組織も対応が必要？
A. はい。本件の本質は「AIワークフロー基盤に認証情報を埋め込む」設計パターンであり、同型の基盤はすべて棚卸し対象です- 要点：Langflowで実際に悪用が起きている。 IDOR脆弱性CVE-2026-55255は、認証済みユーザーが有効なフローIDを入手できた場合に他ユーザーのフロー（ワークフロー）を実行できてしまう不備で、CISA KEVに登録され米連邦民間機関の対応期限は2026年7月10日（既に期限到来済み）。攻撃者はRCE脆弱性CVE-2026-33017と併用し、フローに埋め込まれた認証情報の窃取を試みていた。
- 本質は「AIワークフローに認証情報を埋め込む」設計。 Langflowのフローには日常的にAPIキー・認証情報・外部連携が埋め込まれるため、他人のフローを乗っ取れば、LLMプロバイダーの鍵・クラウド認証情報・DBシークレットが芋づる式に流出する。
- マルチテナント／マネージドSaaSで境界を越える。 RCE単体ではテナント間分離を破れないが、IDORはアプリ層でテナント境界を越え、正規の実行経路に乗って「被害者の認証情報で被害者のフローを実行」できる。
- これはシャドーAIそのもの。 業務部門が情シスの見えない場所にAI基盤を立てると、鍵の在処もオーナーも棚卸しできず、攻撃面になる。SaaS側でも「オーナー不在（ownerless）エージェント」の再割り当てが管理機能として必要になり始めている。
- やるべきは3つ。 ①AI基盤・AIエージェントの発見と台帳化、②シークレットを基盤に埋め込まず外部管理（Vault/Secrets Manager）＋最小権限化、③オーナー・ライフサイクル・監査ログの整備。
1. 何が起きているの？
Langflowは、AIエージェントとワークフローをGUIで組み立てるオープンソースの視覚的フレームワークで、個人開発者から企業、サービス提供者まで幅広く使われています。 このLangflowに、2つの脆弱性が絡んで実際の攻撃が起きています（Help Net Securityによる報道）。
- CVE-2026-55255（IDOR）：`/api/v1/responses` エンドポイントの安全でない直接オブジェクト参照（IDOR）が存在します。
- バージョン1.9.1より前では、認証済み攻撃者が有効な他ユーザーのフローIDを入手してリクエストに入れると、そのフローを実行できてしまいます。
- エンドポイントはクライアントが指定したフローIDを受け取った際に、リクエスト元がそのフローの所有者・実行権限を持つかを検証しません。
- 修正はLangflow 1.9.1で導入されています（公開当初はCVE Record/NVDに「1.9.2より前が影響」と記載されていましたが、現在はGitHub Advisory・CVE Record・NVDのいずれも1.9.1に統一されています）。
- CVE-2026-33017（コードインジェクション／認証不要のRCEに至りうる）
- 同一インスタンスに対して、同じ攻撃者がこの2つを同じ週に併用していたことをSysdigの脅威調査チームが観測しています（CVE-2026-33017自体の詳細はSysdigの日本語解説を参照）。
なお、CVE-2026-55255のCVSSスコアは出典により表記が異なり、CISA KEVでは6.1、GHSA／NVDでは9.9とされています。
Sysdigは、攻撃者が乗っ取ったフローに「APIキーを漏らせ（leak api keys）」というプロンプトを注入し、埋め込まれた認証情報を抜き取ろうとしていたと報告しています。
- 攻撃者はまず `GET /api/v1/flows/` で有効なフローIDを列挙し、入手したIDを `POST /api/v1/responses` の実行に再利用していました（フローUUIDは122bitランダムで総当たりは困難とされます）。
- 攻撃者は金銭目的・機会主義的で、主目的はCVE-2026-33017によるコード実行（RCEペイロードによるドロッパーとしてのシェルコマンド）と二次ペイロードの投下（ダウンロードは不発で、その機能は当該ホストでは未確認・他事例からの推定とSysdig記事に記載）でしたが、IDORも使ってLLMプロバイダーの鍵・クラウド認証情報・DBシークレットの窃取を試みていました。
タイムラインは次のとおりです。
| 日付 | 出来事 | 対象CVE |
|---|---|---|
| 2026年3月25日 | CISAがKEVに登録（先行） | CVE-2026-33017（RCE） |
| 2026年6月25日 | Sysdigが実環境での悪用を初観測 | CVE-2026-55255（IDOR） |
| 2026年7月7日 | CISAがKEVに登録 | CVE-2026-55255（IDOR） |
| 2026年7月10日 | 米連邦民間機関の対応期限 | CVE-2026-55255（IDOR） |
なお、CISAはKEV登録に伴い米連邦民間機関に対し、ベンダー指示に沿った緩和策の適用、BOD 26-04（リスクに基づくセキュリティ更新の優先順位付け）およびフォレンジックトリアージ要件への準拠、各資産のインターネット露出評価（緩和策が無い場合は利用停止）を求めています（CISA KEVカタログ）。
2. なぜ情報システム・セキュリティ担当者に関係するの？
AIワークフロー基盤とは、AIエージェントや処理の流れ（フロー）をGUIなどで組み立て・実行するための基盤ソフトウェアのことです。また、シャドーAIとは、情シスの把握・統制の外で業務部門などが独自に導入・運用するAIツールや基盤を指します。
Langflowを自社で使っていなくても、この一件は情シス・セキュリティにとって「対岸の火事」ではありません。理由は、AIワークフロー基盤という新しい種類の資産が、認証情報の集積地になっているという点です。
Langflowのフローには、日常的にAPIキー・認証情報・外部システム連携が埋め込まれます。そのため、他人のフローを参照すれば、それだけでクロステナントのデータ露出とシークレット窃取に連鎖します。 本件を「アプリの脆弱性が1つ見つかった」という話として片づけることはできません。「AI基盤を立てた時点で、そこにクラウドの鍵束を置いている」という設計の話です。
こうした基盤は、AIエージェントの利用と普及が広がった昨今、業務部門をはじめとする非エンジニア層が自分たちで立てがちです。生成AIの利便性は「連携するほど上がる」ため、メール・カレンダー・ドキュメント・チャット・クラウドストレージへのアクセス権が次々と付与されます。
連携によって利便性が向上する一方で、本来であれば設計時に検討されるべきセキュリティが見逃され、気がつけば攻撃面が広がっている図式は、個人向けAIエージェントの露出事例でも繰り返し確認されています。
たとえばAIエージェント基盤OpenClawでは、公開インスタンスが1週間足らずで約1,000件から21,000件超へ急増したと報告されています（Censysの調査ブログ、2026年1月31日時点。Recoによる整理も参照）。
ThreatLockerも2026年6月の総括（CEOのDanny Jenkins氏のコメント）で、AIを使った脅威が注目を集めた一方、同社が6月に調査した攻撃の多くは結局「信頼されたアクセスの悪用」に行き着いたと指摘しています。
これは、AIそのものが新種のリスクというより、AIワークフロー基盤やワークロードが野放しになった結果、「信頼された鍵」に手を届かせてしまうことが問題の核心です。
なお、AIエージェントやAI基盤に対してアクセス統制を適用する考え方は「Anthropicが発表したゼロトラスト「Zero Trust for AI agents」解説、AIにもゼロトラストを適用して運用する方法」でも解説しています。
2-1. よくある誤解
誤解1：「Langflowを使っていないから関係ない」。
- 問題の中心は特定の製品名よりも、「AIワークフロー基盤にシークレットを埋め込む」設計パターンにあります。Dify、Flowise、n8n風のツール、各SaaSの内蔵エージェントビルダーなど、同じ構造を持つ基盤は、認可やシークレット管理について同型のリスクを抱えうるため、個別に確認が必要です。
誤解2：「認証を有効にしてあるから安全」
- CVE-2026-55255は認証済みユーザーが他人のフローを実行できるIDORです。「ログインできる人＝そのデータに触れてよい人」ではありません。テナント間・ユーザー間の認可（認証ではなく認可）が別途必要です。
誤解3：「マルチテナントはサンドボックスで隔離しているから大丈夫」
- RCEはテナント間のサンドボックス分離を単体では破れませんが、IDORはアプリ層で境界を越え、プラットフォーム自身の正規実行経路に乗って被害者の認証情報でフローを走らせます。ワーカー隔離だけでは守れません。なお、単一組織のセルフホスト環境では、そもそもRCE単体でホスト上のすべて（全フロー・埋め込まれた認証情報を含む）が侵害されうるため、隔離の有無にかかわらず修正版の適用が前提です。
誤解4：「ローコードAIエージェント基盤は使わせない、で解決」
全面禁止は現実的でなく、地下に潜るだけです。目指すべきは「発見して管理下に置く」ことです。
3. 実務で問題になりやすいポイント（一般論です）
多くの企業で、AI活用を進める過程で次の論点が繰り返し立ち上がります。いずれも導入直後より運用開始後に表面化し、監査や経営説明の場で問われやすいものです。
- 台帳に載らないAI基盤が増える。 業務部門が自前で立てたAIワークフロー基盤・エージェントは、情シスのSaaS台帳にも資産管理にも載らず、誰が・どの権限で・何に繋いでいるかが不明になりがちです。
- シークレットが基盤内に「べた書き」される。 手早く動かすため、APIキーやクラウド認証情報がフロー内・環境変数・設定にそのまま埋め込まれ、外部のシークレット管理を経由しません。
- 権限が広すぎる。 「とりあえず動かす」ために、必要以上に広いスコープの鍵やサービスアカウントが払い出され、そのまま放置されます。NHI（非人間ID）とは、人間ではなくプログラムやサービスが利用するID・認証情報（APIキーやサービスアカウント等）を指し、本件はそのNHIの過剰権限問題そのものです。シークレット管理とは、こうしたAPIキーや認証情報を安全に保管・配布・ローテーションする仕組みのことです。
- オーナー不在（ownerless）になる。 立てた人が異動・退職すると、そのAI基盤・エージェントは管理者不在のまま権限だけ生き続けます。Microsoftも2026年6月2日付のMicrosoft 365 Copilotリリースノートで、ポリシーベースのルールにより「オーナー不在エージェントを適切な管理者へ再割り当てする」機能（Roadmap ID 481518）の提供開始を発表しており、ベンダー側でもこの問題が管理課題として認識され始めています。
- 監査ログが中間ステップまで残らない。 エージェントの最終出力しか残らず、途中でどのツールを・どの認証情報で呼んだかが追えないと、インシデント時に影響範囲を特定できません。
4. 具体的な技術的・運用的な確認ポイント
自社環境で、以下点を確認してください。
- AI基盤の発見：CASB／SWG（Netskope等）のログ、EDRのプロセス／通信、IdPのアプリ連携、クラウド課金、ネットワーク上の露出ポートから、社内外で稼働するAIワークフロー基盤・エージェントを洗い出す。自己ホスト型はインターネット露出の有無も確認する。
- Langflow等を使っている場合の緊急対応：Langflowは1.9.1以降の最新版へ更新（CVE-2026-55255の修正）。RCE（CVE-2026-33017）は影響が1.8.1以下・修正版1.9.0のため、こちらの適用状況も別途確認し、SysdigやSentinelOneが公開するIOC（侵害の痕跡）を突き合わせる。
- シークレットの在処：フロー・設定・環境変数に認証情報がべた書きされていないか。外部シークレット管理（Vault／各クラウドのSecrets Manager）へ寄せられているか。
- 鍵の権限とローテーション：AI基盤が使う鍵・サービスアカウントのスコープは最小か。露出した前提でローテーション（再発行）できる運用になっているか。
- 認可（テナント／ユーザー分離）：マルチテナント・共有環境で、認証に加えて、「誰がどのフロー・データにアクセスしてよいか」の認可が実装・検証されているか。
- オーナーとライフサイクル：各AI基盤・エージェントにオーナーが割り当てられ、異動・退職時に棚卸し・再割り当て・停止される運用があるか。
- 監査ログ：エージェントが呼び出した中間のツール／API／認証情報まで監査可能な粒度でログが残るか。
5. 取り得る対応方針とその比較
| 対応方針 | 概要 | メリット | 留意点 | 向いている状況 |
|---|---|---|---|---|
| 全面禁止 | ローコードAI基盤の利用を原則禁止 | 短期的に攻撃面を抑制 | シャドー化して地下に潜る／競争力を損なう | 高規制・極小チーム |
| 発見＋台帳化（可視化優先） | まずCASB/EDR/IdP等で棚卸しし台帳化 | 実態把握が進む／統制の起点になる | 発見だけでは是正されない | ほぼ全ての組織の第一歩 |
| シークレット外部化＋最小権限 | 鍵を基盤に埋めずVault等で集中管理・最小スコープ化 | 露出時の被害を局所化 | 既存フローの改修が必要 | 稼働中のAI基盤がある組織 |
| 認可・テナント分離の強化 | 認証に加えユーザー／テナント単位の認可を実装・検証 | IDOR型の横断被害を防ぐ | 設計・テスト工数が要る | マルチテナント／共有基盤 |
| ライフサイクル管理 | オーナー付与・棚卸し・再割り当て・停止を運用化 | オーナー不在化を防ぐ | 継続運用の体制が要る | エージェントが増え続ける組織 |
現実解は、「発見＋台帳化」→「シークレット外部化＋最小権限」→「認可強化」→「ライフサイクル管理」と段階を踏んでいく進め方です。
6. 進めていく上でのチェックリスト
- 社内外で稼働するAIワークフロー基盤・エージェントを洗い出し、台帳化した
- Langflow等の該当製品を使っている場合、修正版へ更新しIOCを確認した
- フロー・設定・環境変数へのシークレットべた書きを解消し、外部シークレット管理へ寄せた
- AI基盤が使う鍵・サービスアカウントを最小権限化し、ローテーション手順を用意した
- 認証に加えてユーザー／テナント単位の認可を実装・検証した
- 各AI基盤・エージェントにオーナーを割り当て、異動・退職時の再割り当て／停止フローを整えた
- エージェントの中間ツール呼び出しまで監査ログを取得・保全できる
- 自己ホスト型のインターネット露出を確認し、不要な公開を止めた
7. 本件を進める上での経営層・監査部門への説明ポイント
- リスクの一文要約：「業務部門が自前で立てたAIワークフロー基盤に、クラウドやSaaSの認証情報が埋め込まれており、そこが1つ破られると鍵束ごと外部に渡る」。実際にLangflowでこの型の攻撃が起き、CISAはKEVに登録し米連邦民間機関に対応期限（2026年7月10日・既に到来済み）を課しました。
- 論点の切り分け：これは「AIを使うか否か」の話ではありません。「AI基盤という新しい資産を、資産管理・シークレット管理・ID管理の統制下に置けているか」というガバナンスの話である、と整理する。
- 監査で問われる観点：AI基盤の台帳、シークレットの管理方法、鍵の最小権限とローテーション、オーナーとライフサイクル、監査ログの粒度。いずれも既存のIT統制・ISMSの延長で説明できます。
- 投資対効果：発見と台帳化・シークレット外部化は比較的低コストで着手でき、露出時の被害を大きく局所化できる「守りの投資」であると位置づける。
8. 実務担当者が次に取るべき対応ステップ
- 【今すぐ】該当製品の緊急対応：Langflow等を使っていれば修正版へ更新し、IOCを突き合わせ、露出インスタンスを閉じる。
- 【今週】発見と台帳化：CASB／EDR／IdP／課金からAI基盤・エージェントを洗い出し、オーナー・接続先・権限を台帳化する。
- 【今月】シークレット外部化と最小権限：べた書きの鍵を外部シークレット管理へ移し、スコープを絞り、ローテーション手順を定める。
- 【四半期】認可・ライフサイクル・監査ログ：テナント／ユーザー分離の認可を検証し、オーナー再割り当て・停止フローと監査ログ整備を運用に落とす。
- 【継続】ポリシー化：AI基盤の立て方・鍵の扱い・承認フローを社内ルール化し、「便利さは活かしつつ、鍵は会社の統制下に置く」状態を維持する。
9. まとめ
AIエージェント／ワークフロー基盤は、業務の生産性を確かに押し上げます。一方で、それは「クラウドの鍵束を新しい場所に置く」ことでもあります。Langflowの一件が示したのは、その鍵束が、認証済みユーザーが有効なフローIDを入手できればテナントを越えて盗まれうるという現実です。
まずは、社内で静かに増えているAI基盤を「発見して台帳に載せる」ところから始めてください。
次に鍵を基盤の外へ出し、最小権限とローテーションで守る。そして認可・オーナー・監査ログを整える。
前回記事でも言及しましたが、本件の本質はガバナンスです。禁止よりも統制下に置くこと。それが現実的な守り方です。
また、AIに脆弱性対応を任せる際の統制の考え方は「AnthropicのDefending Code Reference Harnessを読む AIに脆弱性対応を任せる前に必要なこと」で解説しています。あわせて参照してください。
FAQ
Q1. Langflowを使っていなければ対応は不要ですか？
いいえ。問題の中心は個別の製品よりも、「AIワークフロー基盤に認証情報を埋め込む」設計パターンにあります。同型の基盤（Dify・Flowise・n8n風ツール・各SaaSの内蔵エージェントビルダー等）はすべて同じ棚卸しの対象になります。
Q2. CVE-2026-55255はどれくらい危険ですか？
実際に悪用が確認され、CISA KEVに登録（2026年7月7日）、米連邦民間機関の対応期限は2026年7月10日でした（既に到来済み）。認証済みユーザーが他ユーザーのフローを実行でき、埋め込まれた認証情報の窃取に連鎖します。
Q3. IDORとは何ですか？
Insecure Direct Object Reference（安全でない直接オブジェクト参照）の略で、リクエストで指定したIDに対して「その人がアクセスしてよいか」を検証しない不備です。今回は、認証済みユーザーが別途入手した他ユーザーの有効なフローIDを渡すと実行できてしまう不備でした。
Q4. 認証強化やサンドボックス隔離では防げないのですか？
いいえ。本件は認可（アクセスしてよいかの検証）の不備であり、MFAやパスワードポリシーなどの認証強化では塞げません。また、IDORはアプリ層でテナント境界を越えるため、ワーカー隔離だけでも防げません。対処は修正版への更新・インターネット露出の遮断・埋め込まれた鍵のローテーション・IOC確認です。
Q5. まず何から始めるべきですか？
発見と台帳化です。CASB／EDR／IdP／クラウド課金から社内外で稼働するAI基盤・エージェントを洗い出し、オーナー・接続先・権限を可視化します。次に、基盤内にべた書きされた鍵を外部のシークレット管理（Vault／各クラウドのSecrets Manager）へ集約し、最小権限・ローテーション運用にします。
Q6. オーナー不在のエージェントや、ローコードAI基盤の利用自体はどうすべきですか？
全面禁止はシャドーIT化を招くため、「発見して管理下に置く」のが現実解です。オーナー不在のものは棚卸しでオーナーを再割り当てするか、不要なら停止します。Microsoft 365 Copilotでもオーナー不在エージェントの再割り当てが管理機能として提供され始めています。
おわりに
「自社にどんなAI基盤・エージェントが立っているのか分からない」「鍵がどこに埋まっているのか棚卸しできていない」という状況は、いま多くの情シス・セキュリティ部門が同時に直面しています。
繰り返しますが、本件の本質はガバナンス体制にあります。ツールに頼る前に、まずは自社状況の整理から始めるのが有効です。
