n8n は、新しい版がとても頻繁に出ます。公式ドキュメントによると、マイナー版はほぼ毎週出ます。GitHub のリリース一覧を見ると、2026年10月はパッチ版もほぼ毎日公開されていました。脆弱性の公表も多く、2026年に公表されたセキュリティアドバイザリは、10月23日時点で211件ありました（GitHub で集計）。
セルフホストの n8n は、自分で更新しないと修正を受けられません。この記事では、安全に更新する手順と、1.x から 2.x へ移行するときに動かなくなるものを、手元で実際に試した結果で解説します。
結論
- 版は固定し、月に1回以上は更新する。 公式も、版の番号を固定することと、月に1回以上の更新を勧めています。
- 更新の前に、ボリュームを丸ごとバックアップする。 暗号鍵を含むため、これがあれば元の版に戻せます。
- 1.x から 2.x に上げる場合は、移行前のチェック機能だけに頼らない。 手元では、チェック機能が指摘しなかったワークフローも動かなくなりました。
2.x の中での更新手順
n8n を Docker でセルフホストする手順の構成を例にします。
1. バックアップを取る
構築の記事の手順4と同じ方法で、ボリュームを丸ごと固めます。
docker compose stop n8n
docker run --rm \
-v n8n_n8n_data:/data:ro \
-v "$PWD":/backup \
alpine:3.22 tar czf /backup/n8n_data-before-update.tar.gz -C /data .2. 版を書き換えて起動する
compose.yaml の image: の版を、新しい版に書き換えます。latest や stable のような名前ではなく、版の番号を書きます。名前で指定すると、意図しないときに版が変わるためです。
image: docker.n8n.io/n8nio/n8n:2.44.6docker compose pull n8n
docker compose up -d
docker compose logs n8n | grep Version手元では 2.44.5 から 2.44.6 に更新し、ログに Version: 2.44.6 と表示されること、公開済みの Webhook がそのまま動くことを確かめました。
新しい版は、GitHub のリリース一覧で確認できます。n8n@2.44.6 のように番号が付いたものが正式な版です。「Pre-release」と表示されているもの（ベータ版）は避けてください。
1.x から 2.x への移行
n8n 2.0 は 2025年12月に公開され、既定の動きが多く変わりました。データの保存先に MySQL や MariaDB を使っている場合は、2.0 では使えなくなったため、先に PostgreSQL か SQLite へ移す必要があります（この記事の検証は SQLite で行いました）。1.x 系にも修正が続いているため、まだ 1.x を使っている人もいるはずです。そこで、1.123.87 で4種類のワークフローを作り、2.44.6 に上げたらどうなるかを試しました。
結果：3つが動かなくなった
| ワークフロー | 1.123.87 | 2.44.6（既定のまま） | 移行前のチェック機能 |
|---|---|---|---|
Code ノードで環境変数（$env）を読む |
成功 | 失敗：access to env vars denied |
指摘なし |
| Execute Command でコマンドを実行する | 成功 | 失敗：Unrecognized node type |
指摘あり |
| サーバー上のファイルを読む | 成功 | 失敗：Access to the file is not allowed. |
指摘あり |
| Webhook で起動する（有効化済み） | 成功 | 成功 | — |
移行前のチェック機能とは、1.x の Settings → Migration Report です。2.0 で問題になる設定やワークフローを一覧にしてくれます。手元では「4つのうち2つは対応済み」と表示されました。しかし、実際には環境変数を読む Code ノードも動かなくなりました。Code ノードで $env を使っている場合は、チェック機能の結果にかかわらず確認が必要です。
それぞれの原因と対処
2.0 では、どれもセキュリティのために既定が変わったものです。
- 環境変数の読み取り：Code ノードなどから環境変数を読むことが、既定で禁止されました。値は、n8n の資格情報（Credentials）に移すのが安全です。どうしても元に戻すなら
N8N_BLOCK_ENV_ACCESS_IN_NODE=falseを設定します。 - Execute Command：このノードと Local File Trigger が、既定で無効になりました。サーバー上でコマンドを実行できるノードなので、本当に必要か見直してください。戻すなら
NODES_EXCLUDE=[]を設定します。 - ファイルの読み書き：ファイルを扱うノードが読み書きできる場所が、既定で
~/.n8n-filesに限られました。別の場所を使うなら、N8N_RESTRICT_FILE_ACCESS_TOにそのディレクトリを指定します（構築の記事の構成では/filesを指定済みです）。
手元では、3つの設定を加えると、3つのワークフローがすべて元どおり動きました。ただし、上の2つは 2.0 で意図して塞がれた機能です。戻す場合は、ワークフローを編集できる人を信頼できる人だけに限ってください。
戻し方
移行の前に取ったバックアップを戻し、image: の版を 1.123.87 に書き換えて起動すると、元の状態に戻りました。4つのワークフローと Webhook がすべて動くことを確かめています。復元のコマンドは、構築の記事の手順4と同じです。
脆弱性への備え
2026年は公表が非常に多い
GitHub で n8n のセキュリティアドバイザリを集計すると、2026年1月1日から10月23日に公表されたものは211件でした。深刻度の内訳は、Critical が19件、High が94件です。
特に影響が大きかったものを2つ挙げます。
- CVE-2026-21858（深刻度 Critical、CVSS 10.0）：Webhook の処理の不備により、特定のフォーム系のワークフローを公開している場合に、ログインしていない人がサーバー上のファイルを読める問題です。1.65.0 以降 1.121.0 未満が対象でした。
- CVE-2025-68613：2025年12月に公表された、ワークフローを編集できる人が式の評価を通じてサーバー上でコードを実行できる問題です。米国の CISA が、実際に悪用が確認された脆弱性の一覧（KEV）に 2026年3月11日に追加しました。
Critical の多くは、ワークフローを作成・編集できるユーザーがサーバー上でコードを実行できる、という種類のものです。一人で使っているなら、ログインしなくても使える入口が実害に直結しやすいと言えます。外に公開している Webhook やフォームの入口がそれに当たります。
日ごろやっておくこと
- リリースを購読する。
https://github.com/n8n-io/n8n/releases.atomを RSS リーダーに登録すると、新しい版を見逃しません。脆弱性の一覧は GitHub のセキュリティアドバイザリで確認できます。2026年のアドバイザリは、多くが修正版と同じ日に、2週間おきにまとめて公表されていました。公表された時点で修正版は出ているので、公表を見たらすぐに更新できるようにしておきます。 - 使っていない Webhook やフォームは止める。 外から呼べる入口を減らすほど、ログインなしで悪用される余地が減ります。
- 編集できるユーザーを絞る。 複数人で使う場合は、ワークフローを編集できる権限を信頼できる人だけに与えます。
今後の大きな変更：n8n 3.0
n8n は、3.0 での破壊的な変更をすでに公表しています（公開日は未定）。主なものは次のとおりです。
- セルフホストは Docker での運用が前提になる
- ファイルの保存先
~/.n8n/binaryDataの名前が~/.n8n/storageに変わる - Code ノードなどを動かす仕組み（タスクランナー）の制限時間の既定値が、300秒から60秒に短くなる
2.x の今の版でも、起動時のログに、タスクランナーの制限時間などについて「非推奨」の表示が出ています。1.x から更新して ~/.n8n/binaryData がある環境では、保存先の名前が変わることの警告も出ました。3.0 が出る前に、公式の変更点のページで自分の環境に関係するものを確認しておくと安心です。