はじめに：なぜフロントエンドエンジニアがこの脆弱性に関心を？

今回ご紹介する脆弱性は、主にバックエンドのワークフロー自動化ツールであるn8n-mcpに関するものです。一見するとフロントエンドエンジニアには直接関係ないように思えるかもしれません。しかし、n8n-mcpはNode.jsベースであり、CI/CDパイプラインやデプロイプロセス、あるいはAPIゲートウェイの背後で間接的に利用されることもあります。Webアプリケーション全体のセキュリティを理解し、システム全体の健全性を高めることは、すべての開発者にとって非常に重要です。この脆弱性を通じて、ミドルウェアのセキュリティ対策と、多層防御の考え方について理解を深めましょう。

脆弱性の概要 (CVE-2026-45707 / GHSA-jxx9-px88-pj69)

この脆弱性は、n8n-mcpをマルチテナントモード（環境変数 `ENABLE_MULTI_TENANT=true`）で運用している場合に発生します。通常、各テナントのn8nインスタンスへのリクエストは、`x-n8n-url`と`x-n8n-key`というHTTPヘッダーによって識別され、適切なテナントのインスタンスにルーティングされます。

しかし、本脆弱性の問題は、これらのヘッダーがリクエストに含まれていない、または不完全な場合に発生します。本来テナント自身のインスタンスに送られるべきリクエストが、サイレントに運用者（サービス提供者）自身のn8nインスタンスにフォールバックして処理されてしまうという重大な欠陥がありました。これにより、認証済みのMCPテナントが、自分の権限ではアクセスできないはずの運用者のn8nインスタンスに対して、管理用のAPI呼び出しを実行できてしまう状態でした。

この脆弱性は、HTTPモードで共有のマルチテナントサービスとして稼働している `n8n-mcp` のデプロイメントにのみ影響し、シングルテナント環境（`ENABLE_MULTI_TENANT` が未設定または `false`）は影響を受けません。

具体的な影響とリスク

この脆弱性が悪用されると、認証済みのMCPテナントは、運用者のn8nインスタンス上で以下のような非常に危険な操作が可能になります。

**情報漏洩・データ改ざん**: 運用者のワークフロー、実行履歴、データテーブルの内容、さらには認証情報（クレデンシャル）のメタデータなど、機密性の高い情報を読み取ったり、不正に書き換えたりできる可能性があります。

**リモートコード実行 (RCE) の可能性**: 最も深刻なリスクとして、もし運用者のn8nインスタンスが「Codeノード」経由でのOSレベルのモジュール実行を許可している場合、攻撃者は運用者のn8nが稼働するサーバー上で任意のコードを実行できる可能性があり、これはシステム全体の乗っ取りにもつながりかねません。

運用者の `N8N_API_KEY` は通常、非常に高い権限を持つキーであり、コミュニティ版ではデフォルトで権限範囲の制限がなく、エンタープライズ版でも運用者自身の必要性に基づいて設定された高権限が、そのまま悪用されることになります。

あなたのプロジェクトへの影響確認

もしお使いのシステムで `n8n-mcp` を利用しており、特にマルチテナントモード（`ENABLE_MULTI_TENANT=true`）で運用している場合は、この脆弱性の影響を直接受ける可能性があります。まずは現在利用している `n8n-mcp` のバージョンを確認してください。

今すぐ取るべき対策

この脆弱性は深刻度が高いため、速やかな対応が求められます。

**n8n-mcp 2.51.2** でこの脆弱性は修正されています。可能な限り速やかに最新版にアップグレードしてください。

修正内容には、ヘッダーがないマルチテナントリクエストをHTTP 400エラーで即座に拒否するようになったこと、マルチテナントモードでの環境変数からのn8n APIクライアントの構築拒否、そして運用者のURLや環境キーの情報がテナントに漏洩する二次的な経路の閉鎖が含まれます。

**アップグレード方法:**

NPMの場合: `npx n8n-mcp@latest`

Dockerの場合: `docker pull ghcr.io/czlonkowski/n8n-mcp:latest`

一時的に以下のいずれかの対策を講じることで、リスクを軽減または排除できます。

**マルチテナントモードの無効化**: `ENABLE_MULTI_TENANT=false` に設定するか、この環境変数を未設定にします。その上で、テナントごとに個別のn8n-mcpインスタンスを、それぞれのテナント用の `N8N_API_URL` と `N8N_API_KEY` で運用してください。これにより、脆弱性のあるコードパス自体が完全に排除されます。

**プロキシでの不正なリクエストの拒否**: リバースプロキシ（例: Nginx, Apache）を導入し、`x-n8n-url`と`x-n8n-key`の両ヘッダーがすべてのリクエストに存在することを必須とします。どちらかが欠落している場合はHTTP 400エラーを返すように設定してください。ただし、これはヘッダー欠落による主要な脆弱性経路を無効化するのみで、一部の情報漏洩リスクは残るため、部分的な軽減策である点に注意が必要です。

**運用者APIキーの権限を最小化**: もしお使いのn8nインスタンスがAPIキーのスコープ（権限範囲）設定に対応している場合（Enterprise版や一部のCommunity Editionビルド）、運用者の`N8N_API_KEY`にn8n-mcpの機能に必要な最小限の権限のみを付与してください。これは、脆弱性による境界突破自体を防ぐものではありませんが、万が一悪用された場合の被害範囲を限定できます。

まとめ

今回のn8n-mcpの脆弱性は、Webアプリケーション全体のセキュリティ設計における「多層防御」と「最小権限の原則」の重要性を改めて示しています。フロントエンドエンジニアとして、直接バックエンドのコードを触ることが少なくても、利用しているミドルウェアやサービスのセキュリティ動向には常にアンテナを張り、システム全体の健全性を高める意識を持つことが重要です。最新の情報をキャッチアップし、常にセキュアな開発を心がけましょう。