n8n式評価の隔離不備で認証ユーザーRCE、10万超が露出—パッチ適用と権限再設計が急務です

今日の深掘りポイント

• 自動化基盤n8nに、認証済みユーザーが式評価の隔離不備を突いて任意コード実行できる脆弱性（CVE-2025-68613）が公開です。プロセス権限でのRCEのため、ワークフロー資産と接続先SaaS/クラウドへの横展開が現実的です。
• 修正は1.120.4、1.121.1、1.122.0で提供とされ、影響範囲については「全バージョン影響」と「0.211.0以上1.120.4未満影響」の両表現が流通しています。運用系統ごとの修正ラインという解釈が成り立つ可能性があり、ベンダーアドバイザリの一次確認が必須です。
• インターネット上に最大103,476の潜在的に脆弱なインスタンスが露出との報道があり、米独仏伯シンガポールに集中です。自社の露出確認と72時間以内の対処を標準とするのが現実的です。
• 「認証が必要」は有効な緩和とは限らず、SSO・APIトークン・共有アカウント・外部委託先アカウントなどのライフサイクル管理が甘いと初動突破は容易です。
• パッチ適用に加え、ワークフローの作成・編集権限を最小化し、資格情報ストアの即時ローテーション、n8n実行環境の権限縮小・ネットワーク分離・監査ログ強化を同時に走らせるべきです。
• 指標全体からは「緊急性と実務対応可能性が高い一方、新規性は中程度」という読みが立ちます。既知パターン（式評価/サンドボックス不備→RCE）の再来であり、横展開阻止の設計力が問われます。

はじめに

自動化基盤は、もはや“業務の制御プレーン”です。n8nのようなワークフロー自動化は、内部システムとSaaS・クラウドを接着し、認証情報や運用キーを大量に保有します。この層で認証済みユーザーがRCEに到達できる欠陥が露呈すると、単体ホストの侵害に留まらず、接続先の広範な資産へ横展開しやすいのが最大の難点です。
今回のCVE-2025-68613は、式評価コンテキストの隔離不備に起因する典型的なRCEで、CVSS 9.9相当の重大性が付与されています。報道ベースでも10万超の公開インスタンスが示唆されており、攻撃者の探索面から見れば魅力的な標的集合です。日本企業の現場では、n8nがDevOps・データ連携・カスタマーオペレーションのハブとして活用され、権限と接続先が濃密に集積しているケースが多く、早期の是正が必要です。

深掘り詳細

事実整理（報道・公開情報ベース）

• 脆弱性の正体
  認証済みユーザーが提供する式が、十分に隔離されないコンテキストで評価されることにより、n8nプロセス権限で任意コード実行に至る欠陥です。識別子はCVE-2025-68613です。
• 影響範囲と修正
  影響範囲については「すべてのバージョンに影響」との記述と、「0.211.0以上1.120.4未満に影響」との記述が並存しています。修正は1.120.4、1.121.1、1.122.0各系で提供されたと報じられています。運用中のブランチ別に緊急修正リリースが切られた可能性があり、使用中のメジャー/マイナー系統に対応する修正バージョンの一次情報確認が不可欠です。
• 露出状況
  2025年12月22日時点で103,476の潜在的に脆弱なインスタンスが観測されたとの報道があり、米国・ドイツ・フランス・ブラジル・シンガポールに分布が集中しています。露出の多さはスキャン容易性と初動侵入の現実性を押し上げます。
• 公開観測
  現時点で大規模な悪用事例は限定的とされますが、RCEの性質上、概念実証や攻撃自動化の普及次第で局面が一変し得ます。

出典: The Hacker Newsの報道

インサイト（運用現場への示唆）

• 「認証が必要」でも危険な理由
  自動化基盤の“認証ユーザー”には、人だけでなくサービスアカウントや外部委託先のアイデンティティが含まれがちです。SSO連携・APIトークン・共有アカウント・役割の過大付与など、認証周りの衛生管理が少しでも崩れると、攻撃者は「低権限でログイン→式注入でRCE」という最短経路を取り得ます。認証前提の欠陥軽視は禁物です。
• Blast radiusの読み替え
  n8n自体のプロセス権限でRCEが可能ということは、n8nに保存された資格情報・接続先SaaS・クラウドのAPI経由で、機密データ抽出や設定改ざん・CI/CD連携の悪用などが連鎖し得ることを意味します。特に、単一インスタンスに複数部門・複数業務のワークフローが同居している場合、被害面積が指数的に広がります。
• 指標からの読み
  メトリクス全体像は、緊急性と対応可能性の高さ、そして起点が“式評価サンドボックス不備”という既知パターンであることを示唆します。新奇性が突出していない分、攻撃者側の自動化も速く、脆弱な露出母集団が大きい現状では、初動対応の速さが被害有無を分けます。
• アーキテクチャの原則
  自動化基盤は“便利な共用サーバ”ではなく“高価値の制御プレーン”として扱うべきです。権限（編集/実行/資格情報管理/接続先登録）の細分化、環境分離（部門・機密区分ごと）、実行ユーザーの非特権化、ネットワークの外向き最小化が、恒久対策の柱になります。

脅威シナリオと影響

以下は仮説に基づくシナリオで、MITRE ATT&CKに沿って整理します。実環境での適用はログ・設定と突き合わせて検証することを推奨します。

• シナリオ1：低権限アカウント乗っ取りからの制御プレーン奪取

  • 初期侵入: 有効アカウントの悪用（T1078）、パスワードスプレー/総当たり（T1110）、フィッシング（T1566）
  • 実行: 式評価不備を突いた任意コード実行（TA0002, T1059相当のコード実行に帰着）
  • 認証情報アクセス: 環境変数・設定からの資格情報窃取（T1552）
  • 偵察: ネットワーク/アカウント/クラウドリソース探索（T1046, T1087, T1526）
  • 横展開: 取得したクレデンシャルで内部サービスやSaaSへ接続（T1021/T1133）
  • 収集/流出: ウェブサービス経由の持ち出し（T1567.002）
  • 持続化/防御回避: ワークフローのトリガ改変、監査ログ抑止（T1053, T1562）

• シナリオ2：委託先/外部ユーザーの権限逸脱

  • 初期侵入: 正規の外部アカウント（T1078）
  • 実行: RCEでホスト上のデータ・キーにアクセス（T1059）
  • インパクト: 接続先SaaS（CRM、チケット、リポジトリ）のデータ改ざん（T1565）とサービス妨害（T1489）

• シナリオ3：サプライチェーン経由のビルド/運用改ざん

  • 初期侵入: リポジトリ/CIの資格情報がn8nから回収される（T1552）
  • 横展開: CI/CDやIaCに対する改変で二次配布に悪性変更を注入（T1195の概念に近いサプライチェーン悪用）
  • 影響: 広域な顧客・内部環境への波及

影響評価の観点では、RCE自体の重大性に加え、「資格情報集約点の侵害」「多系統SaaS/クラウドへの連鎖」「編集権限と実行権限の境界崩壊」の三点が、組織の事業継続・信頼性に直撃します。短期はパッチと露出遮断、長期は権限設計と分離の見直しが鍵です。

セキュリティ担当者のアクション

優先度順に、現実的な運用手順を示します。

1. 直ちにパッチ適用と露出遮断

• 稼働系のバージョンと系統を棚卸しし、1.120.4/1.121.1/1.122.0の各修正リリースに更新します。複数ブランチが混在する場合は全系統を網羅します。
• 一時的にインターネット直結を遮断（VPN/ゼロトラスト下へ格納、WAF/リバースプロキシ背後に限定）。外部登録・自己サインアップを無効化します。

2. 権限モデルの再設計（編集≠実行を徹底）

• ワークフローの「作成/編集」と「実行」の権限を厳格に分離し、編集権限は最小人数へ。サービスアカウントは用途ごとに分割し、共有を禁止します。
• SSO強制とMFA必須化、ロールの最小化、外部委託先アカウントの有効期限・監査を即時実装します。

3. 資格情報と接続先の防御強化

• n8nに保存済みの資格情報（APIキー、OAuthトークン、クラウドIAMキー）を優先度順にローテーションします。まず高権限・広範囲アクセスのものから着手します。
• 接続先SaaS/クラウド側でスコープ最小化・IP許可リスト化・条件付きアクセスを導入し、n8nからのアクセス経路を限定します。

4. 実行環境のハードニング

• コンテナ/ホストの実行ユーザーを非特権化し、不要なケイパビリティを削除、ルートFSの読み取り専用化、不要なボリューム/ソケット（例: Dockerソケット）をマウントしない方針にします。
• egressフィルタで外向き通信を必要先に限定、内部向けもセグメンテーションします。

5. 検知・監査とフォレンジック前提の運用

• 監査ログで「ワークフロー編集・資格情報参照・ユーザー/ロール変更」のイベントを可視化し、異常時に即アラート。n8nプロセス起点の子プロセス生成や異常な外部接続をEDR/NDRで監視します。
• 直近2週間の変更履歴をレビューし、不審な式や見慣れないユーザーの編集痕跡がないかを確認します。痕跡があれば資格情報の追加ローテーションと接続先側のセッション無効化まで含めて対応します。

6. 長期対応（構造的リスク低減）

• 機密区分/部門ごとにn8nインスタンスを分離し、共用を避けます。重要フローはコードレビュー相当のチェンジ管理を適用します。
• 資産管理とASM（Attack Surface Management）にn8nを登録し、露出・バージョンの継続監視を仕組み化します。

参考情報

• 報道: Critical n8n flaw (CVSS 9.9) enables authenticated RCE across thousands of instances – The Hacker News

注記:

• 本稿は提示された公開情報を基に構成しています。影響バージョン表記に揺れがあるため、読者各位の環境で利用中のブランチに対応するベンダー一次情報の確認と、最短での修正適用を強く推奨します。
• 攻撃手法の詳細や再現手順には触れていません。検証はクローズド環境で、かつベンダーのガイダンスに従って実施してください。