n8nの脆弱性と対策｜CVE-2026-21858など重大な脆弱性の影響範囲と、自社の版の確かめ方

n8nの脆弱性のうち、影響が大きいのは、認証なしでサーバー上のファイルを読まれるCVE-2026-21858と、ワークフローを編集できる利用者が任意のコードを実行できる2件です。自社でn8nを動かしている場合は、版が1.123.17以上（2系なら2.5.2以上）になっていれば、この記事で挙げる3件はすべて修正済みです。それより古ければ修正版へ更新し、すぐに更新できない間は、編集権限の絞り込みとインターネットへの公開の停止で被害の入口を狭めます。

この記事の答え

• 3件とも、修正版への更新で直ります。1.123.17以上か2.5.2以上なら対象外です
• 1件目はフォームを公開している環境が、残り2件はワークフローを編集できる人がいる環境が狙われます
• 今日は版を確かめて更新し、担当・確認の頻度・検証環境は運用として決めます

2026年9月時点の情報です。記事内の版や数値は各報道の記載どおりに書いています。最新の情報は、n8nのGitHub上のセキュリティ情報（Security Advisories）でご確認ください。

n8nそのものの全体像は、中心の記事にまとめています。

関連記事：n8nとは？できること・料金・使い方と、業務自動化を本番で回す前に決めること

n8nの重大な脆弱性一覧｜CVE・CVSS・修正版

近年報じられた重大な脆弱性のうち、深刻度が高く、多くの環境に関係する3件を並べます。CVSSは脆弱性の深刻度を0〜10で表す共通の指標で、9.0以上が最も重い「クリティカル」に当たります。

1件目はThe Hacker NewsとSecurity NEXT、2件目はSecurity NEXT、3件目はiototsecnewsの報道にもとづきます。

認証なしで狙われるCVE-2026-21858

3件のうち最も急ぐのはCVE-2026-21858です。ログインしていない外部の人でも、公開されているフォームに向けて細工した通信を送るだけで攻撃を始められるためです。Cyeraの分析では、読み出したファイルからn8nのデータベースと暗号化キーを取り出し、管理者として入り込み、コマンドを実行するワークフローを作ってサーバーを乗っ取る流れが示されています。ファイルの読み取りから、最終的にはリモートコード実行（RCE）までつながります。

ワークフローを編集できる人が起点になる2件

CVE-2025-68613とCVE-2026-25049は、ワークフローを編集できるアカウントを持つ人が起点になります。社外の人がいきなり攻撃できるわけではありませんが、社員のアカウントが盗まれた場合や、外部の協力会社に編集権限を渡している場合は、そこから攻撃されます。n8nには外部サービスのパスワードやAPIキーが登録されているため、乗っ取られると、つないでいる会計ソフトやデータベースにも被害が広がりかねません。

影響を受けるのはどんな環境か

影響を受けるのは、主にセルフホストで古い版を動かしている環境です。条件を3つに分けると、自社がどれに当たるかを判断しやすくなります。

n8nをインターネットから直接開ける状態にしていると、1行目と2行目の条件が重なり、最も危ない組み合わせになります。一方、社内のネットワークからしか開けない環境でも、2件の脆弱性は社内のアカウントから悪用されうるため、更新が要らないわけではありません。

クラウド版を使っている場合

n8nの会社が運用するクラウド版では、本体の更新は事業者側が行います。利用者が自分で版を上げる作業は基本的に要りませんが、編集できる人の範囲を絞るのは利用者側の仕事です。表の2件目と3件目は編集権限を持つ人が起点になるため、使っていないアカウントの削除や、社外の人に渡した権限の見直しはクラウド版でも行います。

自社のn8nの版を確かめる方法

版は、画面か、サーバー上のコマンドのどちらかで確かめます。更新が終わったと思っていても、実際に動いている版が古いままのことがあるため、必ず動いているn8nから版を表示させます。

1. 画面で確かめるn8nにログインし、左下のヘルプのメニューから「About n8n」を開くと、版の番号が表示されます。
2. Dockerで動かしている場合サーバーで docker ps を実行してn8nのコンテナ名を確かめ、docker exec <コンテナ名> n8n --version を実行すると版の番号が出ます。
3. npmで入れている場合n8nを動かしているサーバーで n8n --version を実行します。

表示された番号を、上の表の「修正された版」と比べます。1系なら1.123.17以上、2系なら2.5.2以上であれば、表の3件はすべて修正済みです。1.121.0や1.122.0のように1件目と2件目だけが直っている版もあるため、3件分をまとめて確かめます。

修正版へのアップデート手順と確認

Docker Composeで動かしている一般的な環境を例に、更新の流れを示します。更新の前にバックアップを取り、更新の後に版と主なワークフローの動きを確かめる、という前後の作業を省かないことが大切です。

1. ワークフローとn8nのデータが入ったボリュームやデータベースを保存し、暗号化キーの控えがあるかも確かめます。
2. Docker Composeの設定ファイルで、n8nのイメージの版を修正版以上の番号に書き換えます。
3. docker compose pull で新しいイメージを取得し、docker compose up -d で起動し直します。
4. 画面の「About n8n」かコマンドで、動いているn8nの版が書き換えた番号になっているかを見ます。
5. 業務で使っているワークフローを手動で1回ずつ実行し、つないでいるサービスへの接続が切れていないかを確かめます。

構築のときの手順やボリュームの扱いは、セルフホストの記事で詳しく書いています。

関連記事：n8nセルフホストの手順｜Docker・Docker Composeでの構築と本番運用で決めること

すぐ更新できない場合の脆弱性対策

検証が間に合わない、止められない業務が動いているといった理由で、今日中に更新できないこともあります。その間は、攻撃の入口を狭める対策をかけます。どれも更新の代わりにはならず、更新までの時間を稼ぐためのものです。

公開しているWebhookとフォームを洗い出す

まず、社外から呼び出せるWebhookとフォームの一覧を作ります。n8nの画面で、フォームやWebhookを受け口にしているワークフローを探し、それぞれ誰が何のために使っているかを担当者に確かめます。取引先からデータを受け取るような、止めると業務が止まるものは残し、試しに作ったまま公開されているものは止めます。残すものは、送信元を限るか、リバースプロキシで認証を付けてから通します。

編集できる人を見直すときの注意点

見直しの対象は、社員だけでなく、構築を頼んだ外部の会社のアカウントも含みます。構築の後もアカウントが残っていることは珍しくありません。退職者や異動者のアカウント、共有で使っているアカウントも洗い出し、編集権限が要らない人は閲覧だけにするか削除します。

セルフホストで更新を止めない運用の決め方

今回の3件は、どれも修正版への更新で直りました。困るのは、修正版が出ていても誰も気付かず、古い版のまま動き続けることです。セルフホストで使うなら、更新を担当者の気付きに任せず、次の3つを運用として決めておきます。

1. 担当n8nの版を確かめて更新する人と、その人が休んだときに代わる人を名前で決めます。構築した人が退職すると、誰も触れないn8nが残ります。
2. 確認の頻度n8nのGitHubのセキュリティ情報を、週1回など決まった頻度で確かめます。深刻度がクリティカルのものが出たら、何日以内に更新するかの期限も決めておきます。
3. 検証環境本番と同じ版・同じワークフローを動かせる検証用の環境を用意し、更新はまずそこで試します。検証環境が無いと、更新で業務が止まるのを恐れて先送りが続きます。

たとえば、平日の担当を情シスの1人、代わりを同じ部署のもう1人とし、毎週月曜にセキュリティ情報を確かめる、クリティカルなものは3営業日以内に検証環境で試して本番に上げる、と決めて文書にしておけば、担当が替わっても同じ手順で回せます。

現場の人が作ったワークフローが増えてくると、誰が何を動かしているかを管理する仕組みも要ります。

関連記事：現場が作ったAIエージェントを誰が管理するか｜野良AIを増やさない申請・棚卸し・停止の基準

n8nは使って大丈夫か｜導入を判断するときに見る点

脆弱性が続けて報じられると、n8nを使い続けてよいのか迷うかもしれません。判断の分かれ目は、脆弱性の有無ではなく、見つかったときに自社で直せるかどうかです。広く使われているソフトほど調べる人が多く、脆弱性も見つかりやすくなります。n8nの3件も、修正版が出てから報道されています。

導入や継続を判断するときは、次の点を確かめます。

自社で運用する人を置けない場合は、本体の更新を事業者が担うクラウド版のほうが向いています。一方、データを社外に出せない事情があってセルフホストを選ぶなら、担当・確認の頻度・検証環境を決めることが導入の条件になります。

社内でツールの利用を審査するときの項目は、次の記事で整理しています。

関連記事：生成AIのセキュリティ審査｜情シスが確認する12項目と申請・稟議の書き方

判断フロー｜自社が今日やること

使い方と版の判定を、自社のn8nに当てはめる順に並べると次のようになります。上から順に答えれば、今日やることが1つに決まります。

まとめ：n8nの脆弱性対策は、版の確認と更新を運用に組み込む

• n8nの重大な脆弱性3件は、どれも修正版への更新で直り、1.123.17以上か2.5.2以上なら対象外です
• CVE-2026-21858は認証なしで狙われるため、フォームを社外に公開している環境は最優先で更新します
• 版は画面の「About n8n」か、n8n --version で、実際に動いているn8nから確かめます
• すぐ更新できない間は、編集権限を絞り、インターネットへの公開を止め、フォームとWebhookを絞ります
• セルフホストで使うなら、担当・確認の頻度・検証環境を決め、更新が止まらない形にしておきます

Augueでは、n8nを使った業務の自動化について、構築から、更新の担当や権限の決め方といった運用の設計までを支援しています。ご興味がある方は是非ご相談ください。

よくある質問

脆弱性を突かれたかどうかは、どうやって調べればよいですか？

まず、覚えのないワークフローや利用者が増えていないかを画面で確かめます。次に、実行の記録に、社内で作っていないワークフローの実行や、コマンドを実行するノードの利用が残っていないかを見ます。サーバー側では、n8nを入れた前後の不審な通信やファイルの変更を、リバースプロキシやサーバーの記録で追います。疑わしい跡があれば、n8nに登録した外部サービスのパスワードやAPIキーを作り直し、専門の事業者に調査を頼むことも検討します。

更新作業には、どれくらいの時間と人手がかかりますか？

一律の時間は出せません。Docker Composeで動かしていて、手順が文書になっていれば、1人で短時間に終わることが多い一方、手順が無い環境では、どこに何が入っているかを調べる時間のほうが長くかかります。見積もるときは、バックアップ、検証環境での動作確認、本番の更新、更新後の確認の4つに分けて、担当者に作業の時間を出してもらうと、止める時間帯も決めやすくなります。

1系から2系へ上げるときに気を付けることはありますか？

大きな版をまたぐ更新では、設定の項目や一部のノードの動きが変わることがあります。いきなり本番を上げず、n8nの公式ドキュメントで2系への移行の注意点を読み、検証環境で主なワークフローを一通り動かしてから本番に移します。すぐに2系へ移れない場合は、1系の中で修正の入った版まで上げて、脆弱性への対応と大きな移行を分けて進める方法もあります。

セキュリティ審査で、n8nの利用をどう説明すればよいですか？

「脆弱性が無いこと」ではなく、「見つかったときに、決めた期限の中で直せる体制があること」を説明します。具体的には、使っている版、公開している入口の一覧、編集できる人の一覧、更新の担当と確認の頻度、バックアップの取り方の5点を書面にまとめます。クラウド版を使う場合は、データの保管場所や認証の方式など、事業者側の情報も合わせて添えます。

関連する記事

n8n料金プランの比較｜クラウド版・セルフホストの費用と無料の範囲n8n料金プランは、クラウド版が年払いで月20ユーロのStarterから、セルフホストの無料版は0円です。4つの有償プランの実行回数と機能、無料の範囲、実行回数の見積もり方、セルフホストの手間を比べて解説します。AIエージェント導入前の確認項目｜発注先を決める前に自社で固める7点と、撤退ラインの引き方AIエージェントの導入で、発注先を探す前に自社で決めておく7点を順番に整理します。対象業務の絞り方、読ませてよいデータ、書き込み権限、担当部署、費用の枠、測る指標、撤退ラインの引き方を示します。