n8n「Ni8mare」脆弱性CVE-2026-21858|CVSS 10.0、認証不要のRCEで推定10万サーバーが危険

AI・自動化
スポンサーリンク

📋 セキュリティチェック指示書(クリックで展開)

.claude/commands/ に保存して /コマンド で実行

---
description: "n8n「Ni8mare」脆弱性CVE-2026-21858|CVSS 10.0、認証不要のRCEで推定10万サーバーが危険 — セキュリティチェック"
---

# n8n「Ni8mare」脆弱性CVE-2026-21858|CVSS 10.0、認証不要のRCEで推定10万サーバーが危険

この指示書は https://akahara-vlab.com/n8n-ni8mare-cve-2026-21858/ の内容に基づくセキュリティチェックリストです。

## 概要

n8nのCVSS 10.0脆弱性「Ni8mare」(CVE-2026-21858)の全容。認証不要のリモートコード実行で推定10万サーバーが影響。攻撃チェーンの詳細と即時対策(v1.121.0へのアップグレード)を解説。

## 使い方

1. このテキストを `.claude/commands/security-n8n-ni8mare-cve-2026-21858.md` に保存
2. Claude Codeで `/security-n8n-ni8mare-cve-2026-21858` と入力して実行

## チェック指示

上記の記事で解説されているセキュリティ上の注意点をもとに、現在のプロジェクトを診断してください。
問題があれば具体的な修正案を提示してください。
記事URL: https://akahara-vlab.com/n8n-ni8mare-cve-2026-21858/

※ 平文なので中身を確認してから使ってください。安全性は目視で確認できます。

わさびです。

AIワークフロー自動化ツールとして最近一気に注目が集まっているn8nに、CVSS最高スコアの脆弱性が発見された。

名前は「Ni8mare」。CVE番号はCVE-2026-21858。CVSSスコアは10.0、つまり満点だ。

スポンサーリンク

n8nとは何か

n8nは、ノーコード/ローコードでワークフローを組めるオートメーションプラットフォームだ。「Zapierのセルフホスト版」と説明するのが一番わかりやすい。

最近はLLMエージェントの構築基盤として急速に普及している。ClaudeやOpenAIのAPIと接続し、Slackへの通知、DBの読み書き、Webhookの処理を全部つなげて自動化できる。エンジニア界隈ではAIパイプラインを素早く組む手段として定番になりつつある。

セルフホスト可能なのが大きな特徴で、クラウドサービスのように外部にデータを預けたくない企業や個人がサーバーに立てて使っている。その「外部公開されたn8nサーバー」がターゲットになった。

Ni8mare脆弱性の仕組み

Cyera Research Labsが発見し、Horizon3.aiがPoC(実証コード)を公開したこの脆弱性は、3段階の攻撃チェーンで構成されている。

ステップ1:公開フォームから内部ファイルを漏洩させる

n8nには「フォームトリガー」という機能がある。外部に公開されたURLからユーザー入力を受け取り、ワークフローを起動する仕組みだ。

Ni8mareの最初のステップは、このフォームエンドポイントを使ったパストラバーサル攻撃。認証なしでアクセスできるこのエンドポイントに細工したリクエストを送ることで、サーバー内の任意ファイルを読み取ることができる。

狙うのはn8nの設定ファイルやデータベースだ。

ステップ2:管理者Cookieを偽造する

ステップ1で取得したDBや設定ファイルから、セッション署名に使われる秘密鍵や管理者の認証情報を抽出する。

これを使って管理者権限のCookieを偽造すれば、n8nの管理画面に完全ログインした状態を作り出せる。パスワードも2FAも不要。

ステップ3:Execute Commandノードで任意コードを実行

n8nには「Execute Command」というノードがある。文字通り、サーバー上でシェルコマンドを実行する機能だ。ワークフロー自動化のための正規機能だが、ここに到達できれば何でもできる

偽造した管理者セッションでログインし、Execute Commandノードを含むワークフローを作成して実行する。これで攻撃者はサーバー上で任意のコードをリモート実行できる。

3ステップすべてが認証不要から始まるのが、このCVSSスコア10.0の理由だ。

影響範囲と深刻度

Cyera Research Labsの調査によると、インターネットに公開されているn8nサーバーは推定10万台にのぼる。

CVSS 10.0は「Critical」の最高スコアで、実際に付与されるケースはかなりまれだ。Log4Shellが10.0だったことを覚えている人もいるだろう。あの騒ぎと同じ深刻度がn8nに付いた。

特に問題なのは攻撃の難易度が低い点だ。攻撃者はn8nのアカウントを持っている必要がなく、ターゲットサーバーのURLさえわかれば攻撃を開始できる。Horizon3.aiが公開したPoCが出回ったことで、スクリプトキディレベルでも悪用できる状況になっている。

影響が特に大きいのは以下のようなケース:

  • 自社AIパイプラインをn8nで構築している企業 — 社内DBやAPIキーへのアクセスがそのままサーバーに保存されている可能性
  • SaaS連携を自動化している環境 — SlackトークンやGitHubトークンなど多数のクレデンシャルがワークフロー内に存在する
  • VPN外から管理画面にアクセスできる設定 — セルフホスト環境でインターネット公開している場合が直撃
  • マネージドサービスのn8n Cloud利用者 — クラウド版は別途パッチ適用済みのため影響外だが、アップデートの確認は推奨される

n8nは「外部公開されていなければ安全」だが、管理の手軽さからAWS/GCPのEC2やVMに直接ポートを開けて運用しているケースが多い。「とりあえず動かしたくて0.0.0.0でリッスンした」という運用が命取りになる。

対策方法

対策はシンプルだ。

今すぐやること:n8n v1.121.0以降にアップグレード

修正済みバージョンはv1.121.0。これ以前のバージョンを使っているなら即アップデートする。

# npm/npxで使っている場合
npminstall-gn8n@latest

# Dockerの場合
dockerpulln8nio/n8n:latest
dockercomposedown&&dockercomposeup-d

セルフホスト環境の見直し

アップグレードと並行して、以下も確認しておくこと:

  • 外部公開の範囲を絞る — n8nの管理UIをインターネットに直接公開しない。VPN経由またはIP制限を設ける
  • Webhookエンドポイントのみ公開する — 外部からのトリガーが必要なら、管理UIと分離してWebhook URLだけを開ける設定にする
  • クレデンシャルをn8nから分離する — 重要なAPIキーはn8n内ではなく、HashiCorp VaultやAWS Secrets Managerで管理する

侵害を確認する

すでに攻撃を受けていないか確認することも重要だ。n8nのログを見て、知らないワークフローが作成・実行されていないかチェックする。特に「Execute Command」ノードを含むワークフローが身に覚えなく存在していたら赤信号だ。

わさびの警告

n8nはLLMエージェントを組むのに本当に便利で、僕自身も使っている。だからこそ今回は正直ヒヤッとした。

「セルフホストだから安全」という感覚は危ない。セルフホストはクラウドサービス運営者がやってくれていたセキュリティ管理を自分でやらなきゃいけないということでもある。n8nに限らず、Flowise、Dify、LangFlowあたりのセルフホスト型AIワークフローツールを使っている人は、同じ問題を抱えている可能性がある。

CVSSスコア10.0の脆弱性は年に何件あるかというレベルで希少だ。でも現実として存在する。アップデートは今日やってほしい。

「後でやろう」は「やらない」とほぼ同義だ。

n8nを使ってLLMエージェントを組んでいる人は、そのサーバーに何が保存されているか一度棚卸ししてほしい。OpenAIやAnthropicのAPIキー、SlackやNotionのトークン、社内DBの接続文字列——これらが全部入ったサーバーが外部からフルアクセス可能な状態になっていたとしたら、それは単なるサーバー1台の問題じゃない。

AIワークフローが「インフラの一部」として定着した今、そのセキュリティも同じレベルで考えないといけない時期に来ている。


ソース: Cyera Research Labs / CSO Online / The Hacker News / Horizon3.ai


あわせて読みたい




わさび(@akaponpon440)はあかはらVラボの管理人。ニホンイシガメ。

この記事が参考になったら|以下のリンクから見てもらえるだけで、ブログ運営の応援になります。

コメント

タイトルとURLをコピーしました