去年、生成AIの検証のために立てたサーバは、今どうなっているか。この問いに即答できない会社が、今回の対象である。
IBMは2026年7月2日、Langflow OSSに関するセキュリティ情報を公開した。CVE-2026-9198、CVSS基本値は9.8である。IBMの記載によれば、認証を経ていない攻撃者が、既定の構成で動作しているインスタンスに対してリモートコード実行を成立させられる。
そして米CISAは、2026年8月4日にこの脆弱性をKnown Exploited Vulnerabilities（KEV）カタログへ追加した。是正期限は2026年8月7日である。
IBMの公表が7月2日、KEV収載が8月4日。その間は33日である。
⚠️ **ここは正確に読む必要がある。KEVへの収載日は、CISAが悪用の存在をカタログに反映した日であって、悪用が始まった日ではない。**悪用がいつ始まったかは、この2つの日付からは分からない。言えるのは「公表から33日後に、悪用が公的な優先順位に反映された」ということだけである。
Langflow は、大規模言語モデルを組み合わせたアプリケーションを、画面上で部品をつなぐ形で構築するためのツールである。生成AIの検証を始めるときに、最初に触られる種類の製品である。
この記事を読むべき人
- 生成AIやAIエージェントの検証を、社内またはベンダー主導で実施した（している）会社
- 検証のために立てたサーバやクラウド環境が、今どうなっているか把握していない会社
- 現場や特定の部署が独自にAIツールを試している状態を、黙認している経営者
- PoCから本番化に進まないまま、環境だけが残っている会社
- AI活用を進めたいが、セキュリティ面の確認をどこまでやるべきか決めかねている会社
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
何が起きるのか：2つの入口が繋がっている
IBMの記載によれば、この脆弱性は2つの別々の問題が連鎖することで成立する。
1つ目は、認証を必要としないエンドポイント（/api/v1/auto_login）が、ネットワークから到達できる任意の相手に対して最上位権限のトークンを発行してしまうという問題である。
2つ目は、コードを検証するためのエンドポイント（/api/v1/validate/code）が、渡されたコードを実際に実行してしまうという問題である。IBMの説明では、Pythonのデコレータ、デフォルト引数、アノテーションが関数の定義時点で評価されるため、任意のコマンド実行につながる。
攻撃者は、まず1つ目で最上位権限のトークンを取得し、そのトークンで2つ目に悪意あるコードを投げる。これで、そのサーバ上で任意のコマンドが実行できる状態になる。
CVSSベクタは CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H とされている。ネットワーク経由、攻撃条件は容易、権限も利用者の操作も不要で、機密性・完全性・可用性のすべてに高い影響がある。9.8という数値は、この組み合わせから来ている。
IBMは影響を受けるバージョンを Langflow OSS 1.0.0 から 1.10.0 とし、1.10.1 への更新を強く推奨している。そして**回避策・緩和策の欄には「None（なし）」と記載されている。**設定変更で凌ぐ手段は用意されていない。
最も重要な一文は「デフォルト構成が対象」
技術的な詳細より、経営判断に直結するのは次の点である。
IBMの記載は、この問題が**「auto-login機能が有効で、検証用エンドポイントがネットワークから到達できる、既定の構成のすべての環境」**に影響すると述べている。
言い換えると、何も設定を変えずに立ち上げた環境が、そのまま対象である。
これが今回の事案の性格を決めている。セキュリティ設定を意図的に緩めた会社が被害を受ける、という構図ではない。「とりあえず動かしてみる」ために、手順書どおりに起動しただけの環境が対象になる。
そして「とりあえず動かしてみる」は、まさにPoC（概念実証）でやることである。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
PoC環境が放置される4つの理由
生成AIの検証環境が残り続ける構造には、いくつかの典型がある。
理由1：検証の終了が定義されていない。 「AIで何ができるか試す」という目的で始まった検証には、終わりの条件がない。**結果が出ても出なくても、明確に「終わった」と宣言される瞬間が来ない。**環境は動いたままになる。
理由2：立てた人と、管理する人が違う（あるいは管理する人がいない）。 現場が主導した検証では、情報システム部門が存在を知らないことがある。ベンダー主導の検証では、契約が終わった後に環境が誰の管理下にあるかが曖昧になる。
理由3：止めると再開のコストがかかると思われている。 「また使うかもしれない」という理由で残される。**この判断自体は不合理ではないが、残すなら管理対象に入れる必要がある。**入れないまま残すのが問題である。
理由4：資産一覧に「クラウド上の一時的な環境」を書く欄がない。 多くの会社の資産管理は、購入した物理機器とライセンスを対象にしている。数クリックで立って、月額数千円で動き続けるクラウド環境は、この枠組みから漏れる。
**この4つのうち、理由1が最も根本的である。**そして最も安く直せる。検証を始める前に「いつ、どうなったら終わりにするか」を1行決めるだけで、後の3つの多くが連鎖的に解消する。
AI基盤に集まるものを考える
放置されたサーバ一般の話に見えるかもしれないが、AIの検証環境には固有の事情がある。
この種のツールでLLMアプリケーションを組む際、外部サービスへ接続するための認証情報が環境内に保存されることが多い。生成AIのAPIキー、社内データベースへの接続情報、業務システムのAPIトークン、ファイル共有への認証情報。「AIに何をさせるか」を試すほど、AIが触れる先の認証情報が集まっていく。
つまり、検証環境が侵害された場合、影響はその1台に留まらない可能性がある。その環境に保存されていた認証情報を使って、接続先へ到達される経路が生じ得る。
**これはあくまで構造上の指摘であり、今回の事案で実際にそこまでの被害が起きたと述べているわけではない。**それでも、AI検証環境を棚卸しする際に「そのサーバに何が保存されているか」を確認項目へ入れる理由にはなる。
公表から悪用確認まで1か月をどう読むか
IBMの公表が2026年7月2日、KEV収載が2026年8月4日。この約1か月という間隔には、実務上の意味がある。
**この33日を「対応の猶予」と読んではいけない。**公表前から悪用が始まっている場合もあれば、収載がずっと後になる場合もある。KEVに載っていないことは、悪用されていないことの証明にはならない。
今回で言えば、**7月2日の時点で更新していれば、8月4日の収載を待つ必要はなかった。**一方、7月2日の公表を見ていなかった会社は、8月4日のKEV収載も見ていない可能性が高い。問題は情報を見る仕組みがないことであって、33日という期間の長短ではない。判断は、KEV収載を待たずに公表時点で行うべきものである。
そして、ここに検証環境固有の難しさがある。**本番システムであれば、ベンダーからの通知や保守契約を通じて情報が届く経路がある。**検証のために自分で立てた環境には、その経路がない。誰も通知してくれない。
今日できる確認の手順
大がかりな仕組みを作る前に、次の順で確認できる。
手順1：この1年で立てたAI関連の検証環境を、思い出せる範囲で列挙する。 情報システム部門だけでなく、各部署に聞く。完璧を目指さず、まず名前を挙げることを優先する。
手順2：それぞれについて、今動いているかを確認する。 クラウドであれば、請求明細は環境が存在し契約が続いていることの手掛かりになる。⚠️ **ただし課金の継続は「稼働している証拠」ではない。**計算資源を停止していても、ストレージ、固定IP、スナップショット、ログの保存には課金が続き得る。稼働しているかどうかは、クラウドの管理画面、API、あるいはネットワーク上の到達性で確認する必要がある。
手順3：動いている環境が、インターネットから到達できるかを確認する。 社内からしかアクセスできない環境と、外部に開いている環境では緊急度が違う。
手順4：外部に開いている環境について、止めるか、更新するか、アクセス制限をかけるかを決める。 使っていないなら止めるのが最も確実で、最も安い。
手順5：残すと決めた環境を、資産一覧に追加する。 ここまでやって、次回から情報が届く状態になる。
**手順2で「請求明細を見たら知らない環境があった」となる会社は珍しくない。**それ自体が、今回の記事の最大の実益かもしれない。
そして、この5手順は情報システム部門がいなくても回せる。必要なのは、各部署に聞くことと、クラウドの請求明細を開くことだけである。専門知識を要するのは手順3のみで、そこは委託先やクラウド事業者のサポートに聞けば答えが得られる。「担当者がいないからできない」という理由で止まる作業ではない。
環境が止められない本当の理由は、技術ではない
手順4で「止めるか、残すか」の判断に入ると、多くの会社がそこで詰まる。技術的には数分で止められるのに、決められない。
決められない理由は、たいてい次の3つのどれかである。そして、どれに当てはまるかで、取るべき次の行動が変わる。
分岐1：効果は確認できたが、本番化の予算と体制が付いていない。 この場合、環境を止めることは「投資を諦める」ことのように感じられる。だから残す。**しかし、残しておいても本番化は進まない。**進めるために必要なのは動いている検証環境ではなく、投資の意思決定に必要な材料——業務のどこにどれだけ効いたのか、本番化にいくらかかるのか、誰が運用するのか——である。**この材料が揃えば、環境は止めてよい。**材料を作らずに環境だけ残すのが、最も長引く形である。
分岐2：効果があったのかどうか、そもそも測れていない。 何をもって成功とするかを決めずに始めた検証は、この状態で終わる。**判断材料がないので、止める根拠も残す根拠もない。**この場合に必要なのは、検証の再実施ではなく、評価基準を後付けで定義することである。「この作業が何分から何分になったら本番化する」という一文を今から書けば、既存の環境で測り直せる場合が多い。
分岐3：やってみたが、現場で使われなかった。 これは最も明確に「止めてよい」ケースである。**にもかかわらず、失敗を認める形になるため放置されやすい。**ただし、ここで確認しておく価値があるのは、使われなかった原因が「AIが役に立たなかった」のか「業務の流れに組み込まれていなかった」のかである。**後者であれば、対象業務を変えて再挑戦する余地がある。**原因を記録せずに環境だけ消すと、次に同じことを繰り返す。
**3つのいずれの場合も、「投資判断が保留されたままである」という点は共通している。**そして、判断を保留したまま環境だけを動かし続ける理由は、通常はない。
⚠️ **ただし「常に止めてよい」という意味ではない。**停止を判断する前に、次の4点は確認したい。**他のシステムから定期的に呼び出されていないか。四半期末や年度末など、周期的にしか使わない用途がないか。保存が義務付けられているデータを保持していないか。止めた後に同じ環境を復元できるか。**この4点に該当しないのであれば、止めて差し支えない。止められない状態が続いているなら、それは技術の問題ではなく、投資判断が保留されたままであることの現れである。
よくある質問
Q. Langflowを使っていない。関係ないか。 A. 今回の脆弱性そのものは関係ない。**ただし、「デフォルト設定のまま立てた検証環境が外部に開いている」という構造は製品を問わない。**類似のAI開発基盤やローコードツールでも同じ形の問題は起き得る。確認すべきは製品名ではなく、自社の検証環境の状態である。
Q. 検証はベンダーに任せていた。ベンダーの責任ではないか。 A. 契約の内容による。確認したいのは、検証終了後の環境の撤去が契約範囲に含まれているか、含まれる場合に撤去完了の報告を受け取っているかである。「検証をする」という契約に、「終わったら消す」が含まれているとは限らない。
Q. 社内からしかアクセスできない環境なら安全か。 A. 今回の脆弱性は、ネットワークから到達できることが前提になっている。**外部から到達できないなら、直接の攻撃対象にはなりにくい。**ただし、別の経路で社内ネットワークに侵入された場合の横展開先にはなり得る。優先度は下がるが、対象から外す根拠にはならない。
Q. 更新すればよいのか、止めるべきか。 A. 使っているなら更新、使っていないなら停止が原則である。**ただし、判断に迷う環境をそのまま止めてはいけない。**本文で挙げた4点——他システムからの定期的な呼び出し、周期的な利用、保存義務のあるデータ、復元できるか——を先に確認する。依存関係が分からない場合は、いきなり停止するのではなく、外部からの到達を遮断して隔離し、状態のスナップショットを取り、変更の承認を得たうえで停止する順序にしたい。「止めて困る人が出たら戻す」という進め方は、止めた瞬間に業務が落ちる可能性を前提にしていない。
Q. 現場が勝手にAIツールを試すのを禁止すべきか。 A. 禁止は現実的でないことが多い。**禁止すると、報告されずに続くだけになる。**実務的には、「試すのは構わないが、立てたら情報システムに一報を入れる」というルールのほうが機能しやすい。把握できていない状態が最も悪い。
Q. AIの検証をこれから始める。何を先に決めておくべきか。 A. 3つある。**いつまでに何が分かったら終わりにするか、環境を誰が管理するか、終わったら誰が消すか。**この3つを開始前に決めておけば、環境が放置されるリスクを大きく下げられる。
Q. 検証環境まで管理すると、AI活用のスピードが落ちないか。 A. 落ちる要素は小さい。**上記の3つを決めるのに要する時間は、検証計画を書く中の数行分である。**むしろ、終了条件が決まっている検証のほうが、結論が出るのは早い。終わりのない検証は、判断されないまま長期化する傾向がある。
AI検証環境の整理と、本番化の判断から相談したいとき
放置されたPoC環境は、セキュリティの問題であると同時に、**AI投資が結論に至っていないことの現れでもある。**環境が残り続けているということは、その検証が「やる」とも「やらない」とも判断されていないということだからだ。
これまでに実施したAI検証の棚卸しと、本番化に進めるかどうかの判断材料の整理から着手したい場合は、AI導入アセスメントで対応している。検証は済んだが本番運用に移す段階で止まっている場合は、PoC本番化診断が該当する。
外部に開いている環境の有無を含めた技術的な確認をしたい場合は外部に開いている環境の有無を確認する、AIエージェントの業務適用そのものを設計し直したい場合はAIエージェント開発から相談できる。現在地の整理から始めたい段階であれば、AI導入診断で状況を確認できる。
なお、AI開発基盤の脆弱性を横断的に見た整理はAIプラットフォームの脆弱性の全体像、把握されていないAI利用そのものの統制は把握されていないAI利用の統制で別途扱っている。本稿は、検証環境が放置される構造と、その解消手順に絞っている。
参照した情報
- IBM Security Bulletin「Unauthenticated Remote Code Execution via Auto-Login Bypass and Code Validation」: https://www.ibm.com/support/pages/node/7278927
- CISA Known Exploited Vulnerabilities Catalog（JSON配信）: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
- CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
CVE-2026-9198、CVSS基本値9.8、CVSSベクタ、CWE-94（Improper Control of Generation of Code）、影響を受けるバージョン（Langflow OSS 1.0.0〜1.10.0）、修正バージョン（1.10.1）、回避策・緩和策が「None」と記載されている旨、2つのエンドポイントの連鎖による攻撃の成立過程、既定構成の環境が影響を受ける旨、および初回公開日（2026年7月2日）は、上記IBMのセキュリティ情報の記載に基づく。
KEVカタログへの追加日（2026年8月4日）および是正期限（2026年8月7日）は、KEVカタログのJSON配信（カタログバージョン2026.08.11）の該当エントリによる。
**AI検証環境に認証情報が集積することによる影響範囲の拡大は、GXOによる一般的なリスクの指摘であり、今回の事案でそうした被害が確認されたことを示すものではない。**PoC環境が放置される4つの理由、確認の5手順、および開始前に決めるべき3項目は、GXOが実務の中で組み立てた整理であって、IBMまたはCISAが示した基準ではない。攻撃の具体的な手法、悪用の観測範囲、および個別環境における影響判定については、本稿では扱っていない。なお、KEVの是正期限が適用されるのは米国連邦政府機関であって、国内企業に課された法令上の期限ではない。
