n8nに脆弱性34件 認証情報の窃取が可能

ワークフロー自動化基盤「n8n」で、2026年8月だけで34件の脆弱性が公表されました。目立つのは、ワークフローを編集できる一般ユーザー権限から、共有された認証情報を盗み出したり、n8nが動いているサーバ上でOSコマンドを実行できてしまうものです。自前でホストしているなら、最新版への更新と「誰にワークフロー編集権限を渡しているか」の棚卸しが急務です。

この記事でわかること:

  • n8nとは何か、なぜ「うちは使っていない」と言い切れないのか
  • 2026年8月に出た2つの修正バッチと、修正済みバージョン
  • 特に重い脆弱性の中身（アカウント乗っ取り・コマンド実行・認証情報の窃取）
  • 公式CLI n8n audit を使った自社インスタンスの点検手順

n8nとは何か（「うちには無い」と即断する前に）

n8nとは、各種SaaS・データベース・APIを画面上でつないで業務処理を自動化する、オープンソースのワークフロー自動化プラットフォームです。Zapier や Power Automate のような処理を、自社サーバやクラウドVM上で動かせる点が特徴です。

使うのは主に情報システム部門や業務部門で、「問い合わせメールをTeamsに転送する」「基幹DBから抽出してレポートを送る」といった定型処理を、コードをほとんど書かずに組み立てます。近年はLLMノード・AIエージェント機能・MCP対応が加わり、「社内AI自動化基盤」として試験導入されるケースが増えています。

問題は置かれ方です。n8nの公式ドキュメントは提供形態を「n8n Cloud（ベンダーが運用・更新まで面倒を見る）」と「セルフホスト（インフラも保守も利用者の責任）」に分けています。セルフホストの導入手順としてワンライナーの導入スクリプト、Docker Compose、主要クラウド各社への配置などが案内されており、ライセンスキーを入れなければ無償のCommunity editionとして動きます。

つまり「担当者がクラウドVMにDockerで立てて、そのまま定着した」という形で社内に存在しやすいソフトです。無償で始められるため稟議も購買も通らず、資産管理台帳に載りません。以下で該当有無を確認できます。

  • Docker運用なら docker ps --format "{{.Image}}" の出力に n8nio/n8n を含む行がないか
  • npm導入なら npm ls -g n8n
  • n8n Cloud（マネージド）を使っている場合、更新はn8n側が行います

何が起きたのか：2026年8月に2つの大きな修正バッチ

NVD（米国の脆弱性データベース）で2026年8月公表分を検索すると、n8n本体の脆弱性が34件ヒットします。内訳は8月11日公表の16件、8月18日公表の1件、8月20日公表の17件です。16件と17件は、それぞれ一括でリリースされた修正バッチに対応しています。

公表日 件数 修正済みバージョン
2026年8月11日 16件 1.123.67 / 2.31.5 / 2.32.1
2026年8月20日 17件 1.123.69 / 2.33.4 / 2.34.1

脆弱性ごとに影響するバージョン範囲は微妙に異なり（1.x系のみ、あるいは2.x系のみ、というものもあります）、個別に突き合わせるのは現実的ではありません。素直に最新の安定版へ上げるのが確実です。本稿執筆時点で、npmレジストリ上の latest は 2.36.9 です。8月の修正版（2.34.1）でさえ、すでに数リリース分の後追いが発生しています。

更新頻度はどれくらいか

8月だけで大きな修正バッチが2回。おおむね月2回のペースでセキュリティリリースが出ている計算になります。四半期に一度まとめてパッチを当てる運用では追いつきません。

特に重い脆弱性

CVSSはNVDが付与した基本値です。評価基準のバージョン（v3.1／v4.0）が混在しているため、併記しています。

CVE 対象 内容 CVSS
CVE-2026-72772 埋め込みログイン（Token Exchange Embed Login） 署名が有効なトークンをメールアドレスで既存アカウントに突き合わせる際、そのメールが検証済みかを確認していなかった。トークンを入手できれば任意の既存ユーザーになりすまし可能。埋め込みログインが有効で信頼鍵が設定されたインスタンスのみ該当 8.9 (v4.0)
CVE-2026-72750 Snowflakeノード Execute Query 式の値をSQL文字列に直接埋め込むためSQLインジェクションが成立。修正では値をプレースホルダーでバインドする「Query Parameters」欄が追加された 8.8 (v3.1)
CVE-2026-72765 式（Expression）の評価 アロー関数の本体を使ってサンドボックスを脱出し、n8nが動いているホスト上でシステムコマンドを実行。ワークフローの作成・変更権限があれば足りる 8.7 (v4.0)
CVE-2026-72767 Gitノード 認証済みユーザーによるリモートコード実行 8.7 (v4.0)
CVE-2026-77068 MCP用ノードスキーマ読み込み（@n8n/workflow-sdk） ノードタイプ文字列からモジュールパスを組み立てる際にパストラバーサルを検証しておらず、global:member 権限のユーザーがn8nメインプロセス上でコードを実行できる 8.7 (v4.0)
CVE-2026-77080 Snowflakeノード Execute Queryの入力をクライアント側コマンドごとSnowflake SDKに素通しするため、n8nホスト上のファイルを読み出し・上書きできる 8.7 (v4.0)
CVE-2026-77072 Formノードの完了ページ 格納型XSS。公開フォームを送信した訪問者のセッションで、n8nオリジンのスクリプトが実行される 8.4 (v4.0)
CVE-2026-72766 Send Emailノード 本文フィールドが文字列であることを強制しておらず、細工した非文字列値をメールライブラリ（Nodemailer）がファイルパスやURLと解釈。任意のローカルファイル読み取りとSSRFに至る 7.5 (v3.1)

この中でCVE-2026-72766だけは認証が不要です。ただし成立には「無認証Webhookを持つ稼働中のワークフローが既にある」「そのノードに有効なSMTP認証情報が設定されている」「信頼できない入力が本文欄に直接マッピングされている」という3条件が揃う必要があり、既定の構成ではありません。逆に言えば、公開Webhookで受けた値をそのままメール本文へ流し込むワークフローを組んでいる組織は、真っ先に確認すべきということです。

なぜ「ワークフローを編集できる人」が危ないのか

今回の一群を並べて見えてくるのは、個々のバグよりも権限境界そのものが繰り返し破られているという構図です。

n8nには認証情報（クレデンシャル）の共有機能があり、公式ドキュメントは「共有された認証情報を使うユーザーは、その中身を閲覧・編集できない」と説明しています。「使わせるが中身は見せない」という設計です。ところが8月の修正には、この境界を回れてしまうものが少なくとも3件含まれていました。

  • CVE-2026-72763（7.2 / v4.0）：Execute Sub-workflowノードのインラインJSON内で参照された認証情報が、権限検証の対象外だった。共有ワークフローの編集権限を持つメンバーが対象の認証情報IDを知っていれば、保存時・実行時の検証をすり抜けてアクセスを許されていない認証情報を使用・持ち出しできる
  • CVE-2026-72774（7.1 / v4.0）：HTTP Requestノードで認証タイプを「式」で指定すると、実行前の権限チェックが展開前の式と比較してしまい、所有者確認が飛ぶ。結果、他人の認証情報が実行時に読み込まれる
  • CVE-2026-72771（6.5 / v3.1）：複数のAI／LLMノードで、ユーザー指定のベースURL・エンドポイントURLが設定されていると「Allowed HTTP Request Domains（許可HTTPリクエストドメイン）」の制限が効かない。攻撃者が用意したホストへリクエストを飛ばして、認証情報の秘密を抜き出せる

実務上の結論はシンプルです。n8nのワークフロー編集権限は「管理者相当」とみなして運用してください。「編集はできるが認証情報は見られないから安全」という前提は、少なくとも今回の一群では成立していません。

現場目線の課題

この手の自動化基盤で厄介なのは、情シス自身が「自分のための道具」として立てていることが多い点です。棚卸しの視線は普通「業務部門が使っているシステム」に向きます。自分たちが検証用に立てたコンテナは、その視界にまず入りません。PoCのつもりで動かし始めたものが、いつの間にか日次バッチの本番系になっている——という展開に心当たりのある方は多いはずです。

もう一つが認証情報の集積です。n8nは各種SaaS・DB・APIをつなぐ道具なので、使い込むほど社内のAPIキーとパスワードが1か所に集まっていきます。実質的に「社内のパスワード金庫」になっているのに、金庫として設計・運用されていない。今回のように認証情報の権限チェックを回避する脆弱性が続くと、被害範囲はn8n単体では収まりません。

そして更新頻度です。月2回のセキュリティリリースに追随するには、Dockerタグをバージョン固定にして計画的に上げるか、少なくとも「新バージョンが出たことに気づく」仕組みが要ります。latest タグの放置は再現性を失う一方で、固定したまま忘れれば今度は取り残される。どちらも運用でしか埋まらない部分で、限られた人員のなかでここに手を回し続けるのは、正直なところ簡単ではありません。

情シスはどうすべきか

まず何から手を付けるべきか

自社インスタンスの有無と版数を確認し、最新の安定版へ更新したうえで、公式の点検コマンドを一度回すこと——この3つが出発点です。

n8nには公式のセキュリティ監査機能があり、CLIで n8n audit、公開APIの /audit エンドポイント（インスタンスオーナーとして認証）、あるいはn8nノードの Resource > Audit / Operation > Generate のいずれかで実行できます。レポートは5種類出ますが、今回の文脈で効くのは次の項目です。

  • Instance：保護されていないWebhookの一覧、インスタンスが古い場合の指摘、不足しているセキュリティ設定
  • Database：SQLノードのExecute Query欄で式が使われている箇所（まさにCVE-2026-72750が突いた実装パターン）、Query Parameters欄が未使用の箇所
  • Nodes：ホスト上で任意のコードを取得・実行できる「公式のリスクが高いノード」、コミュニティノード、カスタムノード
  • Credentials：ワークフローで使われていない／稼働中のワークフローで使われていない認証情報（＝消し忘れの棚卸し）

設定面では、公式ドキュメントの「What you can do」が自己ホスト向けの推奨をまとめています。特に次の2点は、効果が大きい割に見落とされがちです。

  • SSRF保護の有効化：N8N_SSRF_PROTECTION_ENABLED=true（n8n 2.12.0以降）。ユーザーが操作できるノードからの外向きHTTPリクエストを検証し、RFC1918のプライベートアドレス、ループバック、リンクローカル（クラウドのメタデータエンドポイントを含む）などを既定でブロックします。リダイレクト先とDNS解決も検証対象です。ただし公式も明記しているとおりこれは多層防御の一枚であり、主防御はファイアウォールなどネットワーク側です
  • 危険なノードの無効化：Codeノードからの外部モジュール読み込みを禁止し、Execute CommandやSSHのようなノードを環境変数でブロックする

あわせて、TLS終端のリバースプロキシを置く、保存データを暗号化する、コミュニティノード導入時のリスクを理解する（または無効化する）ことが推奨されています。

組織的な対策としては、IPAの公的資料が土台になります。自動化基盤に限らず「誰がどのシステムに何の権限を持っているか」を定期的に洗い直す話なので、中小企業の情報セキュリティ対策ガイドライン（IPA）の資産管理・アカウント管理の項が使えます。利用者側の啓発には対策のしおり（IPA）が手軽です。「便利だから部内で立てた」を頭ごなしに禁止するより、立てるなら台帳に載せて更新責任者を決めるという着地に持っていくほうが、現実には機能します。

中長期の視点

これはn8nに限った話ではありません。AIエージェント基盤やローコード自動化ツールは、「外部サービスの認証情報を大量に預かり」「ユーザーが書いた式やコードを評価し」「任意のHTTPリクエストを飛ばす」という、攻撃者から見て理想的な性質を三拍子そろえて備えています。今回の一群も、式のサンドボックス脱出、SQL文への直接埋め込み、SSRF、パストラバーサルと、原因の型はどれも古典的です。新しいのは「そういう機能が業務基盤の真ん中に置かれるようになった」という状況のほうでしょう。導入を検討する段階で「このツールが侵害されたら、どのSaaSのどの権限まで一緒に持っていかれるか」を先に書き出しておくと、権限設計と監視の優先順位が決めやすくなります。

まとめ

  1. 2026年8月、n8n本体で34件の脆弱性が公表された。修正版は1.123.67 / 2.31.5 / 2.32.1（8月11日公表分）と1.123.69 / 2.33.4 / 2.34.1（8月20日公表分）。バージョン範囲の突き合わせより、最新安定版への更新が確実
  2. 核心は「ワークフローを編集できる一般ユーザー」からの攻撃。共有認証情報の窃取、式サンドボックスからのコマンド実行、ノード経由のファイル読み書きが並ぶ。編集権限は管理者相当として扱う
  3. 自前ホストなら n8n audit で棚卸しし、SSRF保護と危険ノードの無効化を設定する。そもそも社内にインスタンスが無いかの確認（docker ps）が最初の一歩

関連記事

出典

タイトルとURLをコピーしました