n8nのCVSS9.9脆弱性がヤバすぎる!10万台以上が危険にさらされた衝撃の実態を徹底解説
2025年末から2026年初頭にかけて、ワークフロー自動化ツール「n8n」に史上最高クラスの深刻度を持つ脆弱性が立て続けに発見されて大きな話題となりました。「n8n 9.9」という検索ワードでたどり着いた方は、おそらく「自分の環境は大丈夫なのか」「どれだけ危険なのか」を知りたいはずです。この記事では、CVSSスコア9.9という最高クラスの危険度が付けられた2つの脆弱性(CVE-2025-68613とCVE-2025-68668)について、仕組みから対策まで徹底的に調べてまとめました。
n8nは世界中で57,000件以上の週次ダウンロードがあり、APIやSaaSをつなぐ自動化の要として多くの企業で使われているツールです。それだけに、この脆弱性が放置されれば「認証済みユーザーが数行のコードでサーバー全体を乗っ取れる」という事態に直結します。2026年3月にはCISA(米国サイバーセキュリティ・インフラセキュリティ庁)の「悪用が確認された脆弱性カタログ」にも追加されており、もはや他人事では済まない状況です。
| この記事のポイント |
|---|
| ✅ n8n 9.9(CVSS9.9)とはどんな脆弱性なのかを基礎からわかりやすく解説 |
| ✅ 世界10万台以上が影響を受けた被害規模と攻撃の具体的な仕組み |
| ✅ 第2の脆弱性CVE-2025-68668(N8scape)の危険性と修正バージョン情報 |
| ✅ 今すぐできる暫定対策・アップグレード手順・長期的なセキュリティ強化策 |
n8n CVSS9.9の深刻な脆弱性、その全貌

- n8n 9.9とは:CVSSスコア9.9の脆弱性CVE-2025-68613の正体
- n8nアプリがこれほど危険な理由はここにある
- 影響を受けるバージョンは0.211.0から1.120.3まで
- 攻撃者がたった数行のコードで実行できること
- 103,000台以上が危険にさらされたグローバルな被害規模
- n8nのインストール方法と安全な最新バージョンへの更新手順
n8n 9.9とは:CVSSスコア9.9の脆弱性CVE-2025-68613の正体

「n8n 9.9」 とは、2025年12月19日に公開されたオープンソースのワークフロー自動化プラットフォーム「n8n」の重大な脆弱性、CVE-2025-68613 に付けられたCVSSスコア(9.9/10.0)のことです。CVSSとは「Common Vulnerability Scoring System(共通脆弱性評価システム)」の略で、脆弱性の深刻度を0〜10の数値で表します。10に近いほど危険度が高く、9.9はほぼ最大値という非常に深刻なレベルです。
この脆弱性の本質は、n8nのワークフロー式評価システムにおける「不十分なサンドボックス分離」 にあります。n8nでは {{ }} で囲まれたJavaScript式がサーバーサイドで評価される仕組みになっていますが、その実行コンテキストが適切に分離されておらず、攻撃者が意図的に細工した式を通じて基盤となるNode.jsランタイムにアクセスできてしまいます。
「特定の条件下で、ワークフロー設定中に認証済みユーザーから提供された式が、基盤となるランタイムから十分に分離されていない実行コンテキストで評価される可能性があります。認証済みの攻撃者はこの動作を悪用して、n8nプロセスの権限で任意のコードを実行できます。」
— n8n公式セキュリティアドバイザリー(NVD CVE-2025-68613)
参照: https://nvd.nist.gov/vuln/detail/CVE-2025-68613
セキュリティ研究者のFatih Çelik氏によって発見・報告されたこの欠陥は、2025年12月23日にThe Hacker Newsでも取り上げられ、サイバーセキュリティコミュニティに衝撃を与えました。
🔑 CVE-2025-68613の基本プロファイル
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2025-68613 |
| CVSSスコア | 9.9(CRITICAL) |
| 発見者 | Fatih Çelik |
| 公開日 | 2025年12月19日 |
| 脆弱性の種類 | リモートコード実行(RCE) |
| CWE分類 | CWE-913(動的管理コードリソースの不適切な制御) |
| 攻撃ベクター | ネットワーク経由 |
| 必要な権限 | 低権限(認証済みユーザー) |
| ユーザー操作 | 不要 |
特に注目すべきは「必要な権限が低権限のみ」という点です。ターゲットのn8nインスタンスにログインできる最低限のアカウントさえあれば、管理者権限がなくても攻撃が成立してしまいます。これがスコア9.9という高い評価につながっています。
n8nアプリがこれほど危険な理由はここにある

n8nというアプリがなぜここまで危険視されるのか。それは、n8nが単なるツールではなく「組織の自動化コントロールプレーン」として機能しているからです。n8nのパブリックワークフローギャラリーには7,600以上の公開ワークフローが存在し、SalesforceやSlack、PostgreSQL、各種クラウドサービスとの連携が当たり前のように行われています。
具体的には、n8nは次のような重要なシステムと接続されることが多いです。CRMシステム(Salesforce、HubSpotなど)、データベース(PostgreSQL、MySQL)、内部通信ツール(Slack、Teams)、クラウドインフラ(AWS、GCP、Azure)、そしてそれらへのAPIキーやOAuthトークン、データベースパスワードといった認証情報そのものです。
🏗️ n8nが持つ組織内の権限範囲
| 接続先システム | n8nが保有する情報 |
|---|---|
| CRM(Salesforce等) | APIキー、OAuth2トークン |
| データベース | 接続文字列、DBパスワード |
| クラウドサービス | IAMキー、シークレット |
| 社内コミュニケーション | Bot Token、Webhook URL |
| CI/CDパイプライン | デプロイキー、環境変数 |
つまり、n8nが侵害されると「一点突破で組織全体の鍵を手に入れられる」状況になるわけです。Cyera Research Labsの研究者であるVladimir TokarevとOfek Itachが指摘しているように、「n8nのコンプロマイズは単一サーバーの問題ではなく、組織の自動化コントロールプレーン全体の崩壊を意味する」のです。
さらに悪いことに、n8nはAIエージェントフレームワークの実行レイヤーとしても使われるケースが増えています。AIが自律的に判断してアクションを実行する環境では、n8nへの不正アクセスがAI駆動の全自動攻撃につながる恐れもあります。
「ワークフローエンジンはこれらのアクションの実行レイヤーとして頻繁に使用されており、自然言語による決定を実際のインフラ変更に変換します。だからこそ、コード実行機能のサンドボックスミスが不釣り合いに高いインパクトを持つのです。」
参照: https://www.cyera.com/research/n8scape-pyodide-sandbox-escape-9-9-critical-post-auth-rce-in-n8n-cve-2025-68668
影響を受けるバージョンは0.211.0から1.120.3まで

CVE-2025-68613の影響を受けるバージョン範囲は非常に広く、n8n v0.211.0以上かつv1.120.4未満のすべてのバージョンが対象です。また、v1.121.0も脆弱であり、修正済みバージョンはv1.120.4、v1.121.1、v1.122.0の3つです。
自分のn8nバージョンを確認するには、以下の方法が使えます。
✅ バージョン確認方法
- npmでインストールした場合:
n8n --versionをターミナルで実行 - Dockerで動かしている場合:
docker exec <コンテナ名> n8n --version - n8nのWeb UIにログイン後、右下のバージョン表示を確認
🔍 脆弱性の影響バージョン一覧
| 状態 | バージョン範囲 |
|---|---|
| 🔴 脆弱(要対処) | v0.211.0 〜 v1.120.3 |
| 🔴 脆弱(要対処) | v1.121.0 |
| 🟢 修正済み | v1.120.4 |
| 🟢 修正済み | v1.121.1 |
| 🟢 修正済み | v1.122.0以降 |
注意すべきは、修正バージョンが複数のブランチにわたって提供されている点です。これは、異なるメジャーバージョンラインを使っているユーザーそれぞれにパッチが当たるよう、メンテナーが配慮した結果です。
また、GitHubでは3つの修正コミット(08f332015153、1c933358acef、39a2d1d60edd)が公開されており、技術者はパッチの内容を直接確認することもできます。パッチの骨子は「式評価の実行コンテキストを追加の安全策によって制限する」というもので、thisオブジェクトへのアクセスを遮断することでNode.jsプロセスへの到達を防ぎます。
現在使用中のバージョンが脆弱なバージョン範囲に含まれている場合は、後述するアップグレード手順を参照してください。パッチ適用が即座に難しい場合でも、暫定対策を講じることが強く推奨されています。
攻撃者がたった数行のコードで実行できること

この脆弱性の「怖いところ」は、攻撃の難易度が低いという点です。SecureLayer7のブログによれば、PoC(概念実証コード)では、{{ }}で囲まれたJavaScript式の中でNode.jsのprocessオブジェクトにアクセスし、child_processモジュールをロードしてOSコマンドを実行できることが示されています。
通常のn8n利用と攻撃的な利用の違いを簡単に説明すると:
🟢 正常な使い方の例
{{ $node["取得データ"].data["名前"] }}
→ 前のノードのデータを参照するだけの安全な式
🔴 攻撃的な使い方の例(脆弱なバージョン)
{{ (function() { var require = this.process.mainModule.require; var execSync = require('child_process').execSync; return execSync('whoami').toString(); })() }}
→ サーバー上で whoami コマンドが実行されてしまう
攻撃者が実際に行える操作の例を以下にまとめます。
⚠️ 攻撃者が実行できる操作(修正前バージョン)
| 攻撃の種類 | 具体的な被害 |
|---|---|
| 任意コマンド実行 | サーバー上でOSコマンドを自由に実行 |
| 機密ファイル読み取り | /etc/passwd、.env、設定ファイルなどへのアクセス |
| 環境変数の窃取 | APIキー、DBパスワード、クラウド認証情報の流出 |
| バックドア設置 | cronジョブや永続的な接続の確立 |
| リバースシェル | 攻撃者のサーバーへの継続的な接続確立 |
| 横断侵害 | n8nと接続された他システムへの不正アクセス |
SecureLayer7は、この脆弱性がワークフローエディタのWeb UI、REST API(/rest/workflows)、Webhookエンドポイントなど複数の経路で悪用できることを確認しています。つまり、UIにアクセスできる必要すらなく、APIキーさえあれば遠隔から自動的に攻撃を実行できてしまいます。
参照: https://blog.securelayer7.net/cve-2025-68613-n8n-rce-exploitation/
103,000台以上が危険にさらされたグローバルな被害規模

2025年12月22日時点でのアタックサーフェス管理プラットフォーム「Censys」の調査によれば、潜在的に脆弱なn8nインスタンスは世界全体で103,476台に上ることが判明しました。この数字はセキュリティコミュニティに大きなショックを与えました。
🌍 脆弱インスタンスの地域別分布(Censys調査)
| 順位 | 国 | 特徴 |
|---|---|---|
| 1位 | 🇺🇸 アメリカ | 最多の公開インスタンス |
| 2位 | 🇩🇪 ドイツ | ヨーロッパ最大 |
| 3位 | 🇫🇷 フランス | 企業利用が多数 |
| 4位 | 🇧🇷 ブラジル | 南米最大 |
| 5位 | 🇸🇬 シンガポール | アジア太平洋の拠点 |
さらに深刻なのは、2026年3月11日にCISA(米国サイバーセキュリティ・インフラセキュリティ庁)が CVE-2025-68613を「悪用が確認された脆弱性カタログ(KEV)」に追加 したことです。これは、単なる理論上のリスクではなく、実際に攻撃者がこの脆弱性を使って攻撃していることを意味します。
「n8n Improper Control of Dynamically-Managed Code Resources Vulnerability」として2026年3月11日に追加。政府機関に対しては2026年3月25日までの対処が義務付けられた。
参照: https://nvd.nist.gov/vuln/detail/CVE-2025-68613
Akamaiのセキュリティリサーチブログでは、「Zerobot」と呼ばれるマルウェアがこの脆弱性を標的にしていることも報告されています。PoC(概念実証コード)がSecureLayer7によって2025年12月22日に公開されたことで、攻撃のハードルがさらに下がり、悪用件数が急増したとみられています。
n8nのインストール方法と安全な最新バージョンへの更新手順

ここでは、n8nのインストール方法と、脆弱性から守るための安全なバージョンへの更新手順をまとめます。n8nを初めて導入する場合も、既存環境をアップデートする場合も参考にしてください。
✅ npmを使ったインストール・更新方法
# 新規インストール
npm install -g n8n
# 最新バージョンへのアップデート
npm install -g n8n@latest
# バージョン確認
n8n --version
✅ Dockerを使ったインストール・更新方法
# 最新イメージの取得
docker pull n8nio/n8n:latest
# 既存コンテナの停止と再起動
docker-compose down
docker-compose up -d
# バージョン確認
docker exec <コンテナ名> n8n --version
🔒 セキュアな初期設定のポイント
| 設定項目 | 推奨内容 |
|---|---|
| 実行ユーザー | rootではなく専用の非特権ユーザーで起動 |
| ネットワーク | インターネット直接公開を避け、VPN/リバースプロキシ経由に |
| ワークフロー編集権限 | 信頼できるユーザーのみに付与 |
| ログ監視 | 不審なプロセス起動・ネットワーク接続を監視 |
| 定期更新 | セキュリティアドバイザリーを定期チェック |
n8nは公式ドキュメントでも、修正済みバージョン(v1.120.4、v1.121.1、v1.122.0以降)への早急なアップグレードを強く推奨しています。まだ更新が完了していない方は、次のセクションで紹介する暫定対策と組み合わせて、できるだけ早く対処することが重要です。
n8n 9.9問題の対策と第2の脆弱性CVE-2025-68668の全貌

- 第2の脆弱性CVE-2025-68668(N8scape)の仕組みと危険性
- n8nとDifyの違い:ワークフロー自動化ツールのセキュリティ比較
- すぐに実施すべき暫定対策と環境変数の設定方法
- パッチ適用済みバージョンへのアップグレード完全手順
- セキュリティチームが監視・検知すべき攻撃の痕跡
- 自動化プラットフォームのセキュリティを強化する長期的な対策
- 総括:n8n 9.9のまとめ
第2の脆弱性CVE-2025-68668(N8scape)の仕組みと危険性

CVE-2025-68613の衝撃が冷めやらぬ中、2026年1月6日に第2のCVSS 9.9脆弱性が公開されました。それが CVE-2025-68668、コードネーム「N8scape」です。Cyera Research LabsのVladimir TokarevとOfek Itachによって発見されたこの脆弱性は、n8nの「Pythonコードノード」における「Pyodideサンドボックス」の設計的欠陥を突いたものです。
Pyodideとは「WebAssemblyにコンパイルされたCPython」で、n8nはこれを使ってPythonコードをブラウザ・サーバー環境で実行しています。n8nはPyodideを使う際にいくつかの危険な関数を「ブロックリスト」でふさいでいましたが、その発想自体に根本的な問題がありました。
「CVE-2025-68668は、n8nのPyodideバックエンドPython実行のセキュリティモデルの弱点です。n8nは少数の危険な関数をブロックしていますが、その根底にある機能を削除していません。」
参照: https://www.cyera.com/research/n8scape-pyodide-sandbox-escape-9-9-critical-post-auth-rce-in-n8n-cve-2025-68668
確認された2つのバイパス方法を以下に示します。
⚡ CVE-2025-68668の攻撃バイパス手法
| バイパス方法 | 仕組み |
|---|---|
| Bypass #1: ctypes経由 | os.systemはブロックされているが、Pythonの外部関数インターフェース(FFI)であるctypesは無制限。CDLL(None)でlibc.system()を直接呼び出せる |
| Bypass #2: eval_code経由 | _pyodide._base.eval_code()でコードを実行すると、n8nがパッチを当てたメインの名前空間とは異なるコンテキストで実行されるため、ブロックが効かない |
🔴 CVE-2025-68668の基本プロファイル
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2025-68668 |
| コードネーム | N8scape |
| CVSSスコア | 9.9(CRITICAL) |
| 発見者 | Cyera Research Labs(Vladimir Tokarev、Ofek Itach) |
| 公開日 | 2026年1月6日 |
| 脆弱性の種類 | Pythonサンドボックス脱出 → RCE |
| 影響バージョン | n8n v1.0.0 〜 v1.99.9 |
| 修正バージョン | v2.0.0 |
| 修正の方向性 | ブロックリスト型 → プロセス分離型(タスクランナー方式) |
この脆弱性の恐ろしい点は、攻撃成功後にユーザーからAdminへの権限昇格も可能であることです。n8nのデータベースがコンテナにマウントされているため、RCEを獲得した攻撃者はそのDBを直接書き換え、自分のアカウントを「admin/owner」に変更できます。これにより、組織内のすべてのシークレットや認証情報が一覧できる状態になります。
n8nとDifyの違い:ワークフロー自動化ツールのセキュリティ比較

n8nとDifyはどちらもオープンソースの自動化・AIワークフローツールですが、その設計思想は大きく異なります。セキュリティの観点からも違いがあるため、整理しておきましょう。
🔍 n8n vs Difyの基本比較
| 比較項目 | n8n | Dify |
|---|---|---|
| 主な用途 | ワークフロー自動化・API連携 | AIアプリ開発・LLMオーケストレーション |
| コードノード | JavaScript・Pythonを直接実行可能 | Pythonコードを限定的にサポート |
| 対象ユーザー | エンジニア・DevOps・IT自動化担当 | AIエンジニア・プロダクトマネージャー |
| セキュリティモデル | ブロックリスト方式(今回問題に) | サンドボックス設計が異なる |
| 外部連携数 | 400+のネイティブインテグレーション | LLMプロバイダー中心 |
| 自己ホスト | 容易(npm/Docker) | Docker Compose推奨 |
n8nの強みは豊富なインテグレーションと柔軟なコード実行ですが、今回の脆弱性はまさにその「コード実行の柔軟性」が仇となった形です。一方Difyは、AIモデルとのやり取りを主軸に設計されており、「任意のOSコマンドを実行できるコードノード」という構造自体が異なります。
ただし、どちらのツールも「組織内の重要サービスと接続される」という点では同じリスクをはらんでいます。自動化ツールを導入する際には、どのツールを選ぶかだけでなく、そのツールに与える権限の範囲を最小化する(最小権限の原則) という設計思想が不可欠です。
🛡️ 自動化ツール全般に共通するセキュリティのベストプラクティス
| 対策 | 内容 |
|---|---|
| 最小権限原則 | ツールが必要とする権限だけを付与 |
| ネットワーク分離 | 自動化サーバーをDMZや専用セグメントに置く |
| 監査ログ | すべてのワークフロー作成・編集・実行を記録 |
| 定期的なアップデート | セキュリティアドバイザリーを購読し即座に対応 |
| アクセス制御 | ワークフロー編集権限を信頼できるユーザーのみに |
すぐに実施すべき暫定対策と環境変数の設定方法

すぐにバージョンアップができない場合でも、環境変数を設定することで被害リスクを大幅に下げることができます。n8n公式および各セキュリティ機関が推奨する暫定対策をまとめました。
CVE-2025-68613への暫定対策
最も重要なのはワークフロー編集・作成権限を完全に信頼できるユーザーのみに限定することです。これにより、攻撃に必要な「ワークフローを作成または編集できる認証済みアカウント」の数を最小化できます。
また、n8nをOS権限が制限された隔離環境(Dockerコンテナ内でnon-rootユーザーとして実行など)でデプロイすることで、万が一RCEが成立しても被害範囲をコンテナ内に留めることができます。
CVE-2025-68668への暫定対策(環境変数設定)
🔧 環境変数による暫定緩和策
| 環境変数 | 値 | 効果 |
|---|---|---|
NODES_EXCLUDE |
["n8n-nodes-base.code"] |
コードノード全体を無効化 |
N8N_PYTHON_ENABLED |
false |
Pythonサポートのみ無効化 |
N8N_RUNNERS_ENABLED |
true |
タスクランナー型サンドボックスを有効化 |
N8N_NATIVE_PYTHON_RUNNER |
true |
より安全なPythonランナーを使用 |
docker-composeを使っている場合は、environmentセクションに上記変数を追加するだけで設定できます。ただし、コードノードを無効化すると既存ワークフローが動かなくなる場合があるため、先にどのワークフローがコードノードを使っているかを確認してから実施することを推奨します。
「これらの回避策はリスクを完全には排除できないため、短期的な措置としてのみ使用すべきです。」
— n8n公式セキュリティアドバイザリー
参照: https://nvd.nist.gov/vuln/detail/CVE-2025-68613
パッチ適用済みバージョンへのアップグレード完全手順

暫定対策はあくまで「応急処置」です。根本的な解決は脆弱性が修正されたバージョンへのアップグレードしかありません。CVE-2025-68613とCVE-2025-68668それぞれの修正バージョンをまとめると以下のようになります。
📋 2つの脆弱性と修正バージョン対応表
| 脆弱性 | 影響バージョン | 修正バージョン |
|---|---|---|
| CVE-2025-68613 | v0.211.0 〜 v1.120.3、v1.121.0 | v1.120.4、v1.121.1、v1.122.0 |
| CVE-2025-68668 | v1.0.0 〜 v1.99.9 | v2.0.0 |
最終的な推奨はv2.0.0以上へのアップグレードです。v2.0.0ではPython実行がタスクランナー方式(プロセス分離型)に変更されており、ブロックリスト方式の根本的な設計問題が解消されています。
✅ npmインストール環境のアップグレード手順
# 現在のバージョン確認
n8n --version
# 最新バージョンにアップグレード
npm install -g n8n@latest
# または特定バージョンを指定
npm install -g n8n@2.0.0
# アップグレード後のバージョン確認
n8n --version
✅ Docker環境のアップグレード手順
# 最新イメージを取得
docker pull n8nio/n8n:latest
# または特定バージョンを指定
docker pull n8nio/n8n:2.0.0
# docker-compose.ymlのimage行を更新後
docker-compose down
docker-compose up -d
# バージョン確認
docker exec $(docker ps -q -f name=n8n) n8n --version
アップグレード前には必ずデータベースのバックアップを取得してください。また、v2.0.0ではいくつかの破壊的変更(breaking changes)が含まれる可能性があるため、本番環境への適用前にステージング環境でのテストを強く推奨します。
セキュリティチームが監視・検知すべき攻撃の痕跡

すでに攻撃を受けていないかを確認するため、セキュリティチームは以下の点を調査することが推奨されます。パッチ適用と合わせて、インシデントレスポンスの観点からも確認しておきましょう。
🔍 ワークフロー内の不審パターン検出
# ワークフローJSONに怪しいコードが含まれていないか確認
grep -r "this.process" /path/to/n8n/workflows/
grep -r "mainModule.require" /path/to/n8n/workflows/
grep -r "child_process" /path/to/n8n/workflows/
grep -r "process.binding" /path/to/n8n/workflows/
⚠️ 攻撃の痕跡として疑うべき指標(IoC)
| カテゴリ | 具体的な指標 |
|---|---|
| ワークフロー内のコード | this.process、mainModule.require、child_process、evalの使用 |
| プロセスの異常 | n8nプロセスから予期しないシェルや子プロセスの起動 |
| ネットワーク | n8nプロセスからの不審な外部接続、大量のPOSTリクエスト |
| ファイルアクセス | /etc/passwd、.env、秘密鍵ファイルへのアクセス |
| データベース変更 | ユーザーロールの変更(一般ユーザー→admin) |
| 新規cronジョブ | n8n実行ユーザー名義の新しいスケジュールタスク |
また、CISAのKEVカタログへの追加(2026年3月11日)以降、実際の攻撃事例も増加していると推察されます。Akamaiのレポートで言及された「Zerobot」マルウェアはn8nを標的の一つとしており、インターネットに公開されたインスタンスは特に優先して確認すべきです。
自動化プラットフォームのセキュリティを強化する長期的な対策

今回のn8nの脆弱性は「ワークフロー自動化ツール全般が直面するセキュリティ課題」を浮き彫りにしました。n8nに限らず、自動化プラットフォームを安全に使い続けるための長期的な戦略を整理します。
🏛️ 自動化プラットフォームのセキュリティ成熟度モデル
| レベル | 内容 | 具体的な施策 |
|---|---|---|
| Lv.1 基礎 | 既知の脆弱性への対処 | 定期アップデート、パッチ管理 |
| Lv.2 予防 | 攻撃面の縮小 | 最小権限、ネットワーク分離、不要機能の無効化 |
| Lv.3 検知 | 異常の早期発見 | ログ監視、SIEM連携、ワークフロー監査 |
| Lv.4 対応 | 侵害を想定した準備 | インシデントレスポンス計画、定期的なペネトレーションテスト |
| Lv.5 改善 | 継続的な強化 | 脅威インテリジェンス活用、セキュリティトレーニング |
特に重要なのは、ブロックリスト方式のサンドボックスへの依存を避けるという考え方です。今回のN8scape(CVE-2025-68668)はまさにこの設計の限界を示しています。「危険なものを列挙して禁止する」アプローチは、攻撃者の創造性に常に遅れをとります。「そもそも危険な操作ができない環境を作る」能力ベースの分離(capability-based isolation)こそが、長期的に見た安全なアーキテクチャです。
「唯一の耐久性のある修正は、『増え続ける危険なものを拒否する』から能力ベースの分離へ移行することです。言語ランタイム内に巧妙な経路が存在したとしても、プロセスのスポーン、機密ファイルへのアクセス、シークレットへのアクセスができない環境で信頼できないコードを実行することです。」
参照: https://www.cyera.com/research/n8scape-pyodide-sandbox-escape-9-9-critical-post-auth-rce-in-n8n-cve-2025-68668
n8nはv2.0.0でタスクランナー方式(プロセス分離)を標準採用することで、この方向に舵を切りました。これは組織の自動化基盤を守るうえで重要な前進であり、v2.0.0以上へのアップグレードが推奨される大きな理由の一つです。
総括:n8n 9.9のまとめ

最後に記事のポイントをまとめます。
- 「n8n 9.9」とはCVSSスコア9.9の最高クラスの深刻度を持つ脆弱性(CVE-2025-68613)のことを指す
- CVE-2025-68613はn8nのワークフロー式評価でサンドボックス分離が不十分なため、認証済みユーザーが任意コードを実行できる
- 影響を受けるバージョンはv0.211.0〜v1.120.3およびv1.121.0で、修正済みはv1.120.4、v1.121.1、v1.122.0
- 2025年12月22日時点で世界103,476台のn8nインスタンスが潜在的に脆弱と判定された
- 2026年3月にCISAの悪用確認済み脆弱性カタログ(KEV)に追加され、実際の攻撃も確認されている
- 第2の脆弱性CVE-2025-68668(N8scape、CVSS 9.9)はPythonコードノードのPyodideサンドボックス脱出を可能にし、v2.0.0で修正された
- 即時パッチが困難な場合は環境変数(
NODES_EXCLUDE、N8N_PYTHON_ENABLED=false)による暫定対策が有効だが完全ではない - n8nはワークフロー内にAPIキーやOAuthトークンを多数保持するため、侵害が組織全体の認証情報漏洩につながる危険性がある
- 長期的なセキュリティには「ブロックリスト方式」ではなく「プロセス分離(能力ベース分離)」が必要で、n8n v2.0.0はその方向に対応している
- n8nとDifyは用途が異なり、どちらを使う場合も最小権限の原則・ネットワーク分離・監査ログの設定が不可欠である
- 今後の自動化プラットフォームは「インフラ全体への権限を持つ実行エンジン」として設計されるべきであり、セキュリティ要件も従来のアプリとは異なる水準で管理する必要がある
- セキュリティチームはワークフロー内の
this.process、child_processなどのパターンと、n8nプロセスからの不審なネットワーク接続・子プロセス起動を継続的に監視すべきである
記事作成にあたり参考にさせて頂いたサイト
- https://thehackernews.com/2025/12/critical-n8n-flaw-cvss-99-enables.html
- https://thehackernews.com/2026/01/new-n8n-vulnerability-99-cvss-lets.html
- https://nvd.nist.gov/vuln/detail/CVE-2025-68613
- https://orca.security/resources/blog/cve-2025-68613-n8n-rce-vulnerability/
- https://www.scworld.com/news/cvss-9-9-rce-vulnerability-in-n8n-potentially-impacts-more-than-100k-servers
- https://hawk-eye.io/2026/01/cve-2025-68613-how-a-9-9-cvss-flaw-exposed-103000-n8n-automation-instances/
- https://www.cyera.com/research/n8scape-pyodide-sandbox-escape-9-9-critical-post-auth-rce-in-n8n-cve-2025-68668
- https://blog.securelayer7.net/cve-2025-68613-n8n-rce-exploitation/
- https://community.n8n.io/t/disk-space-keeps-going-up/12108
- https://www.reddit.com/r/selfhosted/comments/1pu0278/critical_n8n_flaw_cvss_99_enables_arbitrary_code/
各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
引用や参照の方法に不備、あるいはご不快に感じられる点がございましたら、お問い合わせフォームよりご連絡ください。
今後とも、どうぞよろしくお願いいたします。

