n8n の MongoDB ノードに NoSQL インジェクション、コレクション全件の漏洩と全削除が起きうる（CVSS 9.8）

Critical（CVSS 9.8）に分類されるn8n n8n（ワークフロー自動化。自ホスト版・n8n Cloud とも同一コードベース）。NVD の該当範囲は 1.123.69 未満、2.33.0 以上 2.33.4 未満、および 2.34.0。修正版は 1.123.69 / 2.33.4 / 2.34.1の脆弱性です。n8n の **MongoDB ノード**の Find / Delete / Aggregate 操作に NoSQL インジェクションがある。NVD の記述によれば、これらの操作は Query パラメータを**式解決のあとに JSON として解析する**が、その際に **MongoDB の演算子を無害化していない**。したがって解決後のクエリに influence できる攻撃者は、`$ne` や `$where` といった演算子を注入できる。 **影響は「1件取得するつもりだった検索が、コレクション全件の開示に変わる」という形で出る。** NVD が挙げているのは (1) コレクション全件の開示、(2) コレクション全件の削除、(3) データベースサーバ上でのその他の操作である。Delete 操作に対して `$ne` を注入すると「指定した値と等しくないすべての文書」＝実質すべてが削除対象になる。`$where` は JavaScript 式を渡す演算子なので、データベースサーバ側での評価に踏み込める。 **CVSS 3.1 基本値は 9.8**（AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）で、事前の権限も利用者操作も不要という評価である。NVD が Primary として付けた値で、CVSS 4.0 の評価は 2026-09-12 時点では付いていない。 **攻撃の入り口は「外部から制御できるデータをクエリに流し込んでいるワークフロー」である。** n8n の典型的な使い方は、Webhook ノードで受けた値・フォームの入力・受信メールの中身・API の応答といった外部由来の値を、式（`{{ }}`）で後段のノードのパラメータに差し込むものである。MongoDB ノードの Query に外部由来の値を差し込んでいる場合、**そのワークフロー自体が公開エンドポイントになっていなくても、入力経路が外部にあるなら影響を受ける**。逆に、Query が固定文字列または内部で生成した値だけで構成されているワークフローは、この経路では攻撃できない。 一次情報はベンダーの GitHub Security Advisory **GHSA-953p-jm2c-8h5j** で、NVD は Mitigation / Vendor Advisory としてこれを参照している。**KEV には 2026-09-12 時点で収載されていない**（CISA KEV カタログ 2026.09.11 で確認）。

**修正版へ上げることが恒久対応である。** NVD の該当範囲から読める修正版は **1.123.69 以降（1.x 系）／2.33.4 以降（2.33 系）／2.34.1 以降（2.34 系）**。自分の系列に対応する版を選ぶこと。2.34.0 を使っている場合は 2.34.1 へ、2.33.x を使っている場合は 2.33.4 へ上げる。1.x 系を使い続ける構成でも 1.123.69 で塞がるので、メジャーアップグレードは必須ではない。 **上げる前に、影響範囲を自分のワークフローで確認する。** 見るべきは「MongoDB ノードを使っているワークフローがあるか」「そのノードの Query パラメータに式（`{{ }}`）が入っているか」「その式が参照している値の出どころが外部か」の3点である。n8n の UI からワークフロー一覧を検索するより、**ワークフロー定義をエクスポートして機械的に探すほうが取りこぼしが少ない**。自ホスト版なら、n8n のデータベース（既定は SQLite、本番では PostgreSQL が多い）の `workflow_entity` テーブルの `nodes` 列に JSON が入っているので、`mongoDb` というノード型と `Query` の値を突き合わせればよい。 **すぐに上げられない場合の暫定策は、外部由来の値をクエリから外すことである。** Query に直接式を差し込む代わりに、前段に Code ノードを1つ置き、外部由来の値を文字列として検証してから渡す形に変える。具体的には「`$` で始まるキーを拒否する」「値の型を文字列に固定する」の2つで、`$ne` / `$where` の注入経路はふさがる。**WAF での入口対策は当てにしない。** 注入は JSON の構造に入るので、URL パターンでは弾きにくい。 **更新後は漏洩と削除の両方を見る。** 未認証で全件開示まで届く欠陥なので、更新するだけでは済まない。MongoDB 側の監査ログ・プロファイラで、想定より件数の多い find、`$where` を含むクエリ、対象条件の広い delete が無いかを確認する。コレクションの文書数が想定より減っていないかも数えること。n8n 側では実行履歴（executions）で、MongoDB ノードの出力件数が不自然に多い実行が無いかを見る。 **n8n Cloud を使っている場合は、版の管理はベンダー側にある。** ただし「自分のワークフローが MongoDB ノードに外部由来の値を渡しているか」の確認は利用者側の仕事なので、上に書いた点検は自ホストと同じく必要である。

n8n n8n（ワークフロー自動化。自ホスト版・n8n Cloud とも同一コードベース）。NVD の該当範囲は 1.123.69 未満、2.33.0 以上 2.33.4 未満、および 2.34.0。修正版は 1.123.69 / 2.33.4 / 2.34.1 を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-77070）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。