n8n の式評価でリモートコード実行（認証済みユーザー・悪用確認済み）

High（CVSS 8.8）に分類されるn8n n8nの脆弱性です。ワークフロー自動化基盤 n8n の式評価（expression evaluation）の実装に、実行コンテキストが下層のランタイムから十分に隔離されていない条件があり、認証済みのユーザーがワークフロー設定時に渡した式から n8n プロセスの権限で任意コードを実行できる。advisory は、成功すると当該インスタンスの完全な侵害、すなわち機密データへの不正アクセス、ワークフローの改変、システムレベルの操作の実行に至り得ると記述している。影響するのは 0.211.0 以降 1.120.4 未満のすべての版と、1.121.0、そして 1.122.0 未満の 1.121 系で、修正版は 1.120.4、1.121.1、1.122.0 の3系列で提供されている。修正では式評価を制限する追加の安全策が導入されたとされる。CVSS は評価元で割れており、NVD（Primary）は 8.8 High（CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H）、CNA の GitHub は 9.9 Critical（CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H）で、差はスコープ変更の見方（S:U か S:C）だけである。CISA KEV には 2026-03-11 に収載され、是正期限は 2026-03-25、ランサムウェア利用は Unknown。NVD の vulnStatus は Analyzed。参照には n8n を狙うボットネット型マルウェアに関する第三者の調査記事が含まれており、実際に狙われている製品であることが裏付けられている。

判定はバージョン確認から始める。docker で動かしていればイメージタグではなく n8n --version か UI の Settings の表示で実際の版を確認し、0.211.0 以上で 1.120.4 / 1.121.1 / 1.122.0 のいずれの修正版にも達していなければ該当する。見落としやすいのは、業務チームが自分で立てた小さな n8n、docker compose のままアップデートしていないもの、そしてリバースプロキシ配下で社内公開しているだけの環境である。前提として認証済みユーザーが必要なので、まず誰がワークフローを作成・編集できるかを棚卸しし、招待やパブリック登録が開いたままになっていないかを確認する。すぐ更新できない場合の緩和策は advisory に明示されており、ワークフローの作成と編集の権限を完全に信頼できるユーザーだけに絞ること、そして OS 権限とネットワークアクセスを制限した堅牢な環境に n8n を配置して侵害時の影響を小さくすることの二つである。ただし advisory 自身がこれらはリスクを完全には排除せず短期の措置としてのみ使うべきと述べているので、更新の代替にはならない。完了条件は、（1）全インスタンスが 1.120.4 / 1.121.1 / 1.122.0 以上になっていること、（2）ワークフロー編集権限を持つアカウントの一覧が意図どおりであること、の2点である。KEV 収載済みで実際に悪用されているため、更新後も痕跡確認が必要になる。n8n は各種 SaaS の資格情報を保管する性質上、被害時の損失が大きい。保存済みクレデンシャルはすべて再発行し、意図しないワークフローや実行履歴（見慣れない Execute Command / Code ノードの追加）、コンテナ内の不審なプロセスと外向き通信を確認する。是正期限 2026-03-25 は既に経過しているため、未更新のインスタンスがあれば期限超過として扱う。

n8n n8n を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2025-68613）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。

はい。CISA の既知の悪用された脆弱性カタログ（KEV）に登録されており、実環境での悪用が確認されています。米国連邦機関向けの対応期限の目安は 2026/03/25 です。推奨される対応: ベンダーの指示に従って緩和策を適用し、クラウドサービスについては該当する BOD 22-01 のガイダンスに従うこと。緩和策が無い場合は当該製品の使用を停止すること。