n8nプラットフォームの脆弱性により、認証済みユーザーなら誰でも基盤サーバーを完全に侵害でき、企業環境全体で認証情報や秘密情報、AI駆動型ワークフローが露出する可能性があった。
この脆弱性のCVSSスコアは10.0で、攻撃者はn8nのJavaScriptサンドボックスを脱出して任意のコマンドを実行できる。これにより、通常のワークフロー・ロジックが実質的にシステム全体の完全な制御へと変わってしまう。
「誰も気づかないうちに、これらのプラットフォームは至宝になっている。機密性の高いワークフローも、AIプロンプトも、認証情報も、すべてオーケストレーション層を通過する」と、Pillarの研究者はeSecurityPlanetへのメールで述べた。
さらに、「本当のリスクは単一のシステムにはなく、システム同士をつなぐものにある。今後、AIエージェントはまもなく、こうしたワークフローを自律的に構築・変更するようになるだろう。あるエージェントが別のエージェントのオーケストレーション層を侵害する――それが、発生してからではなく、今まさに防御策を設計すべき攻撃チェーンだ」と付け加えた。
n8nのサンドボックス脱出の実態
n8nは中核的な業務プロセスの自動化に広く使われており、企業全体でAI駆動型ワークフローのオーケストレーション層としての役割も increasingly大きくなっている。
組織はn8nを利用して、社内システムやクラウドサービス、大規模言語モデルをエンドツーエンドの自動化パイプラインに接続している。
そのため、1件の侵害は単一の連携やワークフローだけに影響するのではない。クラウド認証情報やデータベース、機密性の高い業務・顧客データを日常的に処理するAIパイプラインまで露出する可能性がある。
リスクはセルフホスト型のn8n環境とn8n Cloudの双方に及ぶ。
クラウド環境では、n8nの共有マルチテナント・アーキテクチャによって被害の拡大範囲が大幅に広がり、1つの侵害されたテナントが隣接するサービスやデータを脅かす可能性が高まる。
問題の中心にあるのはn8nの式エンジンだ。ユーザーはこのエンジンを使い、JavaScriptをワークフローに直接埋め込める={{ }}構文を利用する。
この機能は、動的なデータ変換や高度なAIオーケストレーションを可能にするもので、プラットフォームの柔軟性を支える大きな理由となっている。
しかしその一方で、ユーザーが提供したJavaScriptはサーバー側で評価される。
n8nは内在するリスクを抑えるため、危険なJavaScriptオブジェクトやランタイム・プリミティブへのアクセスを防ぐことを目的とした、抽象構文木（AST）ベースのサンドボックスを採用している。
Pillarのセキュリティ研究者は、このサンドボックスを完全に回避できることを発見した。
管理者権限がなくてもワークフローを作成・編集できる認証済みユーザーなら誰でも、サンドボックスを脱出し、n8nサーバー上でリモートコード実行（RCE）を達成できた。
攻撃に成功すると、攻撃者は環境変数を読み取り、ファイルシステムにアクセスし、N8N_ENCRYPTION_KEYを窃取できた。
このキーを使えば、クラウドプロバイダーのアクセスキーやOAuthトークン、データベースのパスワード、OpenAIやAnthropicなどのAIサービスのAPI認証情報を含む、保存済みのすべての認証情報を復号できる。
初期の脆弱性チェーンはCVE-2026-25049として追跡されており、n8nのASTサニタイズ・ロジックの隙に起因していた。
研究者は、テンプレートリテラルによるプロパティーアクセス、V8のError.prepareStackTraceフック、アロー関数のスコープという複数のJavaScriptの挙動を組み合わせ、サンドボックスの外側にある本当のグローバルオブジェクトへ到達した。
n8nは2025年12月にパッチを公開したものの、研究者は24時間以内にObject.defineProperty()を使って回避策を発見した。
サニタイザーはプロパティーアクセス構文に狭く焦点を当てていたため、メンバーへの直接アクセスなしにオブジェクトのプロパティーを変更できるJavaScript APIを考慮できていなかった。
いずれの場合も結果は同じだった。通常のワークフロー式に見えるものの内部から、完全なリモートコード実行が可能になったのである。
最終的に、AST解析の個別の回避手法ではなく、より広範な欠落クラスに対処する包括的な修正がバージョン2.4.0で公開された。
情報公開時点で、実際の環境で悪用された証拠はなかった。
n8nとAIワークフローのリスクを軽減する
n8nの脆弱性は影響が大きく、比較的容易に悪用できるため、対策は単一のパッチ適用にとどめるべきではない。
修正版への更新は重要な第一歩だが、効果的にリスクを低減するには、露出を抑え、可視性を高め、インシデント発生時の迅速な対応を支える対策も必要になる。
- パッチをn8nバージョン2.4.0以降に直ちに適用し、N8N_ENCRYPTION_KEYと、プラットフォームに保存されているすべての認証情報をローテーションする。
- 信頼できるユーザーにワークフローの作成・編集・テンプレートのインポートを限定し、本番ワークフローの変更にはレビューまたは承認を義務付ける。
- 強力なランタイム制御を使ってn8nのワークロードを分離し、コンテナの強化や最小権限、その他の機密システムとの分離などを実施する。
- 外向きのネットワークアクセスを承認済みエンドポイントのみに制限し、監視して、AIプロバイダーのベースURLなど、宛先が未承認で変更されていないか確認する。
- 外部で管理するシークレットを使って認証情報の露出を減らし、短期間だけ有効なトークンと、各ワークフローおよび連携に対する最小権限アクセスを利用する。
- ワークフローとランタイムの挙動を監視して悪用の兆候を探し、不審な式や予期しないプロセス実行、異常なネットワーク活動などを確認する。
- をテストし、更新してインシデント対応計画によって、チームがワークフローの侵害を迅速に封じ込め、認証情報をローテーションし、信頼できる自動化状態を復元できるようにする。
これらの対策は、侵害が発生した場合の影響を封じ込めるとともに、将来の自動化層への攻撃に対する組織のレジリエンスを強化する。
AIオーケストレーション・プラットフォームのリスク
n8nのサンドボックス脱出は、自動化およびAIオーケストレーション・プラットフォームが、従来型の多くのセキュリティ対策より上流に位置する価値の高い標的になっていることを浮き彫りにした。
こうしたツールがより多くのシステムを接続し、AI駆動型の意思決定をますます管理するようになる中、セキュリティチームはアプリケーションレベルの安全策が破られる可能性を前提とし、破られた場合にも被害の拡大範囲を抑えられるアーキテクチャを設計しなければならない。
こうしたリスクの変化を受け、組織はゼロトラストソリューションを導入し、システムとワークフローの相互接続性が高まる中で、侵害の影響をより適切に抑えようとしている。