ニュース約4分で読めます

n8nに脆弱性10件、最新版へ更新を管理画面の公開範囲の見直しも

業務自動化ツールn8nに、2026年10月14日、10件の脆弱性(GitHubのセキュリティアドバイザリ)が公開されました。深刻度はHigh 3件・Moderate 7件でCriticalはなく、いずれもログインできる内部の利用者が前提です。保存した外部サービスの認証情報が漏れうるものも含みます。修正版への更新と、管理画面を公開しない基本の確認を整理します。

公開 2026年10月14日 23:40情シスのミカタ編集部AIにより執筆チェック済み

文字

この記事のまとめ

ワークフロー自動化ツール「n8n」に、2026年10月14日、10件の脆弱性(GitHubのセキュリティアドバイザリ)が公開されました。深刻度はHigh 3件・Moderate 7件で、Critical(緊急)はありません。修正版は2.44.1以降(2.x系)または1.123.85以降(1.x系)です。
今回の10件は、いずれもn8nにログインできる内部の利用者(権限の弱いメンバーなど)が前提で成立します。認証なしで遠隔からコードを実行されるものや、認証をすり抜けるものは、このバッチにはありません。公開時点で、悪用やPoCの公開、CISAのKEVへの掲載は確認されていません。
内容は、保存型のクロスサイトスクリプティング(XSS)、別プロジェクトのデータへの越境アクセス、サービス停止(DoS)のほか、保存した外部サービスの認証情報(各サービスのパスワードやトークン)が内部の利用者に漏れうるものが含まれます。n8nは多数のサービスの認証情報をためる基盤のため、権限の管理が重要です。
対応は、最新版への更新に加え、n8nの管理画面やWebhookをインターネットに直接公開しないこと、アカウントの権限を最小にすること、認証情報の定期的な変更です。n8nは過去に実際に悪用されてCISAのKEVに載った前例(別件)もあり、「外部に公開していないか」の確認が効きます。

こんな方に#30代 #40代 #50代実務

テーマ#n8n #自動化 #脆弱性 #セルフホスト #パッチ管理

目次ひらく

1何が公表されたのか
2内容: XSS・越境アクセス・DoS・認証情報の漏えい
3危ないのは「公開している」「権限を広げすぎている」こと
4影響する会社・しない会社
5情シスが今日やること

ノーコード/ローコードで業務の自動化を組める定番ツール「n8n」に、複数の脆弱性が公表されました。n8n公式が2026年10月14日に、GitHubのセキュリティアドバイザリとして10件を一度に公開したものです。深刻度はHigh 3件・Moderate 7件で、Critical(緊急)はありません。いずれもn8nにログインできる内部の利用者が前提で成立します。n8nは多数の外部サービスの認証情報をためる基盤のため、更新と、公開範囲・権限の見直しを、公式情報をもとに整理します。

何が公表されたのか

n8nは、各種のSaaSやデータを組み合わせて業務を自動化するツールで、無料で自前運用(セルフホスト)できます。今回の10件は、すべてGitHubのセキュリティアドバイザリ(GHSA)として公開され、CVE番号はまだ付いていません。修正版は、2.x系が2.44.1以降、1.x系が1.123.85以降で、これらに更新すれば今回の全件がカバーされます(エラーワークフローに関する1件は2.42.2・2.41.5でも修正)。

重要なのは、10件すべてが「n8nにログインできる内部の利用者」を前提にしている点です。認証なしで遠隔からコードを実行されるものや、認証をすり抜けるものは、今回のバッチにはありません。公開時点で、悪用やPoC(実証コード)の公開、CISAの「悪用が確認された脆弱性の一覧(KEV)」への掲載も確認されていません。

n8nの脆弱性の図解。2026年10月14日にGitHubセキュリティアドバイザリ10件が公開され、High 3・Moderate 7・Critical 0、全件が認証済みの内部利用者が前提で認証不要RCEや認証バイパスはなく、CVE未付番(GHSA番号)、悪用・PoC・KEVなし、修正は2.44.1以降または1.123.85以降。主な内容は、保存型XSS(GHSA-mp7q・8.4)、別プロジェクトへの越境アクセス(GHSA-wvjj・7.2)、サービス停止DoS(GHSA-m7gv・7.1)、Git・MongoDB・Google Cloud・SeaTable等のパスワードやトークンが内部利用者に漏れうる認証情報の漏えい系4件(Moderate)。危ないのは管理画面・Webhookの公開と権限の広げすぎで、n8nは多数のサービスの認証情報をためる基盤、過去にはCISA KEV入りの悪用例(別件・CVE-2025-68613)で公開インスタンスが多数さらされていた。情シスの対応は、更新、管理画面・Webhookを公開しない、権限の最小化、認証情報の変更と実行ログの閲覧制限の4点 — n8nの10件の脆弱性の要点と、更新・公開範囲の見直し(編集部作成)作成: 編集部 / もとの資料: 情シスのミカタ編集部

内容: XSS・越境アクセス・DoS・認証情報の漏えい

深刻度が高い主なものは、次のとおりです。

保存型のクロスサイトスクリプティング(GHSA-mp7q-23hg-35cf・CVSS 8.4): Webhookの応答を通じて、n8nの画面上でスクリプトが実行され、ほかの利用者のセッションで動くおそれ
別プロジェクトへの越境アクセス(GHSA-wvjj-qg37-pv73・CVSS 7.2): ワークフローのIDの細工で、本来見えない別プロジェクトのデータ(Data Table)を閲覧・改変・削除できるおそれ
サービス停止(GHSA-m7gv-mpg5-7c9v・CVSS 7.1): ファイル操作のノードで、n8nのプロセス全体が止まるおそれ

また、保存した外部サービスの認証情報(Git・MongoDB・Google Cloud・SeaTableなどのパスワードやトークン)が、本来は資格情報を読めない内部の利用者に漏れうる問題が複数含まれます。いずれも深刻度はModerateで、外部の匿名の攻撃者が直接奪うものではありませんが、n8nが多数のサービスの認証情報をためる基盤であることを踏まえると、軽視できません。

危ないのは「公開している」「権限を広げすぎている」こと

今回の脆弱性は、内部の利用者が前提です。そのため、実務でとくに気をつけたいのは、(1)n8nの管理画面やWebhookをインターネットに直接公開していないか、(2)半信頼の利用者に、安易にワークフローの作成や編集の権限を与えていないか、の2点です。

n8nは過去に、実際に悪用されてCISAのKEVに載った脆弱性(別件・CVE-2025-68613)もあり、インターネットに公開されたままの未修正インスタンスが多数あったと報告されています。今回のバッチとは別の話ですが、「n8nを外部に公開していないか」という確認は、引き続き有効です。

影響する会社・しない会社

影響する: n8nを自前で運用(セルフホスト)している会社です。とくに、複数の利用者でワークフローを作っていたり、管理画面・Webhookを外部から届く状態にしている場合、優先度が上がります。
影響が小さい: クラウド版のn8n Cloudを使っている場合は、提供元が管理・更新します。
影響しない: n8nを使っていない会社です。

情シスが今日やること

最新版へ更新する: n8nを2.44.1以降(2.x系)または1.123.85以降(1.x系)へ更新します(npmやDockerで)。n8n公式は「回避策は完全な修正ではない。更新が解決策」としています
公開範囲を確認する: n8nの管理画面やWebhookが、インターネットから直接届く状態になっていないかを確認します。リバースプロキシでの認証・IP制限、SSRF対策、Webhookのネットワーク制限を行います
権限を最小にする: 利用者のアカウントの権限を見直し、半信頼のメンバーに、安易にワークフローの作成・編集の権限を与えないようにします
認証情報を見直す: 認証情報が漏れうる問題に該当する運用では、念のため関連するサービスのパスワードやトークンを変更し、実行ログの閲覧権限を絞ります
記録を残す: 確認した版・公開範囲・権限、更新した版、対応日を資産台帳に残します

n8nのような自動化の基盤は、便利な一方で、多くのサービスの認証情報が1か所に集まります。今回のバッチは「外部から誰でも」ではなく「ログインできる内部者・設定ミス・公開しすぎ」が効く類です。更新とあわせて、公開範囲と権限の基本を、この機会に点検してください。

よくある質問

Qうちは使っていますか? 影響しますか?

An8nは、ノーコード/ローコードで業務の自動化(各種サービスの連携やデータ処理)を組めるツールで、無料で自前運用(セルフホスト)できます。情シスや「ひとり情シス」が入れていることがあります。自前で運用している場合、今回の10件の対象になりえます。ただし、いずれもn8nにログインできる内部の利用者が前提で、外部の第三者が認証なしで直接踏むものではありません。クラウド版(n8n Cloud)は提供元が管理します。

Qどう対応すればよいですか?

An8nを最新版へ更新するのが基本です。2.x系は2.44.1以降、1.x系は1.123.85以降で、今回の全件がカバーされます(エラーワークフローに関する1件は2.42.2/2.41.5でも修正)。あわせて、n8nの管理画面やWebhookをインターネットに直接公開せず、リバースプロキシでの認証やIP制限、SSRF対策を行います。アカウントの権限を最小にし、半信頼のメンバーに安易にワークフローの作成権限を与えないようにします。認証情報が漏れうる問題に該当する運用では、念のため関連するサービスの認証情報を変更し、実行ログの閲覧権限を絞ります。

Qすぐに危ないのですか?

A今回の10件は、Criticalがなく、認証なしで踏めるものもなく、悪用やPoCの公開も確認されていません。すぐに全員が危ない、という類ではありません。ただし、n8nは外部サービスの認証情報を多数持つため、内部の利用者による持ち出しや、設定ミスで管理画面を公開してしまうことのリスクは大きいです。更新と公開範囲の見直しを、落ち着いて進めてください。