2025年12月から2026年2月にかけて、オープンソースのワークフロー自動化プラットフォームn8nで、CVSS 9.4〜10.0のリモートコード実行（RCE）脆弱性が三連続で公開された。未認証RCE、Gitノード経由のフック注入、サンドボックスエスケープ──いずれも根本原因は「式評価エンジンの信頼境界設計」にある。本稿では各CVEの技術的メカニズムを解析し、ローコード/ノーコード自動化基盤が構造的に抱えるセキュリティリスクと、エンタープライズ導入における防御戦略を提示する。

わずか2ヶ月で3件のCVSS 10.0級──n8n脆弱性クラスタの全容

n8nはNode.js/TypeScriptベースのオープンソースワークフロー自動化プラットフォームであり、全世界で23万以上のインスタンスが稼働している。Zapier、Makeなどの商用SaaSと異なりセルフホスト可能な点が支持され、エンタープライズのAIパイプラインやDevOps自動化に広く採用されてきた。

しかし2025年末から2026年初頭にかけて、このプラットフォームに壊滅的な脆弱性が矢継ぎ早に発見された。カナダサイバーセキュリティセンター（CCCS）やシンガポールCSAが緊急アドバイザリを発行する事態に至っている。主要な3件のCVEを時系列で整理する。

CVECVSS種別認証要否修正バージョン公開日
CVE-2026-2185810.0未認証RCE（Content-Type混同）不要1.121.02026年1月7日
CVE-2026-2187710.0Gitフック注入RCE要1.121.32026年1月
CVE-2026-250499.4サンドボックスエスケープRCE要（※）1.123.17 / 2.5.22026年2月5日

※CVE-2026-25049は認証済みユーザーが作成した公開WebhookをトリガーとすることでPublicワークフローに対しても悪用可能であり、実質的に未認証攻撃が成立する。さらにこれらは単発の問題ではなく、2025年12月公開のCVE-2025-68613（CVSS 9.9）のパッチを迂回する形で次々と発見されており、構造的な設計課題を示唆している。

CVE-2026-21858「Ni8mare」──Content-Type混同による未認証RCE

Cyera Research Labsの研究者Dor Attiasが2025年11月9日に発見し、2026年1月7日に「Ni8mare」の名称で公開されたこの脆弱性は、CVSS 10.0（最大深刻度）を記録した。攻撃に認証が不要であり、ファイルアップロード機能を持つFormワークフローが1つでも公開されていれば悪用が成立する。

技術的なメカニズムは三段階で構成される。第一段階はContent-Type混同による任意ファイル読み取りである。n8nのparseRequestBody()ミドルウェアはHTTPリクエストのContent-Typeヘッダーのみでパーサーを決定する。攻撃者がContent-Typeをmultipart/form-dataからapplication/jsonに書き換えると、JSONボディパーサーが起動し、req.body.filesに任意のファイルパスを指定できるようになる。prepareFormReturnItem()関数はこの値を検証せずにファイルを読み取るため、/home/node/.n8n/database.sqliteや暗号化キーを含む設定ファイルが外部に漏洩する。

第二段階では、抽出したSQLiteデータベースと暗号化キーを使って管理者用JWTトークンを偽造し、認証済みアクセスを確立する。第三段階で、既知のサンドボックスエスケープ手法（CVE-2025-68613）を利用してthis.process.mainModule.require経由で任意コマンドを実行する。すでにGitHub上に複数のPoCが公開されており、攻撃の再現障壁は極めて低い。

CVE-2026-21877 & CVE-2026-25049──繰り返されるサンドボックス突破

CVE-2026-21877はn8nのGitノード統合における脆弱性である。研究者Théo Lelasseuxが発見し、2026年1月に公開された。根本原因は、Gitノードがリポジトリパスに対する危険なディレクトリ（.git/hooks）への書き込みを検証していなかった点にある。パス検証関数isFilePathBlockedは実装されていたにもかかわらず、ファイルシステムヘルパー関数から呼び出されていなかった。攻撃者は認証済みセッションからGitフックに悪意あるスクリプトを注入し、Git操作のトリガー時に任意コードを実行できた。自己ホスト環境とn8n Cloudの両方が影響を受けた。

CVE-2026-25049は、2025年12月のCVE-2025-68613（CVSS 9.9）に対するパッチを直接迂回するサンドボックスエスケープである。前回の修正は正規表現とAST（抽象構文木）解析で危険な式パターンをブロックする方式だったが、CVE-2026-25049はJavaScriptの分割代入（destructuring）構文を悪用してこれを突破する。

具体的には、静的解析が.constructorというプロパティアクセスをブロックしていたのに対し、const { constructor } = (something);という分割代入ではconstructorが独立した識別子として扱われ、ブロックリストを回避できた。さらにTypeScriptのコンパイル時型検査がランタイムでは強制されないという型混同（Type Confusion）を利用し、文字列以外のオブジェクトを式評価に注入。最終的にprocess.binding('spawn_sync')を通じてOSコマンドの実行に至る。

これらの脆弱性に加え、JFrog Security Researchが報告したCVE-2026-1470（with文によるAST解析バイパス、CVSS 9.9）、CVE-2026-0863（Python例外属性リークによるサンドボックスエスケープ、CVSS 8.5）も同時期に発見されており、n8nのサンドボックスモデル全体の信頼性が根底から揺らいでいる。

構造的要因──なぜローコード自動化基盤のサンドボックスは破られ続けるのか

n8nの脆弱性クラスタは、ローコード/ノーコード（LC/NC）自動化プラットフォーム全般に共通する構造的課題を露呈している。OWASP Low-Code/No-Code Top 10が示すように、このカテゴリの製品は「柔軟性とセキュリティのトレードオフ」を本質的に抱えている。

第一の構造的問題は、サンドボックスの信頼境界設計である。n8nの式評価エンジンはTournamentライブラリによるAST解析でJavaScript入力を無害化する仕組みだが、JavaScript言語仕様の複雑さ（分割代入、with文、Proxy、例外属性など）がバイパスベクターを無限に生み出す。2ヶ月間で同一メカニズムに対する修正が2度迂回された事実は、「ブロックリスト方式によるサンドボックス」の限界を端的に示している。

第二の問題は、中央集権的クレデンシャルストアのリスクである。n8nインスタンスはAWS、Salesforce、OpenAI、Slackなど多数のサービスのAPIキーやOAuthトークンを一元管理する。単一インスタンスの侵害が、接続された全サービスへの横展開につながる「爆発半径増幅」問題を抱えている。Dark Readingの調査では、エンタープライズの32%がLC/NCアプリのデータアクセスに対するガバナンスを持たず、25%はセキュリティチームがLC/NCアプリの作成を把握していないと回答している。

第三の問題は、セルフホストモデル固有のパッチ遅延である。Zapier/MakeなどのクラウドSaaSはベンダーが一括パッチを適用するが、n8nのセルフホストインスタンスは運用者がアップデートを実行する必要がある。Horizon3.aiの分析では、CVE-2026-21858公開時点で10万以上のインスタンスが脆弱なバージョンで稼働していたとされる。

エンタープライズ防御戦略──多層防御の実装指針

n8nの脆弱性クラスタから導出される防御戦略は、以下の4層で構成される。

即時対応層：全n8nインスタンスの棚卸しと、最新パッチ（1.123.17以上またはv2.5.2以上）への即時アップグレードが必須である。全保存クレデンシャル（APIキー、OAuthトークン）のローテーション、監査ログの確認による侵害兆候の調査を並行して実施する。

アクセス制御層：RBAC（ロールベースアクセス制御）を実装し、ワークフロー作成権限を検証済みユーザーに限定する。Function/Codeノードの使用を承認制とし、全公開Webhookに認証を強制する。不要なWebhookは即座に無効化する。

アーキテクチャ層：n8nインスタンスをネットワーク分離し、アウトバウンド通信をファイアウォールで制限する。クレデンシャル管理をHashiCorp Vaultなどの外部シークレットストアに委譲し、n8n自体にはシークレットを保持させない。コンテナ実行環境ではプロセスレベルの監視を導入し、予期しない子プロセスの生成を検知する。

ガバナンス層：ワークフローのレビュープロセスを確立し、Functionノードを含むワークフローには従来のコードレビューと同等の審査を適用する。SIEMとの統合による継続的監視と、定期的な脆弱性スキャンを運用に組み込む。LC/NC基盤を「信頼できない実行環境」として扱い、ゼロトラスト原則を適用することが、今後の自動化インフラ設計における基本方針となるべきである。

FAQ

n8nの脆弱性は自己ホスト環境とクラウド版の両方に影響するのか？

CVE-2026-21877（Gitノード経由RCE）は自己ホスト環境とn8n Cloudの両方に影響する。CVE-2026-21858とCVE-2026-25049は主に自己ホスト環境が対象だが、公開Webhookの設定次第ではクラウド版でも攻撃経路が成立する可能性がある。いずれもパッチ適用が最優先の対応となる。

n8nの代替としてZapierやMakeは安全か？

ZapierやMakeはクラウドSaaSモデルであり、ベンダーが一括でパッチを適用するためユーザー側のパッチ遅延リスクは低い。ただしクレデンシャルを第三者に預託するリスクがあり、データ主権やGDPR準拠の観点では別の考慮が必要である。セキュリティモデルの優劣ではなく、リスク特性の違いとして評価すべきである。

n8nのサンドボックスはなぜ繰り返し突破されるのか？

n8nの式評価サンドボックスはAST解析とブロックリスト方式で危険なパターンを遮断するが、JavaScript言語仕様の複雑さ（分割代入、with文、Proxy、例外属性リークなど）が多数のバイパスベクターを生む。根本的にはブロックリスト方式の限界であり、V8 Isolateやコンテナベースの隔離など、より強固な分離機構への移行が求められている。

脆弱性の影響を受けるn8nバージョンと対策は？

CVE-2026-21858は1.121.0未満、CVE-2026-21877は1.121.3未満、CVE-2026-25049は1.123.17未満（v2系は2.5.2未満）が影響を受ける。全脆弱性をカバーするには1.123.17以上またはv2.5.2以上へのアップグレードが必要である。加えて、保存済みクレデンシャルのローテーションと公開Webhookの認証設定見直しを推奨する。

参考文献