はじめに：なぜフロントエンドエンジニアがn8nの脆弱性に関心を持つべきか？

n8nは、API連携やバックエンドのプロセス自動化を可能にする強力なオープンソースのワークフロー自動化ツールです。直接フロントエンドコードを書くわけではありませんが、多くのフロントエンドエンジニアが関わるWebアプリケーションのバックエンド処理やAPI連携において、n8nが重要な役割を果たすことがあります。例えば、Webhooksを利用したリアルタイム連携や、バックエンドAPIの一部として機能することも珍しくありません。このような状況下で、n8nにセキュリティ脆弱性が存在すると、それが間接的にフロントエンドアプリケーションのユーザーにも影響を及ぼす可能性があります。特に、今回ご紹介するXSS（クロスサイトスクリプティング）は、フロントエンド開発者が最も警戒すべき脆弱性の一つです。

今回の脆弱性 (GHSA-v733-mwr6-fgcm / CVE-2026-54301) の概要

この脆弱性は、n8nの「Respond to Webhook」ノードに存在するSame-Origin XSS（同一オリジンXSS）であり、深刻度は「High」と評価されています。具体的には、ワークフロー編集アクセス権を持つ認証済みの攻撃者が、悪意のあるWebhookを作成し、それにアクセスした認証済みユーザーのブラウザ上で不正なJavaScriptコードを実行させることが可能になります。これにより、ユーザーのセッション情報が盗まれたり、意図しない操作が行われたりするリスクがあります。

技術的な深掘り：Same-Origin XSSとCSP迂回のメカニズム

今回の脆弱性の中核は、n8nの「Respond to Webhook」ノードにあります。このノードは、外部からのWebhookリクエストを受け取り、任意のHTTPレスポンスを返す機能を提供します。通常、アプリケーションはXSS攻撃を防ぐために、Content-Security-Policy (CSP) などのセキュリティヘッダーを適切に設定し、信頼できないソースからのスクリプト実行を制限します。しかし、今回の脆弱性ではこの保護メカニズムが迂回されてしまいました。

XSSは、攻撃者がWebサイトに悪意のあるスクリプトを注入し、それを他のユーザーのブラウザで実行させる攻撃です。Same-Origin XSSは、特に同一オリジンポリシー（Same-Origin Policy）の保護下にあるはずのアプリケーション自身のドメイン上で、攻撃者のスクリプトが実行されてしまう状況を指します。これにより、ブラウザのセキュリティモデルが期待通りに機能せず、正規のコンテンツと同じ権限でスクリプトが動作するため、セッションCookieへのアクセス、LocalStorageの読み書き、認証情報の窃取など、深刻な被害につながる可能性があります。

この攻撃は以下のステップで実行されます：

1. **攻撃者のワークフロー設定**: 攻撃者は、n8nのワークフロー編集アクセス権を持つ認証済みユーザーとして、細工された「Respond to Webhook」ノードを含むワークフローを作成します。このノードは、外部からのWebhookリクエストに対して、通常のJSONなどではなく、攻撃者が制御する`Content-Type`（例: `text/html` や `application/javascript`）を持つバイナリコンテンツを返すように設定されます。

2. **CSPの迂回**: n8nは通常、レスポンスにCSPヘッダーを付与してXSS攻撃を緩和しますが、この特定のシナリオでは、`Respond to Webhook`ノードが意図的に特定の`Content-Type`を持つバイナリコンテンツを返した場合に、CSPが正しく適用されないという問題がありました。これにより、ブラウザは返されたコンテンツをHTMLやJavaScriptとして解釈してしまいます。

3. **不正なJavaScriptの実行**: 認証済みのユーザーが、この悪意のある公開WebhookのURLにアクセスすると、n8nのドメイン上で攻撃者が仕込んだ不正なJavaScriptコードが実行されます。このコードは、正規のn8nアプリケーションのスクリプトとして動作するため、そのユーザーのセッション情報や、n8nのAPIに対するリクエストを自由に実行できる状態になります。

不正なJavaScriptが実行されると、以下のような深刻な被害が発生する可能性があります：

1. **セッションハイジャック**: ユーザーのセッションCookieや認証トークンが窃取され、攻撃者がそのユーザーとしてログインできるようになります。

2. **アカウント乗っ取り**: 攻撃者がユーザーのアカウント情報にアクセスし、設定の変更、データの閲覧・削除、さらに他のワークフローの操作を行う可能性があります。

3. **機密情報の窃取**: n8nのワークフロー内に保存されているAPIキーやデータベース接続情報などの機密情報が、不正なスクリプトによって抜き取られる可能性があります。

この攻撃は、脆弱性のあるバージョンのn8nを使用しており、かつ信頼できないユーザーにワークフローの作成・編集権限が付与されている場合に発生しえます。

影響を受けるバージョンと緊急の対策

この脆弱性は、特定のn8nのバージョンに存在します。開発チームによって迅速に修正されており、以下のバージョンで対策が適用されています。

1. **バージョン 1.123.55**

2. **バージョン 2.25.7**

3. **バージョン 2.26.2**

または、これら以降の最新バージョン。

現在n8nを運用されている方は、上記の修正済みバージョン、あるいはそれ以降の最新バージョンへ速やかにアップグレードすることを強く推奨します。これは、脆弱性を完全に解消するための最も効果的で恒久的な対策です。

もし直ちにアップグレードが難しい場合、以下のいずれかの一時的な対策を検討してください。ただし、これらはあくまで短期的な緩和策であり、リスクを完全に排除するものではないことにご注意ください。

1. **ワークフロー作成・編集権限の制限**: ワークフローの作成や編集権限を、完全に信頼できる管理者ユーザーのみに限定してください。信頼できないユーザーに権限がある場合、この脆弱性を悪用される可能性が高まります。

2. **「Respond to Webhook」ノードの無効化**: 環境変数`NODES_EXCLUDE`に`n8n-nodes-base.respondToWebhook`を追加することで、問題の「Respond to Webhook」ノード自体を無効化できます。これにより、このノードを悪用した攻撃を防ぐことができますが、当然ながらこのノードに依存するワークフローは機能しなくなります。

まとめ：フロントエンド開発とセキュリティ

今回のn8nのXSS脆弱性は、XSSが依然として強力な攻撃ベクトルであること、そしてCSPのような現代的なセキュリティ対策も、実装のわずかな抜け穴を突かれると迂回される可能性があることを改めて示しています。直接n8nを運用していなくても、API連携などで間接的に利用しているサービスやミドルウェアのセキュリティ情報には常にアンテナを張り、迅速な情報収集と対応が不可欠です。

フロントエンドエンジニアとしては、自身が開発するアプリケーションにおいても、XSS対策（サニタイズ、エスケープ処理、適切なCSP設定など）を徹底し、常に最新のセキュリティベストプラクティスを学ぶ姿勢が求められます。バックエンド、フロントエンド、インフラ全体でのセキュリティ意識と協力が、ユーザーを脅威から守る鍵となります。定期的なアップデートとセキュリティ監査を怠らないようにしましょう。