CVE-2025-68613：n8nにおける認証された式インジェクションRCE（CWE-913） - 影響を受けるもの、パッチ適用対象、および対処方法

CVE-2025-68613の正体

CVE-2025-68613 の影響 n8nオープンソースのワークフロー自動化プラットフォームである。脆弱性は リモートコード実行 (RCE) n8nの問題 ワークフロー表現評価システムある条件下では、以下のような表現も可能である。 認証済みユーザー ワークフロー構成中に、以下の実行コンテキストで評価することができる。 十分に孤立していない を実行することができます。攻撃者はこの動作を悪用して、n8nプロセスの特権で任意のコードを実行し、インスタンスの完全な侵害(データアクセス、ワークフローの変更、システムレベルの操作)につながる可能性があります。(NVD)

ナショナル・ヴァルネラビリティ・データベース(NVD)のエントリーでは、NVD独自のスコアリング・エンリッチメントはまだ提供されていない。 のCNAスコアが表示されます。: CVSS v3.1 ベーススコア 9.9 (CRITICAL) ベクトル CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. (NVD)

このベクトルは、運用上重要である。この問題は、ネットワークに到達可能で、複雑性が低く、低い権限しか必要とせず、ユーザーとのやりとりがなく、スコープが変更されている。まさに、サービスが内部システムに接続されている場合、「アプリのバグ」が「環境の侵害」に変わりがちなパターンである。

弱点マッピングは CWE-913.MITREはCWE-913を、動的に管理されるコードリソース（変数、オブジェクト、クラス、属性、関数、実行可能な命令/文）に対する不適切な制御と定義しており、この問題の「式の評価が意図された分離を逃れる」という性質と一致しています。(cwe.mitre.org)

セキュリティー勧告の中に入れることができるテーブルの1つ

認証が必要」でも緊急対応が必要な理由

認証済みだから緊急性が低い」という扱いは、よくある失敗モードだ。n8nでは、認証されたユーザーは管理者だけでなく、自動化ビルダー、統合オペレーター、サービスアカウントであることが多い。いったん式の評価境界が破られると、攻撃者はアプリケーションのアクションに限定されません。-NVDは、n8nプロセスの特権による任意のコードの実行と、インスタンスの完全な侵害の可能性を明示的に指摘しています。(NVD)

実際には、ワークフロー・プラットフォームには、攻撃者が好む3つのもの、すなわち、広範な接続性、秘密、ロジックの実行が集中している。だからこそ、"ログインが必要 "という直感ではなく、CVSSベクトル（PR:L + S:C + C/I/A:H）に対応策を固定すべきなのだ。(NVD)

混乱に陥らないパッチ戦略

あなたの "正しい "最終状態はシンプルだ。NVDはこの問題を 1.120.4、1.121.1、1.122.0. (NVD)

n8n/GitHubのアドバイザリーテキストでは、以下の問題が修正されていることが強調されている。 v1.122.0 にアップグレードすることを推奨する。 1.122.0以降 というのも、「表現の評価を制限するための追加的なセーフガードを導入している」からである。(ギットハブ)

運用上、これは単純なルールだ：

安全に前進できるのであれば、そこに収束する。 1.122.0+特定のリリース列車に固定されている場合は、可能な限り早く前進を計画しながら、NVDが示す最小固定バージョンに着陸する。(NVD)

以下はその一例である。 監査専用 CI、ホスト、またはフリートジョブで実行できるバージョンチェッカー（エクスプロイトロジックはなく、バージョンとリスクフラグを立てるだけ）：

#!/usr/bin/env bash
# CVE-2025-68613 n8n バージョン監査 (悪用なし)

set -euo pipefail

if command -v n8n >/dev/null 2>&1; then
  VER="$(n8n --バージョン | tr -d 'v' | head -n1)"
さもなければ
  VER="${N8N_VERSION:-unknown}"
fi

echo "n8n バージョン検出: $VER"

# GitHub アドバイザリによる影響範囲：>=0.211.0 <1.120.4
# NVDによる修正バージョン：1.120.4, 1.121.1, 1.122.0
if [[ "$VER" != "unknown" ]] && \
   [[ "$(printf '%s￤n' "0.211.0" "$VER" | sort -V | head -n1)" == "0.211.0" ]] && ￤"0.211.0" == "0.211.0" ]] && ￤"$VER" !
   [[ "$(printf '%sxxn' "$VER" "1.120.4" | sort -V | head -n1)" == "$VER".]] && \\
   [[ "$VER" != "1.120.4" ]]; then
  echo "FLAG: CVE-2025-68613 の影響を受ける可能性があります。NVD/GitHub のガイダンスに従ってアップグレードしてください。"
  exit 2
fi

echo "このクイックチェックではフラグは出ませんでした。公式勧告とあなたの正確なデプロイの詳細と照らし合わせて検証してください。"

短期的な緩和策

NVDもGitHubの勧告も、同じ短期的な緩和策を提供している。 完全信頼ユーザーでn8nを展開する。 硬化環境 OSの権限やネットワークへのアクセスを制限することで、影響を軽減している。(NVD)

これを強制可能なものにしたいのであれば、"hardened environment "をランタイム制御に置き換えるべきである。以下は、搾取後の活用（Defense-in-Depth）を減らすための、保守的なコンテナハードニングスケッチである：

サービス
  n8n：
    image: n8nio/n8n:1.122.0
    読み込み専用: true
    tmpfs：
      - /tmp
    security_opt：
      - no-new-privileges:true。
    cap_drop：
      - ALL
    ユーザー"1000:1000"
    環境
      - N8N_LOG_LEVEL=info
    # ネットワークポリシー/ファイアウォールとペアリングする：
    #はデフォルトでegressを拒否し、必要な宛先のみ許可する。

検知と脅威ハンティング：脆弱なシグネチャを超える振る舞い

トリガーとなるメカニズムは、「ワークフロー設定中の式が、十分に分離されたコンテキストで評価される」ことであるため、以下のような有用な検出を構築することができる。 誰がワークフローを編集しているのか, 何度そして ランタイムがその後に行うこと. (NVD)

実施方法の違いに耐える実用的なアプローチは、相関させることである：

低権限ユーザー（またはサービスアカウント）による異常なワークフロー編集＋不審なプロセス実行／n8nランタイムからのアウトバウンド接続。これは、悪用に成功すると n8n プロセス権限でシステムレベルの操作が実行される可能性があるという NVD の声明と一致しています。(NVD)

オーディット・アイディアの例（環境に合わせる）：

-a 常に終了 -F arch=b64 -S execve -F comm=node -k n8n_exec
-a 常に終了 -F arch=b64 -S connect -F comm=node -k n8n_net

隣接する影響度の高いn8n CVEを確認する必要がある。

もしあなたの組織がn8nに依存しているなら、CVE-2025-68613を一過性のものとして扱うべきではありません。隣接する2つの例は、ワークフロープラットフォームで繰り返されるテーマである、コンフィギュレーションと実行の境界を曖昧にする機能を示している。

CVE-2025-65964 は、Gitノードに関わる別のn8n問題です：NVDによると、バージョン0.123.1から1.119.1までは、GitフックによるRCEを防ぐための適切な保護が欠けており、ワークフローのアクションがGitの設定（例えばcore.hooksPath）に影響を与え、フックの実行を引き起こす可能性があるとのことです。 1.119.2. (NVD)

CVE-2025-57749 の前のn8nのRead/Write Fileノードにシンボリックリンク・トラバーサルの脆弱性がある。 1.106.0シンボリックリンクによってディレクトリの制限が回避され、制限されたパスへのアクセスが可能になる。(NVD)

これらは異なるバグですが、同じ教訓です。ワークフローエンジンは「コードとシステムの能力」に危険なほど接近しているため、分離、ノードレベルのガードレール、厳格な権限境界はオプションではありません。MITREのCWE-913の定義は、動的なコード・リソースが予期せぬ影響を受ける可能性がある場合に、なぜこれらの問題が再発するのかを捉えています。(cwe.mitre.org)

エンジニアによるクローズドループ（資産の発見、バージョンの検証、パッチの検証、証拠となるようなレポート作成）が目標であれば、Penligent のような AI を活用したセキュリティワークフロープラットフォームは、「修正とリグレッションの検証」フェーズに自然に適合する。本番環境のリスクを即座に低減することだけを目的とするのであれば、「修正済みのバージョンにアップグレードし、ベンダーの短期的な緩和策を適用する」という、最も活用度の高いアクションが残る。(NVD)

https://nvd.nist.gov/vuln/detail/CVE-2025-68613
https://github.com/n8n-io/n8n/security/advisories/GHSA-v98v-ff95-f3cp
https://cwe.mitre.org/data/definitions/913.html
https://docs.n8n.io/release-notes/
https://nvd.nist.gov/vuln/detail/CVE-2025-65964
https://github.com/n8n-io/n8n/security/advisories/GHSA-wpqc-h9wp-chmq
https://nvd.nist.gov/vuln/detail/CVE-2025-57749