n8n の Supabase ノードで PostgREST フィルタインジェクション、1行のはずの操作が全行に及ぶ（CVSS 9.8）

Critical（CVSS 9.8）に分類されるn8n n8n（ワークフロー自動化ツール・npm パッケージ `n8n`）の Supabase ノード。対象は Row の Get Many / Delete / Update 操作。の脆弱性です。**壊れ方の形が特徴的である。「1行を取る／消す／書き換える」つもりの操作が、条件ごと広げられて全行に及ぶ。** NVD の記述はこうである。「n8n の 1.123.69 未満、2.33.4 未満、2.34.1 未満には、Supabase ノードの **Row の Get Many / Delete / Update 操作**における PostgREST フィルタインジェクションの脆弱性がある。これらは**式でバインド可能な値をエスケープせずに連結して**フィルタクエリを組み立てていた。攻撃者は**すべての行に一致するようフィルタを広げる条件を注入**でき、**1行を対象とするはずの操作を、テーブル全体の開示・削除・変更に変えられる**」。 **Delete が含まれている点が重い。**開示（読み取り）だけなら情報漏えいだが、Delete と Update が同じ経路に乗っているので、**データが消える／書き換わる**。ワークフロー自動化ツールは定期実行されるものなので、気づかないうちに繰り返される可能性がある。 **評価は割れているが、Primary は Critical である。** | 評価元 | CVSS | 判定 | |---|---|---| | **NVD (nvd@nist.gov・Primary)** | **9.8** | Critical（CVSS 3.1 / AV:N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H）| | VulnCheck (disclosure@vulncheck.com・Secondary) | 7.1 | CVSS 4.0 / AV:N / AC:L / **AT:P** / PR:N / UI:N / VC:N / VI:N / VA:N / **SC:H / SI:H / SA:H** | | n8n（GitHub Security Advisory）| — | **High** と分類 | **Secondary 評価が下がっているのには理由がある。**CVSS 4.0 の評価は、影響を**当該システム（VC/VI/VA）ではなく後続システム（SC/SI/SA）**に置いている。壊れるのは n8n 自身ではなく**その先の Supabase のデータ**だ、という見方である。加えて AT:P（攻撃の前提条件あり）が付いている。**「式でバインド可能な値」に攻撃者の入力が流れ込むワークフローになっている必要がある**ためだろう。本サイトは Primary 評価の 9.8 を採るが、**自組織で該当するかは、この前提条件の有無で決まる**。 **該当するかどうかの見分け方はここである。**Supabase ノードの Get Many / Delete / Update のフィルタ値に、**外部から来たデータ（Webhook のボディ、フォーム入力、受信メール、外部 API の応答）を式で流し込んでいるか**。ワークフロー内の固定値だけを使っているなら、注入する経路が無い。 **公開は 2026-08-20、NVD の最終更新は 2026-09-01、状態は Analyzed である。**n8n の GitHub Security Advisory（GHSA-f4f3-2g67-4vhm）は 2026-08-05 に公開されている。**CISA KEV には 2026-09-11 時点で収載されていない。**

**修正版へ更新する。**n8n の Security Advisory が明示している修正版は次の3つで、系列ごとに分かれている。 | 系列 | 対象 | 修正版 | |---|---|---| | 1.x | 1.123.69 未満 | **1.123.69 以降** | | 2.33.x | 2.33.4 未満 | **2.33.4 以降** | | 2.34.x | 2.34.1 未満（2.34.0）| **2.34.1 以降** | **自分が使っている系列の修正版を選ぶこと。**2.33.x を使っているなら 2.33.4、2.34.0 なら 2.34.1 である。系列をまたぐアップグレードは別の互換性の検討が要るので、**同じ系列の修正版へ上げるのが最短**である。 **すぐに更新できない場合の緩和として、Advisory は n8n インスタンスへのアクセスを完全に信頼できる利用者に限定することを挙げている。**これはワークフローを編集できる人を絞る話であって、**外部入力がフィルタ値に流れ込む経路そのものは塞がらない**。あわせて次を確認する。 - **Supabase ノードの Get Many / Delete / Update を使っているワークフローを洗い出す**。使っていなければこの CVE の対象外である - そのフィルタ値に**式（`{{ }}`）で外部データを入れていないか**。入れているなら、更新までそのワークフローを止めるのが確実である - どうしても動かし続ける必要があるなら、**Supabase 側のロール権限を絞る**。読み取り専用のロールで動くワークフローなら、Delete と Update の被害は成立しない。Row Level Security を有効にしていれば、広げられたフィルタでも到達範囲は制限される **更新後は、被害が起きていないかをデータ側で見る。**注入が成功しても n8n のログには「ワークフローが正常終了した」としか残らない可能性がある。見るべきは n8n ではなく Supabase 側である。 - **想定より多い行が返っている／消えている／更新されている実行履歴**。1行のはずの操作の実行時間や返却件数が急に伸びた回を探す - **Supabase（PostgreSQL）側のログ**で、該当テーブルに対する広い範囲の DELETE / UPDATE - バックアップとの**行数の突き合わせ** **n8n はセルフホストで動かしている例が多い。**コンテナで動かしている場合、イメージのタグを修正版へ固定し直し、`latest` 依存になっていないかを確認すること。

n8n n8n（ワークフロー自動化ツール・npm パッケージ `n8n`）の Supabase ノード。対象は Row の Get Many / Delete / Update 操作。 を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://github.com/n8n-io/n8n/security/advisories/GHSA-f4f3-2g67-4vhm）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。