n8nのセキュリティ｜脆弱性情報の確かめ方と安全な運用

この記事の内容は、2026年10月2日に n8n の公式ドキュメント、公式サイト、GitHub で確かめたものです。脆弱性情報と設定の項目は変わります。使う前に、末尾の出典から最新の内容を確かめてください。

n8nのセキュリティを考えるときは、n8n という製品そのものの安全性と、自分たちの運用の安全性を分けて見ます。製品に脆弱性が見つかることはあります。そのとき、すぐに更新できる体制があるかどうかで、危険の大きさが変わります。

n8nの安全性はどこで決まるか：クラウド版とセルフホスト

n8n には、n8n が運営する n8n Cloud と、自分のサーバーで動かすセルフホストがあります。公式ドキュメントは、セルフホストでは保守が利用者の責任になると説明しています。

n8n Cloud の場合

n8n のセキュリティのページによると、n8n Cloud は Microsoft Azure で動いており、データは2026年10月時点で欧州連合の中に保存されています。保存データは AES256 で暗号化され、顧客ごとのインスタンスは論理的に分けられています。第三者による侵入テストを、少なくとも年に1回行っていると説明しています。

同じページによると、顧客とシステムのデータは毎日バックアップされ、同じ国の別の地域に複製されます。サーバーのログは一か所に集められ、監査ログの履歴は少なくとも12か月保管されます。社員が機密データに触れる権限は、仕事に必要な範囲に限られ、四半期ごとに見直されています。

SOC 2 について

同じページは、n8n のセキュリティの取組を SOC 2 の枠組みに合わせ、独立した監査人による年1回の監査を受けていると説明しています。SOC 2 のレポートは Enterprise の顧客に提供され、それ以外の人は SOC 3 のレポートを読めます。n8n の Trust Center にも、セキュリティとコンプライアンスの情報がまとめられています。

セルフホストの場合

セルフホストでは、パスワードのハッシュ化は n8n が行いますが、ほかのデータの保存時の暗号化は利用者の責任です。通信の暗号化には、n8n の前にリバースプロキシを置いて TLS を受け持たせる方法が勧められています。

脆弱性情報の確かめ方

n8n の脆弱性（vulnerability）の情報は、GitHub の n8n リポジトリの Security のページで公開されています。1件ごとのアドバイザリに、深刻度、影響を受けるバージョン、修正済みのバージョンが書かれています。

たとえば、2026年9月30日に公開されたアドバイザリの一つは、Microsoft SQL ノードの SQL インジェクションに関するものです。深刻度は High で、修正済みのバージョンとして 2.42.1 以降と 2.41.4 以降が挙げられています。自分の n8n のバージョンがこの範囲より古ければ、更新が必要です。

n8n の更新のドキュメントは、こまめに更新し、少なくとも月に1回は更新するよう勧めています。一度に多くのバージョンを飛ばすと、更新で動かなくなる危険が増えるためです。更新の前にリリースノートで互換性のない変更を確かめ、テスト用の環境で先に試すことも勧めています。

脆弱性を見つけた場合は、n8n の脆弱性開示プログラム（Vulnerability Disclosure Program）から報告できます。

セルフホストで必要な設定

公式ドキュメントのセキュリティの章は、セルフホストのインスタンスを守る方法として、セキュリティ監査、SSL、SSO、ノードの制限、公開APIの無効化、実行データの秘匿などを挙げています。最初に確かめたいものをまとめます。

セキュリティ監査を動かす

n8n には、よくある問題を見つけるセキュリティ監査の機能があります。CLI で n8n audit を実行するか、公開APIか n8n ノードから動かします。監査の結果は、次の5つの報告に分かれます。

• 認証情報：どのワークフローでも使われていない認証情報など
• データベース：SQL ノードのクエリに式が使われている箇所など
• ファイルシステム：ファイルを読み書きするノード
• ノード：危険になりうる公式ノード、コミュニティノード、カスタムノード
• インスタンス：保護されていない Webhook、足りないセキュリティ設定、古いバージョン

危険になりうるノードを止める

NODES_EXCLUDE という環境変数で、使わせたくないノードを止められます。ドキュメントは、最初に止める候補として、Execute Command ノードと、ディスクのファイルを読み書きするノードを挙げています。Execute Command ノードは、初期設定で止められています。

そのほかの設定

• SSL：リバースプロキシで TLS を受け持たせる方法が推奨されている
• 公開API：使わないなら無効にできる
• 実行データの秘匿：ワークフローの入力と出力を見せない設定。Enterprise プランの機能
• 二要素認証：認証アプリを使った二要素認証を設定できる
• SSO：SAML か OIDC でつなぐ。セルフホストでは Business と Enterprise の機能

セルフホストの準備全体は、n8nのセルフホストで説明しています。

コミュニティノードを入れるときの注意

コミュニティノードは、n8n 以外の人が作って npm で公開しているノードです。公式ドキュメントは、npm からコミュニティノードを入れることは、検証されていないコードをインスタンスに入れることだと説明しています。挙げられているリスクは次の3つです。

• システム：コミュニティノードは n8n が動くマシンに完全にアクセスでき、悪意のある動作も含めて何でもできる
• データ：使うコミュニティノードは、ワークフローの中のデータにアクセスできる
• 互換性：新しいバージョンで互換性のない変更が入り、ワークフローが動かなくなることがある

マルウェアを心配する場合は、ここが一番の注意点です。n8n は、一部のコミュニティノードを検査し、検証済みのノードとしてノードの一覧に出しています。検証済みのノードは、データとシステムのセキュリティの要件を満たす必要があります。

セルフホストでは、環境変数 N8N_COMMUNITY_PACKAGES_ENABLED を false にすると、コミュニティノードを止められます。n8n Cloud では、管理画面から止められます。問題のあるコミュニティノードは、security@n8n.io に報告できます。

認証情報の保管

n8n は、連携先のAPIキーやパスワードを、認証情報として保存します。セルフホストでは、最初の起動時に暗号化キーが自動で作られ、ホームディレクトリの .n8n フォルダーに保存されます。n8n はこのキーで認証情報を暗号化してから、データベースに保存します。

• 暗号化キーは、環境変数 N8N_ENCRYPTION_KEY で自分で決めることもできる
• キューモードで動かす場合は、すべてのワーカーに同じキーを設定する
• セルフホストでは、認証情報を暗号化する鍵を定期的に入れ替える機能もある。行えるのはインスタンスのオーナー
• 外部のシークレット管理サービスとつなぐ機能は、料金ページでは Enterprise プランに含まれている

セキュリティのページによると、n8n Cloud では、認証情報はワークフローの実行時に読み込まれ、初期設定では記録や書き出しをされません。使っていない認証情報は、セキュリティ監査の認証情報の報告で見つけられます。

導入前のチェックリスト

社内で n8n を使う場合も、n8n で作られたAIエージェントを導入する場合も、次の点を確かめます。導入するAIの作り手に聞く場合は、そのまま質問のリストとして使えます。

1. n8n Cloud か、セルフホストか。セルフホストなら、誰のサーバーか
2. 今のバージョンと、更新を誰がどの頻度で行うか
3. GitHub の脆弱性情報を誰が確かめるか
4. コミュニティノードを使っているか。使うなら検証済みか
5. 連携先の認証情報は、誰のアカウントで発行したものか
6. 暗号化キーをどこに保管し、誰が持っているか
7. セキュリティ監査を動かしたことがあるか
8. 実行の記録に、個人情報や機密情報が残るか

AIエージェント全体のセキュリティはAIエージェントのセキュリティで、n8n の基本はn8nの使い方で説明しています。

Employee Store には、n8n のワークフローで作られたAI社員も掲載されます。購入者と出品者は、取引ごとの取引ルームでメッセージをやり取りできます。上のチェックリストは、導入の前に取引ルームで出品者に確かめておくと安心です。