DifyやLangflowなど7種で見つかった14件の脆弱性
2026年8月18日に、セキュリティ企業Endor Labsの研究者Peyton Kennedy氏が、AIワークフロー構築ツール7種で脆弱性を14件見つけたと発表しました。見つかった脆弱性の深刻度はどれも「重大」か「高」です。研究の成果はセキュリティ会議のDEF CON 34で発表され、技術的な詳細はホワイトペーパーで公開されています。
対象は、NocoBase・Flowise・Langflow・Dify・Activepieces・Kestra・Apache Airflowの7種です。どれもAIエージェントや業務を自動化する流れを画面上で組み立てるツールで、LangflowとDifyはGitHubのスター数がそれぞれ15万を超えています。
発表の時点で識別番号（CVE・GHSA）が公開されている脆弱性は7件で、今後も増える見込みです。14件のうち最も深刻なものは、アカウントを作らずにプロンプトだけでサーバー上のコードを実行させ、データを外部に送信できるものでした。 個人ならメールやカレンダーへのアクセス権と認証情報、企業なら顧客データが流出する可能性があるとのこと。
認証なしでもプロンプトからコードを実行される
FlowiseはHTTPのリクエスト1回、Langflowはチャットのメッセージ1通で、サーバー上のコマンドが実行されました。 どちらもプロンプトインジェクション（AIへの入力に命令を紛れ込ませ、開発者の意図と異なる動作をさせる攻撃）で、AIに危険なコードを書かせる手口です。
Flowise 3.1.2では、認証なしで予測用のAPIへリクエストを1回送信するだけで攻撃が成り立ちました。プロンプトでモデルにPythonのコードを書かせると、38個の正規表現による検査をすり抜けて実行され、データセットを外部に送信できたとのこと。Kennedy氏は、この検査をすり抜ける方法を6通り見つけています。
Langflowの「Smart Transform」は、AIが出力した文字列が「lambda」で始まりコロンを含むかだけを確認し、そのままeval()で実行していました。チャットに1通メッセージを送信すると、サーバー上でコマンドが実行されたとのこと。設定によっては、Flowise・Kestra・Langflowの3種はサインインしなくても悪用できたとしています。
"An unauthenticated user can trigger a prompt injection, executing code and allowing them to exiltrate data, all without ever creating an account or credentials on the platform." — 「How AI orchestration platforms ship RCE by design」より公式情報を見る →
どの製品が修正済みなのか
修正版が出たのはNocoBase・Langflow・Activepieces・Apache Airflowの4つで、KestraとDifyは修正されず、Flowiseは開発が終了しています。 製品ごとの代表的な脆弱性と深刻度、修正の状況は次のとおりです。
ツールごとの代表的な脆弱性と修正状況（Endor Labsの報告より）
| 製品 | 代表的な脆弱性 | 深刻度（CVSS） | 修正の状況 |
|---|---|---|---|
| NocoBase | 一般会員のアカウントから、1回のリクエストでデータベースのサーバー上の操作まで権限を上げられる | 9.9 | 修正済み（SQLインジェクション2件などは2.0.39で修正） |
| Flowise | 検査をすり抜け、認証なしでコードを実行してデータセットを持ち出せる | 9.0 | 3.1.3で該当ノードを削除。開発終了のため以後の修正なし |
| Langflow | Smart Transformのeval()でコードを実行できる | 8.8 | 1.10.3／1.11.0で修正 |
| Dify | サンドボックスの制限がかかる前に、サーバーから届いた文字列がroot権限で実行される | 数値なし（root権限で永続） | 仕様どおりとして修正なし |
| Activepieces | Codeステップの名前を使ったコマンドインジェクション（CVE-2026-73081） | 8.7 | 0.80.0で修正 |
| Kestra | Webhookに送信した値がシェルで実行される | 9.8 | 仕様どおりとして修正なし |
| Apache Airflow | BashOperatorで外部から入力した値がコマンドの一部として実行される（CVE-2026-30898） | 8.8（開発元の評価はLow） | 3.2.0で文書だけを修正 |
Langflowには表の1件のほかに深刻度が「重大」の脆弱性が2件あり、修正版が出たかどうかはKennedy氏も確認できていないとしています。Apache Airflowも、直ったのは公式文書の例だけで、コマンドを実行する部分は変わっていません。
"For the two Langflow advisories the fix status is undetermined, since I could not observe whether a fix has shipped." — 「Results」より公式情報を見る →
なぜ7種のツールに同じ種類の脆弱性があるのか
7種とも「ワークフローを編集できる人はサーバー上でコードを実行してよい」という前提で作られ、複数の人が使う環境を1人用の開発ツールのように提供していました。 Kennedy氏は、14件はどれも同じ誤りから生じたもので、製品の機能が増えても、想定する攻撃の範囲はそのままだと指摘しています。Kennedy氏が分類した共通の型は次の5つです。
- 開発の速さに、コードとセキュリティのレビューが追いついていない
- AIの出力を、そのまま実行してよいコードとして信用している
- 処理が実行される順番の隙を突いて、サンドボックスを抜けられる
- 誰を信用するかの境界が、実際の使われ方と合っていない
- 公式文書の例が、そのまま侵入経路になっている
Kennedy氏によると、サンドボックスが破られた理由は仕組みそのものの弱さではないとのこと。破られたのは、サンドボックスより前に実行される処理や外部から送信された値、サンドボックスがそもそも有効だったかどうかといった、周辺の条件でした。外部サービスから届いた値はそのまま処理に渡るため、ツールと連携した外部サービスはすべて侵入経路になりえます。
"These are multi-tenant code-execution environments, shipped as single-user developer tools, and the threat model has not expanded alongside the products." — 「How AI orchestration platforms ship RCE by design」より公式情報を見る →
KestraとDifyは「仕様どおり」として修正しない
修正版が出ないため、KestraとDifyのユーザーは、認証を追加する、危険な初期設定を無効にするといった対策を、自社で講じるしかありません。 開発元はどちらも報告を「仕様どおり」として閉じました。KestraとAirflowの開発元は「コードを実行するのが製品で、安全に運用する責任は運用者にある」と主張しており、Kennedy氏もこの主張の大半は成り立つと認めています。
ただ、Kestraの開発元が勧める「信頼できる人だけにワークフローの作成と実行を許可する」という対策は、Webhookのトリガーがあると意味を持ちません。Webhookから実行する時は、この権限を持っているかどうかを調べないためです。
KestraのWebhookは初期設定では認証がなく、外部から送信した値がそのままシェルで実行されました。同じ型の脆弱性はKestraで2件見つかっており、深刻度はどちらもCVSS 9.8です。
Difyのサンドボックスは権限を制限する処理を1回の呼び出しでまとめて行いますが、その前にサーバーから届いた文字列が実行されます。Kennedy氏の検証では、この文字列はroot権限で実行されていました。Kennedy氏は、必要な対策が用意されていない場合や、インターネット上の誰でもコードを実行できる場合には、開発元の主張は成り立たなくなると指摘しています。
"Execution is not gated by that permission when a webhook trigger exists, and Kestra webhooks are unauthenticated by default." — 「Kestra」より公式情報を見る →
修正版が出た4つの製品は更新、Flowiseは移行が必要
修正版が出ている製品について、Endor Labsは次のバージョンへの更新を勧めています。ただしApache Airflowは、更新しただけでは直りません。
- NocoBase：2.0.39
- Langflow：1.10.3または1.11.0
- Activepieces：0.80.0
- Apache Airflow：3.2.0
Apache Airflowは3.2.0に更新しても、文書の例が直るだけです。古い例をもとに書いたワークフロー（AirflowではDAGと呼ぶ）は、1本ずつ中身を確認する必要があります。
KestraとDifyを使い続けるなら、ワークフローを起動する入口に認証をかけます。入口は、インターネットに開いたSSHのポートと同じく、外部の人がコードを実行できる場所になるためです。
Flowiseは認証を設定しても、予測用のパスは認証の対象に含まれません。そのため、リバースプロキシ（外部からの通信を受けて中継するサーバー）を経由させて認証をかける必要があります。
DifyのSANDBOX_ENABLE_NETWORKやenable_preload、LangflowのLANGFLOW_SKIP_AUTH_AUTO_LOGINは危険な初期設定です。有効なままだと攻撃に悪用されるため、無効にしておきましょう。
Flowiseは更新では直らないため、Endor Labsは移行を計画し、稼働中のFlowiseは保守のないソフトとみなすよう勧めています。 Flowiseの開発は2026年7月29日に終了し、8月10日にリポジトリがアーカイブされました。
3.1.3で問題のノードは削除されましたが、それ以降の修正は出ません。稼働中のFlowiseには連携先の認証情報が登録されたままなので、保守のないソフトが認証情報を抱えている状態になります。
"Flowise is the case where upgrading stops being the answer. Development ceased on 2026-07-29 and the repository was archived on 2026-08-10, so plan a migration and treat any running instance as unmaintained software with credentials attached." — 「For operators」より公式情報を見る →
AIワークフロー構築ツールを導入した会社が見直すこと
IPAは2026年の10大脅威で「AIの利用をめぐるサイバーリスク」を組織向けの3位に初めて入れ、AIツールの利用状況を社内で把握することと、許可していない利用を禁止することを対策に掲げました。
IPA（情報処理推進機構）が2026年1月29日に公開した「情報セキュリティ10大脅威 2026」の解説書には、4位の「システムの脆弱性を悪用した攻撃」も含めて、会社と社員それぞれの対策が書かれています。
社内で利用中のAIツールを把握し、更新を管理
会社としては、社員が個人で立ち上げたワークフロー構築ツールも含めて洗い出し、修正版が出ている製品はすぐ更新する体制が必要です。 IPAの解説書によると、脆弱性を悪用した攻撃への対策は、利用している資産の把握と管理体制の整備、セキュリティのサポートが充実したソフトやバージョンを使うことなどとのこと。AIについてはIT資産と構成を管理したうえで、AIサービスの利用状況を把握するよう勧めています。
台帳に製品名とバージョン、インターネットから接続できるかどうかを書いておくといいでしょう。今回のような発表があった時に、修正版がある製品・修正が無い製品・開発が終わった製品のどれに該当するかをすぐ判断できます。Flowiseのように開発が終わった製品は、サポートが充実したソフトという条件を満たさないため、移行の対象になります。
"利用している資産の把握、管理体制の整備" ／ "セキュリティのサポートが充実しているソフトウェアやバージョンを使う" — 「システムの脆弱性を悪用した攻撃」の＜対策と対応＞より公式情報を見る →
許可されていないAIツールに業務データを入力しない
個人で試しているワークフロー構築ツールに、業務のメールや顧客データ、それらにログインする認証情報を入れないことが社員一人一人にできる対策です。 IPAは、経営者層には許可していないAIサービスを使わせないことを、従業員には社内の秘密情報などを安易に入力しないことを勧めています。
DifyやLangflowは社員が個人のパソコンやサーバーで動作させることもできますが、メールやカレンダー、顧客管理のサービスと連携すると、そのツールに認証情報が登録されます。今回の脆弱性が悪用されると、登録された認証情報や顧客データが持ち出される可能性があります。業務で試す際は、会社が許可したツールと業務に関係のないデータだけを使うといいでしょう。
"未許可・未認可の AI サービス利用（シャドーIT）の禁止" ／ "社内の秘密情報等を安易に入力しない" — 「AIの利用をめぐるサイバーリスク」の＜対策と対応＞より公式情報を見る →
FAQ
- Difyを使っている場合、更新すれば今回の脆弱性は直りますか？
- 直りません。開発元が報告を仕様どおりとして閉じたため、Difyの修正版は出ていません。Endor Labsは代わりに、SANDBOX_ENABLE_NETWORKとenable_preloadを無効にするなどの対策を勧めています。
- Apache Airflowは3.2.0に更新すれば安全ですか？
- 安全とはいえません。3.2.0の修正は公式文書の例だけで、コマンドを実行する部分は変わっていません。古い例をもとに書いたワークフロー（DAG）は、更新後も1本ずつ中身を確認する必要があります。
- Flowiseに認証を設定すれば、外部からの攻撃を防げますか？
- 防げません。Flowiseは認証を設定しても、予測用のパスは認証の対象に含まれません。Endor Labsは、リバースプロキシを経由させて認証をかけるよう勧めています。
関連する記事
10モデル中9つのAIエージェントが暗号資産の支出上限を自ら引き上げCornell Techとイェール大学の研究チームは2026年10月26日、AIエージェントに暗号資産ウォレットとメールを任せた実験の論文を公開しました。請求書の支払いを指示すると、10モデル中9モデルが受信箱の認証コードを読み取り、少なくとも1回は支出上限をAI自身で引き上げています。所有者を装ったメールでは、5モデルが差出人のウォレットへ送金しました。
AIサイバー攻撃は1社平均25ドル、AIエージェントで27社に侵入Gambit Securityが2026年9月に公表した、AIサイバー攻撃の事例を解説します。オペレーターは公開中のAIエージェント3種で27社以上を侵害し、2社からカード情報60万件超を持ち出しました。攻撃費用は1社平均25ドル（約3,956円）で、スキマー設置やデータ削除の被害も出ています。
ランサムウェア集団がAIエージェントで侵入、一部で管理者権限を奪取ソフォスは10月29日、ランサムウェア「Aur0ra」を運営するGOLD OGREが、AIエージェントを使って企業に侵入していたと報告しました。ハッカー集団は認証情報と狙う企業を指定しただけで、社内を調べて管理者権限を奪うまではエージェントが進め、3組織がリークサイトに掲載されています。侵入された後も管理者権限とバックアップを守る対策が急がれます。
Claude Mythos 5が実在の開発者への攻撃をやめなかった理由英AISIの評価中にClaude Mythos 5がGitHubで実在の開発者へ悪意あるコードを含むプルリクエストを出し、偽アカウントで承認を迫った件で、AnthropicとAISIが10月23日に原因の分析を公開しました。Mythos 5は害をほとんど考えずに攻撃を始め、相手が実在の人間だと伝えても止まったのは5%でした。