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）の危険性と修正バージョン情報
✅ 今すぐできる暫定対策・アップグレード手順・長期的なセキュリティ強化策
今日のセールをまとめてチェック！
本日のセール・タイムセールをまとめてチェックできます。
Amazon
＼ポイント最大47倍！／
楽天市場
Yahooショッピング
メルカリ

n8n CVSS9.9の深刻な脆弱性、その全貌

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

n8n 9.9とは：CVSSスコア9.9の脆弱性CVE-2025-68613の正体

【AI】【業務効率化】【職場】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アプリがこれほど危険な理由はここにある

【AI】【業務効率化】【職場】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まで

【AI】【業務効率化】【職場】影響を受けるバージョンは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プロセスへの到達を防ぎます。

現在使用中のバージョンが脆弱なバージョン範囲に含まれている場合は、後述するアップグレード手順を参照してください。パッチ適用が即座に難しい場合でも、暫定対策を講じることが強く推奨されています。

攻撃者がたった数行のコードで実行できること

【AI】【業務効率化】【職場】攻撃者がたった数行のコードで実行できること

この脆弱性の「怖いところ」は、攻撃の難易度が低いという点です。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台以上が危険にさらされたグローバルな被害規模

【AI】【業務効率化】【職場】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のインストール方法と安全な最新バージョンへの更新手順

【AI】【業務効率化】【職場】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以降）への早急なアップグレードを強く推奨しています。まだ更新が完了していない方は、次のセクションで紹介する暫定対策と組み合わせて、できるだけ早く対処することが重要です。

【AI】【業務効率化】【職場】n8nのインストール方法と安全な最新バージョンへの更新手順
忘れる前に！【ふるさと納税】今年もお得に！
ふるさと納税のポイント付与は2025年10月に廃止になりました。
Amazon
＼ポイント最大47倍！／
楽天市場
Yahooショッピング
メルカリ

n8n 9.9問題の対策と第2の脆弱性CVE-2025-68668の全貌

【AI】【業務効率化】【職場】n8nのインストール方法と安全な最新バージョンへの更新手順
  1. 第2の脆弱性CVE-2025-68668（N8scape）の仕組みと危険性
  2. n8nとDifyの違い：ワークフロー自動化ツールのセキュリティ比較
  3. すぐに実施すべき暫定対策と環境変数の設定方法
  4. パッチ適用済みバージョンへのアップグレード完全手順
  5. セキュリティチームが監視・検知すべき攻撃の痕跡
  6. 自動化プラットフォームのセキュリティを強化する長期的な対策
  7. 総括：n8n 9.9のまとめ

第2の脆弱性CVE-2025-68668（N8scape）の仕組みと危険性

【AI】【業務効率化】【職場】第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の違い：ワークフロー自動化ツールのセキュリティ比較

【AI】【業務効率化】【職場】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や専用セグメントに置く
監査ログ すべてのワークフロー作成・編集・実行を記録
定期的なアップデート セキュリティアドバイザリーを購読し即座に対応
アクセス制御 ワークフロー編集権限を信頼できるユーザーのみに

すぐに実施すべき暫定対策と環境変数の設定方法

【AI】【業務効率化】【職場】すぐに実施すべき暫定対策と環境変数の設定方法

すぐにバージョンアップができない場合でも、環境変数を設定することで被害リスクを大幅に下げることができます。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

パッチ適用済みバージョンへのアップグレード完全手順

【AI】【業務効率化】【職場】パッチ適用済みバージョンへのアップグレード完全手順

暫定対策はあくまで「応急処置」です。根本的な解決は脆弱性が修正されたバージョンへのアップグレードしかありません。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）が含まれる可能性があるため、本番環境への適用前にステージング環境でのテストを強く推奨します。

セキュリティチームが監視・検知すべき攻撃の痕跡

【AI】【業務効率化】【職場】セキュリティチームが監視・検知すべき攻撃の痕跡

すでに攻撃を受けていないかを確認するため、セキュリティチームは以下の点を調査することが推奨されます。パッチ適用と合わせて、インシデントレスポンスの観点からも確認しておきましょう。

🔍 ワークフロー内の不審パターン検出

# ワークフロー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を標的の一つとしており、インターネットに公開されたインスタンスは特に優先して確認すべきです。

自動化プラットフォームのセキュリティを強化する長期的な対策

【AI】【業務効率化】【職場】自動化プラットフォームのセキュリティを強化する長期的な対策

今回の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のまとめ

【AI】【業務効率化】【職場】総括：n8n 9.9のまとめ

最後に記事のポイントをまとめます。

  1. 「n8n 9.9」とはCVSSスコア9.9の最高クラスの深刻度を持つ脆弱性（CVE-2025-68613）のことを指す
  2. CVE-2025-68613はn8nのワークフロー式評価でサンドボックス分離が不十分なため、認証済みユーザーが任意コードを実行できる
  3. 影響を受けるバージョンはv0.211.0〜v1.120.3およびv1.121.0で、修正済みはv1.120.4、v1.121.1、v1.122.0
  4. 2025年12月22日時点で世界103,476台のn8nインスタンスが潜在的に脆弱と判定された
  5. 2026年3月にCISAの悪用確認済み脆弱性カタログ（KEV）に追加され、実際の攻撃も確認されている
  6. 第2の脆弱性CVE-2025-68668（N8scape、CVSS 9.9）はPythonコードノードのPyodideサンドボックス脱出を可能にし、v2.0.0で修正された
  7. 即時パッチが困難な場合は環境変数（NODES_EXCLUDE、N8N_PYTHON_ENABLED=false）による暫定対策が有効だが完全ではない
  8. n8nはワークフロー内にAPIキーやOAuthトークンを多数保持するため、侵害が組織全体の認証情報漏洩につながる危険性がある
  9. 長期的なセキュリティには「ブロックリスト方式」ではなく「プロセス分離（能力ベース分離）」が必要で、n8n v2.0.0はその方向に対応している
  10. n8nとDifyは用途が異なり、どちらを使う場合も最小権限の原則・ネットワーク分離・監査ログの設定が不可欠である
  11. 今後の自動化プラットフォームは「インフラ全体への権限を持つ実行エンジン」として設計されるべきであり、セキュリティ要件も従来のアプリとは異なる水準で管理する必要がある
  12. セキュリティチームはワークフロー内のthis.process、child_processなどのパターンと、n8nプロセスからの不審なネットワーク接続・子プロセス起動を継続的に監視すべきである

関連記事

✓replitのlanguages対応は？使える言語とAgent活用
✓genspark トークンの意味が一気に見えてくる話｜料金・クレジット・使い方のモヤモヤを整理
✓openclawで複数エージェント運用は罠か武器か？ハマる前に読むAIチーム化ガイド
✓相模原住宅展示場跡地は今どうなってる？移転後の場所・見どころ・周辺の変化をやさしく整理
✓zapier クラウドで何ができる？AI時代の自動化を迷わず理解する完全ガイド
✓n8nにログインできない！クラウド・セルフホスト版のログイン手順からトラブル解決まで全部まとめてみた
✓manus pitchbookで何がわかる？403でも見えるManus AIの正体と使い方をまるっと整理
✓ニデック 有価証券報告書で何が起きた？意見不表明までザックリわかる整理版
✓gensparkが遅いと感じたら即チェック！重い原因と爆速化の現実的な対処法まとめ
✓n8n switch 9000って何？4分岐の壁を超える方法と今選ぶべき代替案
記事作成にあたり参考にさせて頂いたサイト

各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
引用や参照の方法に不備、あるいはご不快に感じられる点がございましたら、お問い合わせフォームよりご連絡ください。
今後とも、どうぞよろしくお願いいたします。

AI 業務効率化 職場
ABOUT ME
カシワギ
『エグゼクティブワーク』編集長のカシワギです。 普段はITベンチャーで執行役員の40代男です。 元コンサルタントですが、今はテクノロジー企業で日々奮闘中。 仕事では厳しい顔をしていますが、家では小学生の子供2人のやんちゃなパパ。 休日はゴルフに行ったり、妻とワインを楽しんだり。
BLOG：https://min-biz.net/
当サイトについて
当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。 情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。 迅速に対応をさせていただきます。 その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応 することができますのでそちらもご協力いただけますと大変幸いでございます。 今後とも当サイトをよろしくお願いいたします。