n8n の式評価にサンドボックス脱出、ワークフローを編集できる利用者がホストでOSコマンドを実行（2.31.5 / 2.32.1 で修正）

Critical（CVSS 9.9）に分類されるn8n n8n（自己ホスト型のワークフロー自動化ツール）。NVD の記述では 2.31.5 より前、および 2.32.1 より前が影響を受け、2.31.5 と 2.32.1 で修正されている。n8n Cloud ではなく、自分で立てている n8n が対象になる。の脆弱性です。n8n の式（expression）評価にサンドボックス脱出の欠陥がある。NVD の記述はこうである。「n8n の 2.31.5 より前、および 2.32.1 より前には、式評価にサンドボックス脱出の脆弱性が含まれる。ワークフローを作成または変更する権限を持つ認証済み利用者が、アロー関数の本体を使った式を細工することで式のサンドボックスを回避し、n8n を実行しているホスト上でシステムコマンドの実行を引き起こせる。この問題はバージョン 2.31.5 および 2.32.1 で修正されている」。 **何が破られているのかを一段だけ噛み砕く。**n8n のワークフローでは、ノードのパラメータに `{{ ... }}` の形で JavaScript の式を書ける。この式は本来サンドボックスの中で評価され、ファイルやプロセスに触れる能力は与えられていない。今回の欠陥は、**アロー関数の本体（arrow-function body）として書いた式が、そのサンドボックスの外へ抜けられる**というものである。抜けた先はホストの Node.js プロセスなので、そこから先はシステムコマンドの実行に届く。 **「認証が要る」を安全側に読み違えないこと。**CVSS のベクタは PR:L（低い権限が必要）で、必要なのは「ワークフローを作成または変更できるアカウント」である。ところが n8n の運用では、**ワークフローを編集できることは管理者権限ではなく、ふつうの業務権限**として配られている。自動化の設定を各チームに任せている組織では、編集者はしばしば十数人から数十人になる。つまりこの欠陥は「管理者しか触れない」類ではなく、**ワークフローを1本書ける全員がホストでコマンドを実行できる**という意味になる。 **スコープが変わる（S:C）点も重い。**サンドボックスという境界を越えて、その外側のホストへ影響が及ぶため、CVSS はスコープ変更ありと評価している。9.9 という値の大半はここから来ている。n8n は各種 SaaS の認証情報を保管して外部サービスへ接続するための道具なので、**ホストでのコマンド実行はそのまま保管された資格情報と接続先への到達可能性**を意味する。n8n 単体の被害では終わらない構造である。 **ベンダー側の記録との対応関係について。**n8n の GitHub セキュリティアドバイザリ GHSA-gv7g-jm28-cr3m は、影響版（2.32.0 以上 2.32.1 未満、および 2.31.5 未満）・修正版（2.31.5 / 2.32.1）・原因（アロー関数の本体による式サンドボックスの回避）が本 CVE の NVD 記述と一致する。ただし**同アドバイザリのページには CVE 番号が記載されていない**（2026-09-02 時点で「No known CVE」と表示される）。同一のものとして扱うのが自然だが、ここでは断定せず、両者の記載内容が一致していることだけを事実として記す。なお同アドバイザリの評価は CVSS 4.0 で 8.7（High）であり、NVD の CVSS 3.1 9.9（Critical）とは版も値も異なる。**版の違う指標を比較しないこと。**

対応は **n8n の更新**である。2.31 系を使っているなら **2.31.5** へ、2.32 系なら **2.32.1** へ上げる。どちらの系統に乗っているかで上げ先が違う点に注意する。 **まず、自分のところが対象かを確定させる。**対象は**自己ホストの n8n** である。Docker で立てているならイメージのタグを、npm で入れているなら `n8n --version` を確認する。マネージドの n8n Cloud を使っている場合は、更新はベンダー側の作業になる。 **更新できるまでのあいだの手当ては、編集権限を絞ることである。**この欠陥は「ワークフローを作成・変更できる」ことが成立条件なので、**その権限を持つアカウントを減らせば、成立しうる経路がそのぶん減る**。棚卸しの観点は3つある。①退職者・異動者のアカウントが編集権限のまま残っていないか。②検証用や共有アカウントが編集権限を持っていないか。③外部の協力者に一時的に渡した権限が閉じているか。これは緩和であって修正ではないが、更新までの時間を稼ぐという意味では効く。 **インターネットへ出しているなら、その必要性を再検討する。**n8n の管理画面を公開したまま運用している例は多い。ベクタは AV:N（ネットワーク）で、認証は要るが**認証情報が漏れた瞬間にホストでのコマンド実行まで直結する**構造になっている。VPN の内側へ入れる、あるいは IP 制限を掛けるだけで、必要な前提条件が1段増える。 **侵害の有無を見るなら、n8n プロセスの子プロセスを見る。**式の評価からシステムコマンドが起動されるので、n8n のプロセスから想定外の子プロセス（シェル、`curl`、`wget`、パッケージマネージャ等）が生えていないかが手掛かりになる。あわせて、身に覚えのないワークフローの作成・更新がないかを監査ログで確認する。**更新した後も、更新前に既に踏まれていた可能性は消えない**ので、`N8N_ENCRYPTION_KEY` と n8n に保管している各サービスの資格情報については、侵害の疑いがある場合は再発行を検討する。

n8n n8n（自己ホスト型のワークフロー自動化ツール）。NVD の記述では 2.31.5 より前、および 2.32.1 より前が影響を受け、2.31.5 と 2.32.1 で修正されている。n8n Cloud ではなく、自分で立てている n8n が対象になる。 を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-72765）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。