はじめに：n8n-mcpとは？なぜフロントエンドエンジニアが知るべきか

n8nは、Open-Sourceのワークフロー自動化ツールです。API連携やデータ処理など、様々なタスクをコードなし、または少ないコードで自動化できます。特に、バックエンド処理の自動化、Webhookの利用、各種SaaSとの連携などで使われることが多く、フロントエンドアプリケーションから呼び出されるAPIの裏側や、データ連携基盤として活用されるケースもあります。

今回の脆弱性は「n8n-mcp」という、n8nの特定のコンポーネント（おそらくn8n本体の実行環境や管理プレーンの一部）に影響します。フロントエンド開発者の皆さんが直接n8n-mcpを操作することは少ないかもしれませんが、もし皆さんのプロジェクトでn8nが利用されており、そこにAPIキーやトークンなどの機密情報が設定されている場合、今回の脆弱性はアプリケーションのセキュリティ全体に影響を及ぼす可能性があります。

脆弱性の概要：3つの深刻な問題点

今回発見されたのは、n8n-mcpのバージョン2.50.1未満に存在する3つの独立した脆弱性です。これらは認証されたユーザーが存在し、かつn8nのAPIキーが設定されている環境で悪用される可能性があります。CVSSスコアは8.3（HIGH）と評価されており、迅速な対応が求められます。

各脆弱性の詳細と影響

この脆弱性は、n8n-mcpがリクエストURL内の識別子を適切に検証せず、それをパスの一部として使用してしまうことで発生します。悪意のある認証済みユーザーが細工されたワークフローIDを渡すと、本来アクセスが制限されているはずの同じオリジン内の別エンドポイントへ、設定済みのAPIキーを含む外部リクエストが送信されてしまう可能性があります。

これにより、アクセス制御がバイパスされ、予期せぬAPI操作が行われたり、内部APIが外部に公開されてしまうリスクがあります。フロントエンドから呼び出すAPIの認証情報が、意図せず他のエンドポイントに流用されるような事態も考えられます。

n8n-mcpがWebhookやフォーム、チャットトリガーのURLを検証する際、初期検証を通過したURLが「リダイレクト」を指示した場合、本来アクセスを拒否すべき外部ホストへもリクエストを送信してしまいます。そしてそのレスポンスボディは、攻撃者に返されてしまいます。

これは「非盲目型SSRF」と呼ばれる脆弱性の一種で、攻撃者はn8n-mcpが動作しているサーバーから、外部（または内部ネットワーク上の）任意のURLへリクエストを送信させ、その応答内容を受け取ることができます。これにより、内部ネットワークの構造や機密情報を探られたり、外部への攻撃の踏み台として悪用される可能性があります。フロントエンド側で指定するWebhook URLなどが、意図せずSSRFの起点となるリスクがあります。

n8n-mcpのテレメトリ機能（製品改善のために利用状況データを収集する機能）がデフォルトで有効になっている場合、ワークフローの「部分的な更新操作」の差分情報が、マスキング（秘匿化）されずに外部にアップロードされていました。

この差分情報には、ワークフロー内に設定されたAPIキー、ベアラートークン、Webhookシークレットといった**極めて重要な機密情報**が含まれる可能性があり、これにより認証情報が第三者に漏洩するリスクがありました。フロントエンドから認証情報を安全に扱うためのベストプラクティスをいくら守っても、連携するバックエンドツールから漏洩してしまっては意味がありません。

悪用条件と深刻度

これらの脆弱性はCVSSスコア8.3（HIGH）と評価されています。悪用には以下の条件が揃っている必要があります。

1. 認証されたn8n-mcpのユーザーが存在すること。

2. n8nのAPIキーが設定されたn8n API連携が構成されていること。

つまり、内部のユーザーや、なんらかの方法で認証を突破した攻撃者が、これらの脆弱性を悪用する可能性があります。

いますぐ取るべき対応策

最も推奨される対策は、**n8n-mcpをバージョン2.50.1以降に直ちにアップグレードすること**です。これにより、上記の脆弱性はすべて修正されます。

アップグレードがすぐに難しい場合の回避策として、以下の対応を検討してください。

これらの回避策は一時的なものであり、根本的な解決のためにはバージョンアップが必須であることを忘れないでください。

まとめ：セキュリティ意識の重要性

今回のn8n-mcpの脆弱性は、自動化ツールや連携ツールがいかに重要な機密情報を扱っており、そのセキュリティがアプリケーション全体の安全性に直結するかを示す良い例です。フロントエンドエンジニアの皆さんも、直接触れる機会の少ないバックエンド寄りのツールであっても、使用しているライブラリやフレームワーク、連携しているサービスに脆弱性がないか常に注意を払う必要があります。

特にAPIキーやトークンなどの認証情報は、常に厳重に管理し、定期的なセキュリティアップデートを怠らないようにしましょう。