チームが信頼するAIアプリビルダーに、root権限のバックドアが存在

現在、企業向けソフトウェアで最も急速に成長しているカテゴリーは、セキュリティの観点から最も精査されていない分野でもあります。AIアプリケーションプラットフォームは、コードをほとんど書かずにAI搭載ワークフローを構築・連携・自動化できるツールです。こうしたツールが、セキュリティチームの評価が追いつかない速さで本番環境に導入されています。これらはAPIやデータベース、クラウドの認証情報、AIサービスのアカウントに接続されます。そして攻撃者は、すでにそこに目を付けています。

Langflowは、こうしたプラットフォームの中でも特に広く導入されているものの1つです。オープンソースのローコードツールで、AIモデルやAPI、データソースをドラッグ＆ドロップで組み合わせ、大がかりな開発をしなくても動作するアプリケーションやエージェントのワークフローを作れます。手軽に使えることが急成長の理由であり、8月末に起きた出来事が、Langflowを導入しているあらゆる組織にとって重要である理由でもあります。

2026年8月29日、 VulnCheckの脅威インテリジェンスチームは、インターネットに公開されたLangflowインスタンスに対する攻撃の試みが続いているのを確認しました。悪用された脆弱性はCVE-2026-0768で、CVSSスコアは9.8です。この脆弱性は、2026年1月にゼロデイとして公に開示される前から、Langflowのコードベースに存在していました。8月末に始まった攻撃は、いまも衰えていません。

この脆弱性が実際に引き起こすこと

Langflowのカスタムコンポーネントエディターには、validateエンドポイントがあります。開発者がワークフローに追加する前に、コードスニペットをテストするための機能です。本番で動かす前にロジックを確認できるようにするという発想自体は妥当ですが、問題は実装にあります。

このエンドポイントは、ユーザーが送信したコードをそのままPythonのexec()に渡します。 実行前の入力検証は一切なく、多くのデフォルト構成ではエンドポイントへのアクセスに認証すら不要です。インターネットに公開されたLangflowインスタンスにネットワーク経由で到達できる攻撃者は、細工したリクエストをこのエンドポイントに送るだけで、任意のPythonコードを即座に実行できます。実行はroot権限で行われ、認証情報もユーザー操作も必要ありません。

侵入後の攻撃の流れは迅速で、パターンも一貫しています。攻撃者は.envファイル、環境変数、SSH鍵、ソースコードを探し出し、OpenAIのAPIキー、AWSの認証情報、クラウドストレージのトークン、データベースの認証情報を収集します。盗まれた認証情報は外部のインフラに送信され、攻撃者はSSHなどのプロトコルを使って横展開を試みます。最初の悪用から認証情報の窃取までの一連の動きは、通常のAIワークフローの活動に紛れてほとんど痕跡を残さないため、検知は格段に難しくなります。

VulnCheckは、英国に設置したハニーポットで、公開後の数日間に360件を超える攻撃の試みを記録しました。攻撃トラフィックの大半はロシアから発信されていました。この数字は、監視対象のシステムで観測できた試行の数にすぎません。監視されていない本番環境でどれだけ攻撃が成功したのかは、わかっていません。

なぜこれが繰り返されるパターンになりつつあるのか

Langflowの脆弱性は、単独で現れたわけではありません。 2026年より前に、実際の攻撃で悪用されたLangflowの脆弱性は1件だけでした。それが今年は12件に増えています。VulnCheckは、CVE-2026-0768が加わる前の段階で、関連する3つのLangflowの欠陥（CVE-2026-0769、CVE-2025-3248、CVE-2026-5027）に対し、1万5,000件を超える攻撃の成功を記録しました。

その理由は、Langflowが突然安全でなくなったからではありません。攻撃する価値があるほど、Langflowが重要な存在になったからです。 VulnCheckの研究者が指摘するとおり、AI技術の急速な普及とともに、セキュリティ優先の原則よりも使いやすさを重視して設計されたツールが広がりました。オープンソースで入手でき、導入が簡単で、幅広いAPIと連携し、クラウドサービスやAIアカウントにつながる。AIアプリケーションプラットフォームが企業チームにとって魅力的である理由は、コード実行の足がかりが見つかれば、そのまま攻撃者にとっての魅力にもなります。

同じ構図は、かつてCI/CDプラットフォームで、次にKubernetes管理ツールで繰り返されてきました。そして今、AI開発基盤で起きています。ツールのカテゴリーは急速に成長し、セキュリティの精査は後れを取ります。導入数が攻撃の手間に見合う規模になった段階で、攻撃者が動き出すのです。

CVE-2026-0768が未修正のままインターネットに公開されたLangflowインスタンスは、Langflow固有の問題というより、認証情報の漏えいの問題です。開発者の.envファイルから盗まれたOpenAIのAPIキーは、どのように盗まれたかを問いません。環境変数から収集されたAWSの認証情報も、あとからパッチを適用したところで失効しません。 この調査と同時に公表されたRailsの欠陥も、この点をはっきり示しています。漏えいした秘密情報は、それを露出させた脆弱性が修正されたかどうかにかかわらず、ローテーションするまで悪用可能な状態が続きます。

今すぐ実施すべき3つの対策

1. ただちにパッチを適用し、公開されているインスタンスをすべて洗い出す。1.4.2までのすべてのLangflowバージョンが影響を受けます。 VulnCheckは、公開から数時間以内に攻撃の試みを観測し始めました。パッチが提供されてから、攻撃者が未適用のインスタンスをスキャンし始めるまでの猶予は、日単位ではなく時間単位です。validateエンドポイントの前段に認証がないまま、インターネットから到達できるLangflow環境は、いま現在、実際のリスクにさらされています。まず、自社環境にインスタンスがいくつあり、そのうちどれがインターネットに公開されているかを把握してください。インシデントの際に、開発・テスト用の環境がセキュリティチームの把握しないまま公開されていたと判明する組織は少なくありません。
2. 公開されたLangflowインスタンスに触れたすべての認証情報をローテーションする。インスタンスが実際に攻撃されていないと考えていても、これは省略できません。この攻撃は、.envファイル、環境変数、SSH鍵、クラウドの認証情報を狙います。これらはLangflowの通常運用中、ディスクやメモリ上に残り続けるものです。影響を受けるバージョンのLangflowを動かしていた環境に保存されたOpenAIのAPIキーやAWSのアクセス認証情報は、侵害された可能性があるものとして扱うべきです。ローテーションを実施し、認証情報の提供元側のアクセスログで、正規の所有者が行っていないリクエストがないかを確認してください。 VulnCheckの指針は、観測された攻撃キャンペーンの主な標的としてOpenAIとAWSの認証情報を特に挙げています。攻撃を受けたかどうかにかかわらず有効な対策は、認証情報のローテーションだけです。
3. 認証なしでAI開発プラットフォームをインターネットに公開しない。デフォルト構成でLangflowのvalidateエンドポイントに認証がないことが、この攻撃を直接可能にしています。ただし、原則はもっと広く当てはまります。AIアプリケーションプラットフォーム、ワークフロー自動化ツール、エージェント開発環境は、一般消費者向けのサービスではありません。本番の認証情報やクラウドアカウント、社内APIに接続されています。インターネットに面したエンドポイントに認証層を設けないまま運用するのは、開発用データベースをインターネットに公開するのと同じです。こうした環境はVPNの内側に置くか、ネットワーク境界で認証を必須にしてください。ほかの社内開発インフラに適用しているのと同じアクセス制御を適用すべきです。

率直な評価

LangflowのCVE-2026-0768は深刻な脆弱性ですが、より重要なのは、それが示している傾向です。 過去のすべての年を合わせて1件だったLangflowの悪用が、2026年に12件へ増えたのは偶然ではありません。攻撃者が、かつてクラウド管理ツールや開発パイプラインを攻略したのと同じように、AIツールのスタックを順番に、計画的に攻めていることを示すシグナルです。

SaaSアプリケーションやクラウドの認証情報、開発パイプラインの可視化に投資してきたセキュリティチームは、初期の悪用に続く横展開を検知しやすい立場にあります。最も危険にさらされているのは、AI開発プラットフォームをインフラではなく生産性向上ツールとして扱っている組織です。急いで導入し、本番の認証情報に接続し、ほかのあらゆるものを守るセキュリティ境界の外に置いたままにしています。

CVE-2026-0768にはパッチが公開されており、修正版も入手できます。しかし、8月29日から組織がパッチを適用して認証情報をローテーションするまでの間に収集された認証情報は、別の問題です。そちらには、ベンダーからのアップデートはありません。