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

こんにちは、日本のフロントエンドエンジニアの皆さん。今回は、ワークフロー自動化ツールn8nに関する深刻なセキュリティ脆弱性「GHSA-6qc9-mqvw-jg7x」について解説します。

「n8nはバックエンドやインフラのツールでは？」と感じる方もいるかもしれません。しかし、多くのモダンなWeb開発において、CI/CDパイプライン、バックエンドAPIとの連携、デプロイ自動化、データ処理などでn8nのようなワークフローツールが間接的に利用されるケースは少なくありません。特にAPIキーやDB接続情報といった機密情報の管理は、フロントエンドがバックエンドと連携する上で非常に重要な要素です。この脆弱性は、そうした機密情報が不正に利用されるリスクをはらんでおり、システム全体のエンドツーエンドなセキュリティを考える上で、私たちフロントエンドエンジニアもその内容と対策を理解しておくべきです。

脆弱性の概要 (GHSA-6qc9-mqvw-jg7x)

この脆弱性は、n8nのHTTP Requestノードにおいて、クレデンシャル（認証情報）の指定方法に起因するものです。深刻度は「High」とされており、権限のないユーザーが共有ワークフローを悪用することで、本来アクセス権のない他のユーザーの機密情報（APIキー、データベース接続情報など）を不正に利用したり、外部に持ち出したりすることが可能になります。

これは、システムにおける認証情報の機密性が根本的に損なわれる可能性を示唆しており、非常に重大なセキュリティリスクと言えます。

脆弱性の詳細な仕組み

具体的には、n8nのHTTP Requestノードでクレデンシャルのタイプを「式」(Expression) で指定する機能に問題がありました。通常、ワークフローの編集権限を持つユーザーは、自分がアクセスを許可されているクレデンシャルしか使用できないはずです。

しかし、脆弱性のあるバージョンでは、ワークフローの「実行前」に行われる権限チェックが、ユーザーが指定した「未解決の式」（例: `={{ $credential.myApiCredential.id }}` のような動的な指定）の内容ではなく、ワークフロー定義内の静的な値を見ていました。このため、式の評価が行われ、実際にクレデンシャルがロードされる「実行時」になって初めて、本来の所有権チェックが行われるべきタイミングで、そのチェックが実質的に迂回されてしまいました。

これにより、悪意のあるユーザーは、自分がアクセス権を持たない他者のクレデンシャルを式として指定し、それをHTTPリクエストノードを通じて利用・窃取することが可能になってしまったのです。

悪用される条件と具体的な影響

この脆弱性を悪用するには、いくつかの条件が揃っている必要がありました。

1. **認証済みのユーザーであること:** 攻撃者はn8nインスタンスにログインできる必要があります。

2. **共有ワークフローへの編集アクセス権があること:** 攻撃者は、不正なHTTP Requestノードを含むワークフローを作成または編集できる権限を持っている必要があります。

3. **ターゲットとなる他のユーザーのクレデンシャル識別子（ID）を知っていること:** 攻撃者は、窃取したいクレデンシャルのIDを特定できる必要があります。

これらの条件が揃うと、攻撃者は共有ワークフローに不正なHTTP Requestノードを仕込み、本来アクセス権のない他のユーザーのクレデンシャル（例: AWSのAPIキー、Stripeのシークレットキー、データベースの接続情報など）を使って、外部サービスへのリクエストを実行したり、クレデンシャル自体を外部に持ち出したりすることが可能になります。これにより、情報漏洩や不正なサービス利用といった甚大な被害が発生する可能性があります。

緊急対応：推奨される対策

n8n開発元は本脆弱性に対する修正をリリース済みです。**最優先で以下のいずれかのバージョンへアップグレードしてください。**

修正済みのバージョン:

<ul><li>n8n **1.123.67** 以降</li><li>n8n **2.31.5** 以降</li><li>n8n **2.32.1** 以降</li></ul>

これらのバージョンへのアップグレードが、この脆弱性を解消するための最も確実で推奨される方法です。

やむを得ずすぐにアップグレードできない場合、以下のいずれかの回避策を検討してください。ただし、これらはあくまで一時的な措置であり、リスクを完全に排除するものではないことをご理解ください。

1. **n8nインスタンスへのアクセスを制限:** n8nインスタンスへのアクセスを、完全に信頼できると判断されたユーザーのみに厳しく制限してください。

2. **HTTP Requestノードの無効化:** もしワークフローでHTTP Requestノードを使用していない場合は、環境変数`NODES_EXCLUDE`に`n8n-nodes-base.httpRequest`を追加して、このノードをサーバー全体で無効にすることを検討してください。これにより、脆弱性のあるパスが利用されなくなります。

3. **クレデンシャル共有設定およびワークフローへのアクセス権限の監査:** クレデンシャルの共有設定とワークフローへのアクセス権限を徹底的に見直し、信頼できないユーザーにクレデンシャルのIDが漏洩しないように、また不必要なワークフロー編集権限を与えないように制限してください。

まとめ

n8nの認証情報窃取につながるこの脆弱性 (GHSA-6qc9-mqvw-jg7x) は、非常に深刻な問題です。直接n8nを運用していないフロントエンドエンジニアであっても、関わるシステム全体のセキュリティチェーンの一環として、その影響範囲と対策を理解しておくことは重要です。

最新の情報に常に注意を払い、利用しているツールやライブラリのセキュリティアップデートを怠らないようにしましょう。安全な開発環境とサービス運用は、私たちエンジニア全員の責任です。