CVE-2025-68613：n8nにおける式インジェクションによるリモートコード実行

エグゼクティブサマリー

ワークフロー自動化プラットフォームn8nは、サーバー側の式評価エンジンにおける重大なリモートコード実行（RCE）の脆弱性（CVE-2025-68613）の影響を受けました。インターネット上には、潜在的に脆弱なn8nインスタンスが103,476件確認され、地域によって濃淡はあるものの世界中に分布しています。影響を受ける製品はAI機能と業務プロセス自動化を組み合わせ、サードパーティソリューションとの400以上の連携を備えているため、侵害に成功すると企業環境に影響し、攻撃者が機微情報へアクセスできる可能性があります。

AI搭載のワークフロー自動化プラットフォームを狙うことは新たな攻撃ベクトルをもたらし、データ侵害や悪意あるコード配布につながる脅威アクターの機会を増やす可能性があります。こうしたソリューションは現代のITサプライチェーンにおける重要な構成要素です。本欠陥により、認証済みユーザーがワークフロー内に悪意あるJavaScript式を投入し、意図されたサンドボックスを回避して、n8nプロセスの権限で任意のコードを実行できます。式はサーバー上で評価されるため、悪用に成功するとn8nインスタンスの完全な侵害につながります。

実際には、ワークフローの作成または編集に限定された低権限の権限しか持たない攻撃者であっても、次のことが可能になります：

• 任意のOSコマンドを実行する
• 機微なシークレット（APIキー、トークン、パスワード）を窃取する
• ホスト上のファイルを読み取る／改ざんする
• 基盤サーバーを完全に掌握する

この脆弱性は、攻撃の複雑性が低く影響が大きいこと、そして中核機能に影響することから、CVSSスコア9.9（Critical）を受けました。当社HUNTERチームは、防御側に対して想定される悪用手法と企業環境への影響について注意喚起するため、本脆弱性に関する詳細な調査レポートを作成しました。CVE-2025-68613を悪用した悪意ある活動の影響は容易に見積もれず、攻撃者が侵害後段階でバックドアを設置していた場合、長期的な結果をもたらす可能性があります。新たな大規模データ侵害が発覚するかもしれません。サイバー犯罪者は、組織が冬季休暇中に警戒が手薄になることをよく理解しています。監視が限定され、チームが逼迫する時期に合わせて、フィッシング、ランサムウェア、データ窃取などの攻撃を仕掛けることが多いのです。CVE-2025-68613の悪用急増はクリスマス前後に検知されており、潜在的な被害を避けるためには、迅速な評価、是正、侵害防止が重要であることを示しています。

脆弱性の概要

n8n – ワークフロー自動化プラットフォーム

n8nは、技術チームがアプリケーションやサービスを接続し、カスタムの自動化プロセスを構築できるオープンソース（フェアコードライセンス）のワークフロー自動化プラットフォームです。

n8nでは、ワークフローはノードの視覚的なグラフとして設計され、各ノードは次のようなタスクを表します：

• APIリクエストを行う
• データを処理または変換する
• ロジックや条件を実行する
• メッセージ送信やデータベースへの書き込みを行う

n8nは、ローコード／ノーコードのドラッグ＆ドロップエディタの簡便さと、カスタムコード実行の柔軟性を兼ね備えています。ユーザーは事前構築済みの統合ノードを利用することも、より高度なロジックが必要な場合にJavaScript / Pythonコードを挿入することもできます。

このハイブリッドなアプローチにより、技術チームはノーコードのスピードを得つつ、従来のプログラミングの力も維持できます。n8nは一般的に次の用途で利用されます：

• データワークフローの自動化
• APIオーケストレーション
• チャットボットおよびAIパイプライン
• IT / DevOps自動化
• CRMおよび業務プロセス自動化

n8nはセルフホストも可能で、クラウドサービスとして利用することもでき、組織はデータとインフラを完全に制御できます。

n8nの仕組み

概念的には、n8nのワークフローはノードからなる有向グラフです。

すべてのワークフローはトリガーノードから始まり、ワークフローがどのように、いつ実行されるかを定義します。例：

• Webhookトリガー
• スケジュール（cron）トリガー
• 外部サービスからのイベントベーストリガー

トリガーされると、n8nは接続された各ノードを順次実行します。各ノードは：

1. 入力データを受け取る
2. アクション（API呼び出し、ロジック、変換など）を実行する
3. 出力を次のノードへ渡す

ワークフロー例

シンプルなワークフローは次のようになります：

1. Schedule Trigger – 毎日08:00に実行
2. HTTP Request – 外部APIからデータを取得
3. Function Node – データを処理またはフィルタリング
4. Slack Node – 通知を送信

各ワークフロー実行はログに記録されます。ユーザーは次のことができます：

• ノードごとの入出力データを確認する
• 実行履歴を確認する
• 失敗した実行を再実行またはデバッグする

内部的にn8nはNode.js上で動作し、多数の同時実行を効率的に処理できます。

なぜn8nが重要インフラなのか

組織はn8nを次の目的で利用します：

• データベースとクラウドサービスを統合する
• データ処理パイプラインを自動化する
• CRM、ERP、社内システムを接続する
• 機微データやAPI認証情報を管理する

ITインフラにおけるこの中心的役割により、脆弱性は特に危険となります。攻撃者にネットワーク全体や機微データへのアクセスを与え得るためです。

影響を受けるバージョンと修正済みバージョン

脆弱性CVE-2025-68613は、式評価エンジンにおける不適切なサンドボックス化により、複数のn8nリリースブランチに影響します。

公式アドバイザリおよびパッチリリースに基づくと、影響を受ける／修正済みのバージョンは次のとおりです：

脆弱なバージョン

• 0.211.0以降のすべてのn8nバージョン
• 1.120.3まで（1.120.3を含む）
• 1.121.0
• 1.122.0より前の初期1.122.xリリース

要するに、上記のパッチ適用済みリリースより前のバージョンを実行しているn8nインスタンスは脆弱です。

パッチ適用済みバージョン

本問題は次のバージョンで修正されています：

• 1.120.4 — 1.120.xブランチ向けパッチ
• 1.121.1 — 1.121.xブランチ向けパッチ
• 1.122.0以降 — 今後の完全修正済みベースライン

n8nの式を使って中核問題を理解する

ステップ1 – 式とは何か？

式とは、値に評価されるJavaScriptコードです。

n8nでは、式は{{ }}の中に記述され、サーバー側で実行されます。

ユーザーは次のように式を書きます：{{ 2 + 2 }} 結果：4

n8nはこれらの式をブラウザではなくサーバー上で実行します。

ステップ2 – 式には関数を含められる

JavaScriptの式は数学に限定されません。
即時に実行される関数呼び出しを含めることができます。

(function () {
  return 10 + 5;
})()

結果：15

n8nでは： 

{{ (function () { return 10 + 5 })() }}

結果：15

n8nは式が安全な計算機のように振る舞うと想定していますが、実際には本物のJavaScriptです。

ステップ3 – JavaScript関数にはコンテキスト（this）がある

JavaScriptでは、すべての関数はthisと呼ばれるコンテキストで実行されます。

function showThis() {
  return this;
}
console.log(showThis());

結果
global { process, setTimeout, … }

n8nの式

{{ (function () { return this })() }}

n8nの出力

{
  process: {...},
  Buffer: {...},
  setTimeout: [Function],
  ...
}

thisは空ではありません — Node.jsランタイムを露出させます。

ステップ4 – サーバー上でこれが危険な理由

thisの型を確認してみましょう：

function check() {
  return typeof this;
}
console.log(check());

結果：object

これは次を意味します：

• thisは空ではない
• 実体のあるオブジェクトである
• ランタイム内部情報を含む

n8nの式

{{ (function () { return typeof this })() }}

n8nの出力：object

これにより次が確認できます：

• thisは存在する
• オブジェクトである
• ランタイムデータを含む

ステップ5 – n8nが式を評価する方法

内部的に、n8nは概念的には次のようなことを行います：

function evaluateExpression(expression) {
  return eval(expression);
}
evaluateExpression("2 + 2");

結果：4

n8nでの同等表現

{{ 2 + 2 }}

n8nの出力：4

eval()は完全な実行コンテキストでコードを実行します。

ステップ6 – 評価される式の中のthis

ここで両方の考えを組み合わせます。

コード

function evaluateExpression(expression) {
  return eval(expression);
}
const expr = "(function () { return this })()";
console.log(evaluateExpression(expr));

結果：
global { process, … }

n8nの式

{{ (function () { return this })() }}

n8nの出力

{
  process: {...},
  Buffer: {...},
  ...
}

これがCVEの核心です
Node.jsのグローバルオブジェクトは次を露出します：

• process（環境変数、実行コンテキスト）
• require()（モジュール読み込み）
• コアランタイムAPI

その結果、攻撃者が制御する式は次のことが可能になります：

• Node.jsのコアモジュールを読み込む
• OSレベルのコマンドを実行する
• シークレットや認証情報にアクセスする
• ランタイムの挙動を改変する

本来、式は：

• 制限されるべきだった
• しかしNode.jsのグローバルコンテキストを継承してしまった

ステップ7 – n8nの想定と現実

n8nの想定

{{ (function () { return 1 + 1 })() }}

出力：2

現実（安全でないコンテキスト）

{{ (function () { return this })() }}

出力
Node.jsのグローバルオブジェクト
式が意図された境界を逸脱しました。

脆弱性の仕組み

ステップ1：ワークフロー式の評価

n8nでは、ワークフロー内にJavaScript式を埋め込み、データを動的に処理・変換できます。これらの式は{{ }}で囲まれ、ワークフロー実行中にNode.jsを用いてサーバー側で評価されます。

想定される挙動

• 式はワークフローデータにのみ作用する
• OSリソースへアクセスできない
• Node.js内部やグローバルオブジェクトへアクセスできない
• 出力は安全にワークフロー実行へ返される

実際の挙動（脆弱）

• 式が適切にサンドボックス化されていないコンテキストで実行される
• ユーザー制御のJavaScriptがワークフローデータの範囲を超えてアクセスする
• Node.jsランタイムオブジェクトや内部APIに到達可能になる
• 「式」と「サーバーコード」の境界が実質的に破壊される

ステップ2：式インジェクション

式は信頼できないデータとして扱われるのではなくJavaScriptとして実行されるため、攻撃者は単純なデータ操作の代わりに悪意あるロジックを注入できます。

例（悪意ある式）

{{ require('child_process').execSync('id') }}

このペイロードは、ワークフロー実行時にNode.jsによって直接評価されます。

なぜ成立するのか

• require()が式の実行コンテキストで利用可能
• Node.jsのコアモジュールが十分に制限されていない
• 式エンジンが厳格なサンドボックスを強制していない
• ユーザー提供の式がn8nサービスと同じ権限で実行される

その結果、攻撃者が制御する入力が信頼されたサーバー側コードとして実行されます。

ステップ3：コード実行（内部的な分解）

1. モジュール読み込み

require('child_process')

• require()がNode.js組み込みのchild_processモジュールを読み込む
• このモジュールはOSレベルのプロセスを生成・制御するためのもの
• このモジュールへのアクセスは、信頼できない入力に決して露出してはならない

2. コマンド実行

execSync('id')

• ホストOS上でidコマンドを実行する
• n8nサービスを実行しているOSユーザー権限で動作する
• 完了までブロックする同期実行
• コマンド出力をJavaScriptへ返し、さらにワークフローへ返す

出力例

uid=1000(n8n) gid=1000(n8n) groups=1000(n8n)

この出力は次を確認できます：

• コマンドがサーバー上で実行されている
• 攻撃者がコマンド実行を制御している
• n8nプロセスの権限レベルが露出している

n8n式RCEの攻撃フロー

ステップ1：アクセス

「認証済みユーザーがワークフローを作成または編集」

これは何を意味するか：

• 攻撃者は管理者権限やシステムアクセスを必要としない
• ワークフローを作成または編集できる任意のユーザーで十分
• これには次が含まれる：
  • 低権限ユーザー
  • 共有n8nインスタンス
  • 侵害されたユーザーアカウント
  • 設定不備のデプロイで露出したエディタ

なぜ重要か：

• ワークフロー編集は正当な機能と見なされる
• この段階ではまだエクスプロイトは発動しない—純粋に通常利用の範囲

ステップ2：注入

「攻撃者が特別に細工した悪意ある式をワークフローに挿入」

ここで起きること：

• 攻撃者が{{ }}内にJavaScript式を挿入する
• 通常のデータ処理ではなく、実行可能なロジックを含む

ペイロード例：

{{ require('child_process').execSync('id') }}

重要ポイント：

• n8nはこれを有効な式入力として扱う
• 検証やサンドボックス強制がそれをブロックしない
• ペイロードはワークフローの一部として保存される

ステップ3：逸脱

「式が意図されたサンドボックス環境を逸脱」

これが中核となる脆弱性です。

本来起きるべきこと：

• 式はワークフローデータにのみアクセスできるべき
• Node.js内部やシステムAPIへアクセスできるべきではない

実際に起きること：

• 式が安全でないコンテキストで実行される
• 次へのアクセスが可能：
  • require()
  • Node.jsコアモジュール
  • グローバルランタイムオブジェクト
• JavaScriptが意図されたサンドボックス境界を突破する

技術的理由：

• 式実行環境の分離が不十分
• モジュール読み込みとランタイムアクセスに対する制限が欠落

ステップ4：実行

「n8nプロセス権限での任意コード実行」

最終結果：

• 攻撃者がサーバー上でOSコマンドを実行する
• コマンドはn8nと同じOSユーザーとして実行される

結果例：

uid=1000    (n8n) gid=1000(n8n)

影響：

• ファイルの読み書き
• シークレットや認証情報へのアクセス
• 追加ペイロードの実行
• サーバーの完全侵害の可能性

再現手順

ステップ1 – n8nに認証する

有効なアカウントでn8nのWebインターフェースにログインします。

必要な権限：

• ワークフローを作成または編集できること
• 管理者権限は不要

これは、本脆弱性が低権限の認証済みユーザーによって悪用可能であることを示し、共有環境やマルチテナント環境でのリスクを大幅に高めます。

ステップ2 – 新しいワークフローを作成する

ログイン後：

1. 「Add workflow」をクリック
2. 求められた場合は「Start from scratch」を選択

これにより、ノードを追加できる空のワークフローが作成されます。
特別な設定や既存ワークフローは不要です。エクスプロイトはデフォルトのワークフロー構成で動作します。

ステップ3 – 最初のノードを追加する

1. 「Add first step」をクリック
2. Manual Triggerを検索
3. Manual Triggerを選択

Manual Triggerはオンデマンドでワークフローを実行できます。
エクスプロイトはインポートやデプロイ時ではなく、通常のワークフロー実行中に発動します。

ステップ4- データ処理ノードを追加する

1. Manual Triggerの後にある➕アイコンをクリック
2. Edit Fields (Set)を検索
3. Setノードを追加
4. Manual Triggerに接続されていることを確認

Setノードは式をサポートしており、これらはサーバー側で評価されるため、本脆弱性の攻撃面となります。

ステップ5 – Setノードを設定する

1. Setノードを開く
2. 「Add Field」をクリック
3. Stringを選択
4. フィールド名を次に設定：
5. result
6. 「=」アイコンをクリックしてExpression Modeを有効化

Expression Modeは、値を静的データではなくJavaScriptコードとして扱うようn8nに指示します。

ステップ6- 悪意ある式を注入する

{{ (function(){ return this.process.mainModule.require('child_process').execSync('cat /etc/pass').toString() })() }}

上記のペイロードは、n8nワークフローノード内の式の値フィールドに注入されます。
ワークフローが実行されると、n8nはJavaScript式エンジンを用いてこの式をサーバー側で評価します。

データとして扱われるのではなくコードとして実行されるため、攻撃者は意図されたサンドボックスを逸脱し、基盤OS上で任意のコマンドを実行できます。

式はワークフロー実行中にn8nの式エンジンによって評価されます。

なぜ成立するのか：

• 式はNode.jsを用いて評価される
• 実行コンテキストが適切にサンドボックス化されていない
• JavaScriptのthisコンテキストがNode.jsのグローバルオブジェクトに解決される
• 内部ランタイムAPIにアクセス可能になる

ステップ7 – ワークフローを実行する

1. 「Execute step」をクリック
2. Setノードが生成する出力を確認

出力には、基盤OS上で実行されたコマンドの結果が含まれます。

これが悪用を確認できる理由：

• コマンドがサーバー上で実行される
• 出力がワークフローへ直接返される
• 実行はn8nプロセスと同じ権限で行われる

Nucleiを用いてCVE-2025-68613を特定した方法

次のNucleiテンプレートを使用しました：

テンプレート
CVE-2025-68613.yaml
https://github.com/Ashwesker/Blackash-CVE-2025-68613/blob/main/CVE-2025-68613.yaml

テンプレートは次の方法で動作します：

• 安全なテスト式を注入する細工済みリクエストを送信する
• n8nの式エンジンにサーバー側コードを評価させる
• 式実行の兆候となる指標をレスポンスで確認する

スキャンの実行

ターゲットはn8nのURLを含むファイルで指定しました：

nuclei -t CVE-2025-68613.yaml -l targets.txt

現実世界での影響

CVE 2025 68613の悪用は、n8n内の信頼境界を完全に失わせ、攻撃者が自動化プラットフォームそのものと同等の権限で活動できるようにします。n8nは内部システム、クラウドサービス、サードパーティAPIを接続する中央のオーケストレーション層として機能することが多いため、侵害の影響は組織全体へ連鎖的に波及しがちです。

この脆弱性は、機密性・完全性・可用性（CIA）トライアドの3本柱すべてを直接損ない、いずれもHIGHの深刻度となります。

機密性

この脆弱性の悪用に成功した攻撃者は、n8nワークフローで処理・保存されるデータを無制限に可視化でき、次を含みます：

• APIキー、OAuthトークン、DB認証情報、サービスシークレット
• 暗号鍵や内部アクセストークンを含む環境変数
• ワークフロー実行ログおよび過去の実行データ
• 自動化パイプラインを通過する機微な業務／顧客／従業員／患者データ

完全性

データ露出にとどまらず、攻撃者は自動化ロジック自体を操作し、業務プロセスの挙動を密かに変更できます：

• 正当なワークフローを改変して運用を妨害する
• 悪意ある式を注入してデータを破損または改ざんする
• 下流システムへ渡るワークフロー出力を操作する
• ワークフロー内に埋め込まれた永続的バックドアを展開する

可用性

任意コード実行により、攻撃者は自動化サービスを意図的に妨害または停止できます：

• ミッションクリティカルなワークフローの削除または無効化
• システムファイルの改変によるアプリケーション不安定化やクラッシュ
• 悪意ある自動化ループによるリソース枯渇
• 運用復旧のための支払いを要求する身代金型攻撃
• 保護対象保健情報（PHI）への不正アクセス
• 医療記録の改ざん、または重要アラートの抑止
• 自動化された医療プロセスの妨害

n8nの予防策とセキュリティベストプラクティス

1. n8nを最新に保つ

• 利用可能であれば自動アップデートを有効化する。
• 脆弱性情報を把握するためにn8nのセキュリティアドバイザリを購読する。
• 本番適用前にステージング環境でパッチをテストする。

主要な是正策 – パッチ適用済みバージョンへアップグレード：

CVE-2025-68613に完全に対処するには、パッチ適用済みバージョンへのアップグレードが不可欠です。n8n開発者は、式が意図されたコンテキストから逸脱することを防ぐための保護策を導入しました。次のいずれかのバージョンへ直ちにアップグレードしてください：

• 1.120.4
• 1.121.1
• 1.122.0以降

これらのバージョンには重要なセキュリティ強化が含まれます。すべてのn8nデプロイに遅滞なくアップグレードを適用してください。

2. アクセス制御

• ワークフロー作成・編集を制限： ワークフローの作成・変更は、完全に信頼できる少数のユーザーグループに限定してください。権限の定期監査を実施します。
• 最小権限の原則を適用： ユーザー、ワークフロー、プロセスが役割に必要なアクセスのみを持つようにします。
• 強固な認証： 強力なパスワードと2FAを必須化し、企業向けデプロイではSSOを実装します。
• 定期的なアクセスレビュー： 異常を検知するため、ユーザーアクセスと権限を定期的に見直します。

3. 一時的な緩和策（すぐにアップグレードできない場合）

これらの対策はリスクを低減しますが、脆弱性を解消するものではありません。アップグレード適用までの短期的措置としてのみ検討してください。

環境の強化：

• n8nは最小限のOS権限で実行し、rootや特権アカウントを避ける。
• 外向きネットワーク接続を必要最小限に制限する。
• n8nインターフェースへの内向きアクセスを信頼できるIPに限定する、またはVPN経由にする。
• 追加の分離のため、最小限のOSインストールでコンテナ（Docker）または仮想マシン（VM）にn8nをデプロイする。

4. ワークフロー管理

• 不審なロジックや予期しない式がないかワークフローをレビューする。
• カスタム式を含むワークフローに対してコードレビュー手順を実装する。
• 重要なワークフローを識別するために命名規則を使用する。
• データ損失や改ざんを防ぐためにワークフローを定期的にバックアップする。

5. 認証情報管理

• 認証情報をワークフローに直接保存しない。
• 機微データには環境変数を使用する。
• 露出を抑えるために認証情報を定期的にローテーションする。
• n8nで使用されるすべての認証情報へのアクセスを監査する。

6. 監視とログ

• ワークフロー、式、管理操作について包括的な監査ログを有効化する。
• 異常な活動やアクセス失敗を監視する。
• 不審な操作に対するアラートを設定する。
• ログを定期的にレビュー・分析し、侵害の可能性を検知する。

7. ネットワークセキュリティ

• n8nを分離されたネットワークセグメントに配置する。
• ネットワークアクセスを必要なサービスのみに制限する。
• リモートアクセスにはVPNまたはファイアウォール保護を使用する。
• ネットワークトラフィックを監視し、異常や不正接続を検知する。

8. インシデント対応

• 文書化されたインシデント対応計画を維持する。
• セキュリティイベントのエスカレーション手順を定義する。
• 定期的にセキュリティ訓練を実施する。
• 関係者および対応チームの連絡先リストを最新に保つ。

結論

CVE 2025 68613は、n8nの式評価エンジンにおける重大な脆弱性であり、認証済みユーザーが—最小限の権限であっても—サーバー上で任意のコードを実行できてしまいます。これは意図されたサンドボックス化を回避し、Node.jsランタイム、ワークフロー、基盤システムを完全侵害にさらします。

本脆弱性は機密性・完全性・可用性に深刻な影響を与えます。機微データの流出、ワークフローの改変や破損、重要な自動化プロセスの停止が起こり得ます。現実世界での影響は、規制違反や金銭的損失から、評判の失墜、複数業界にわたる業務停止にまで及びます。

決定的な是正策は、パッチ適用済みバージョン1.120.4、1.121.1、または1.122.0以降への即時アップグレードです。ワークフロー作成の制限や最小権限の徹底といった一時的な緩和策は露出を低減できますが、リスクを解消するものではありません。