はじめに：なぜフロントエンドエンジニアがこの脆弱性を知るべきか？

皆さん、こんにちは。日本のフロントエンドエンジニアの皆さんにとって、n8nは直接的な開発対象ではないかもしれません。n8nはバックエンドのワークフロー自動化ツールであり、さまざまなサービス間の連携やタスク自動化を実現します。しかし、API経由でn8nのワークフローをトリガーしたり、CI/CDパイプラインの一部として利用したりと、間接的に関わる機会は少なくありません。

今回解説するn8nの脆弱性 (GHSA-2x35-3fw4-9jr4) は、サーバー内のファイル漏洩という深刻なリスクを伴います。もし皆さんのプロジェクトでn8nが利用されている場合、バックエンドチームと連携し、早急な対策を検討することが重要です。この脆弱性の内容を理解することで、より堅牢なシステム構築に貢献できるでしょう。

脆弱性の概要：GHSA-2x35-3fw4-9jr4

この脆弱性は、ワークフロー自動化ツールn8nのメール送信機能に存在するものです。深刻度は「High」とされており、悪用されるとn8nが動作しているサーバー内の機密ファイルが外部に漏洩する可能性があります。

問題は、n8nのメール送信ノードにおける「メッセージフィールド」の入力値の処理方法にありました。通常、このフィールドにはメールの本文となる文字列が期待されます。しかし、このメッセージフィールドが文字列であることを適切に強制していなかったため、ワークフローからの信頼できない非文字列の入力値（例えば、オブジェクトや配列など）が渡された場合、n8n内部のメールライブラリによって、それらの値がファイルパスやURLとして誤って解釈されてしまう可能性がありました。

結果として、攻撃者が特定の細工を施した入力値をメールのテキストまたはHTMLボディフィールドに送り込むことで、n8nが動作しているサーバー内のローカルファイル（例えば、設定ファイルや環境変数、APIキーなどの機密情報）を読み込み、外部に送信されるメールにその内容を含めてしまうことが可能になってしまいます。

この脆弱性が悪用されるには、いくつかの特定の条件が揃う必要があります。これはn8nのデフォルト設定ではありません。

具体的には、以下の全てに当てはまる場合にリスクが高まります。

1. **認証なしでアクセス可能なWebhookを持つアクティブなワークフローが存在する。**

2. **そのワークフローのメール送信ノードに有効なSMTP認証情報が設定されている。** (つまり、メールが実際に送信できる状態である)

3. **外部からの信頼できない入力（特にWebhookからの入力）が、メールのテキストまたはHTMLボディフィールドに直接マッピングされている。**

これらの条件が揃うことで、攻撃者は外部から送られた悪意のある入力を利用し、n8nサーバーのファイルを読み取らせ、その内容を外部のメールアドレスに送信させることが可能になります。

影響と対策

最も懸念されるのは、n8nサーバー上に存在する設定ファイル、データベース接続情報、APIキー、環境変数など、システムの根幹に関わる機密情報が外部に漏洩することです。これにより、システム全体のセキュリティが脅かされ、さらなる攻撃の足がかりとなる可能性があります。

この脆弱性は、以下のバージョンで修正済みです。速やかにこれらまたはそれ以降のバージョンにアップグレードすることを強く推奨します。

**修正済みバージョン:**

- `1.123.67`

- `2.31.5`

- `2.32.1`

アップグレードがすぐに実施できない場合は、以下の緩和策を検討してください。ただし、これらはあくまで一時的なものであり、リスクを完全に解消するものではないことを理解しておく必要があります。

1. **ワークフローの監査と修正:** 外部からの信頼できないデータ（特にWebhookからの入力）をメールのテキストやHTMLボディフィールドに直接マッピングしているワークフローがないか確認し、該当する場合はそのワークフローを削除するか、入力制限（サニタイズ、型チェックなど）を設けてください。

2. **Webhookアクセス制限:** 非認証の呼び出し元が機密性の高いワークフローに到達するのを防ぐため、ネットワークレベル（ファイアウォールなど）またはリバースプロキシレベルでパブリックなWebhookアクセスを制限してください。

3. **権限の厳格化:** ワークフローの作成および編集権限を、完全に信頼できるユーザーのみに限定してください。

フロントエンドエンジニアとしての視点：セキュリティ意識の向上

この脆弱性はn8nというバックエンドツールに関するものですが、フロントエンドエンジニアの皆さんにも学ぶべき点が多くあります。

- **入力値検証の徹底:** ユーザーからの入力は、常に信頼できないものとして扱うべきです。フロントエンドでのバリデーションはもちろん重要ですが、バックエンドでも厳格な型チェックとサニタイズが不可欠であることを改めて認識しましょう。今回の脆弱性も、入力値の型強制が適切でなかったことが原因です。

- **サービス連携におけるセキュリティ:** 外部サービスと連携する際は、そのサービスのセキュリティ状況にも目を向けることが重要です。APIキーや認証情報がどのように扱われているか、データがどのように流れているかを把握しましょう。

- **CI/CDパイプラインの構成:** もしn8nのようなワークフローツールがCI/CDパイプラインの一部として使われている場合、そのセキュリティも全体のサプライチェーンリスクの一部となります。定期的なツール類のバージョン確認とアップデートを徹底しましょう。

まとめ

n8nのメール送信機能におけるファイル漏洩の脆弱性 (GHSA-2x35-3fw4-9jr4) は、サーバー内の機密情報漏洩に繋がる深刻な問題です。関係者の皆様は、速やかに推奨されるバージョンへのアップグレードを実施し、システムの安全性を確保してください。

常に最新のセキュリティ情報をチェックし、日頃から脆弱性対応への意識を高めておくことが、安全なWebサービス開発には不可欠です。