2026年2月4日（UTC）に公表された CVE-2026-25049 は、OSSワークフロー自動化プラットフォーム n8n の「式評価（Expression）」におけるサンドボックス脱出を起点に、ホスト上での任意コマンド実行（RCE）へ到達し得る脆弱性である。GitHub Security Advisory（GHSA-6cqr-8cfr-67f8）はCVSS v4.0で 9.4（Critical） と評価し、影響は <1.123.17 および <2.5.2 と整理されている（n8nコミュニティの告知では 2.4.5 でも修正が提供された）。

本稿では、型混同を用いたサニタイズの前提崩壊から、Webhook運用で「外部HTTPリクエストが脆弱な式を実行してしまう」状態までを攻撃チェーンとして再構成する。その上で、ローコード／ワークフロー自動化基盤に共通する「式評価エンジン」の安全設計指針を提示する。

CVE-2026-25049の要点: 影響範囲、前提条件、CVSSの読み方

影響範囲は、NVDおよびGHSAの記述に従うと、n8nの式評価を悪用してホスト上でのコマンド実行に至り得る点にある。攻撃の成立条件として、少なくとも「ワークフローを作成・編集できる権限（低権限でも可）」が問題になる。すなわち、n8nを「自動化ツール」ではなく「サーバー上でコードを実行できる実行基盤」として扱うべき局面である。

  • 影響バージョン: n8n < 1.123.17、および 2.0.0以上 < 2.5.2（GHSA/NVD）。n8nコミュニティ告知では 2.4.5 でも修正が提供された。
  • 脅威モデル: ワークフロー作成・編集を許可されたユーザー（内部不正、アカウント乗っ取り、委託先アカウントなど）が、ワークフロー内パラメータの式に細工し、サンドボックスを脱出してホスト側で任意コードを実行する。
  • CVSSの差分: GHSAはCVSS v4.0を主スコアとして9.4を提示している。一方で、互換のためCVSS v3.1ベクターも併記され、外部DBでは9.9（Critical）として流通する場合がある。スコアの相違は「深刻度が変わった」というより、採用するCVSS世代・計算器の違いとして解釈するのが実務的である。

なお、本件は「CVE-2025-68613に対する対策後に追加のエクスプロイトが見つかった」経緯を持つ。つまり、式評価サンドボックスを“ブラックリストとAST検査”で塞ぐ設計は、抜け穴探索に対して脆いという構造的教訓がある（関連記事: n8n三連続RCEの教訓）。

攻撃チェーン再構成: 型混同によるサニタイズバイパスからRCEへ

脆弱性の核心は「ユーザーが入力する式」を安全に評価するためのサニタイズが、JavaScriptの実行時挙動を取りこぼしていた点にある。Endor Labsは、プロパティ名が必ず文字列であるというTypeScript上の前提が、実行時には強制されておらず、これがサニタイズバイパスに直結すると指摘している。

典型的な攻撃チェーンは次のように整理できる（具体的なエクスプロイト文字列は示さない）。

  1. 前提獲得: 攻撃者が「ワークフロー作成・編集」権限を得る（正規ユーザー、乗っ取り、権限設定ミス等）。
  2. 式への埋め込み: 任意のノードのパラメータに、式評価エンジンが解釈する入力を埋め込む。
  3. サニタイズの前提崩壊: 禁止プロパティ（例: constructor 等）の参照をブロックするロジックが、実行時の型（文字列以外）を想定しておらず、ブラックリスト判定をすり抜ける。
  4. サンドボックス脱出: すり抜けた参照を足掛かりに、グローバルオブジェクトや関数生成経路へ到達する。
  5. RCE: Node.js実行環境上の機能に接続し、ホスト上のコマンド実行や機密情報取得へ拡張される。

技術的詳細: 「文字列前提」のdenylistが破られる仕組み

Endor Labsの分析は、セキュア設計の観点で非常に示唆的である。n8n側は危険なプロパティ名をdenylist（Set）で管理し、式中のプロパティ参照が安全かを判定する。しかし、判定関数が property: string と注釈されていても、JavaScriptランタイムは外部入力に対して型を強制しない。結果として、攻撃者は「見かけ上はプロパティ名だが、実行時には文字列ではない値」を渡せてしまう。

ここで重要なのは、ブラックリスト照合は厳密一致（===）である一方、実際のプロパティアクセスでは型が強制的に文字列化され得る点である。つまり「判定はすり抜けるが、アクセス時には望む（危険な）プロパティ名として解釈される」というズレが攻撃面になる。

この種の問題はn8n固有ではない。TypeScript採用プロジェクトでは特に、型注釈が“セキュリティ境界”に誤用される事故が起きやすい。式評価・テンプレート評価・DSL評価のように「外部入力を解釈する」機能では、型注釈ではなく実行時の検証（runtime validation）が唯一の防波堤になる。

Webhookがリスクを増幅する理由: 「認証の外側」で式が実行される運用

本件は「ワークフロー編集権限」が起点になる一方で、実運用ではWebhookトリガーがリスクを増幅しやすい。理由は単純で、Webhookは外部公開されがちであり、ワークフローが有効化されると外部からのHTTPリクエストが、脆弱な式を含む処理パスを実行してしまう可能性があるためだ。

この場合、攻撃者に必要なものは2段階に分かれる。

  • 段階A（初期侵入）: ワークフロー編集権限（アカウント乗っ取り、内部不正、過剰権限付与など）。
  • 段階B（発火）: 公開Webhook等にHTTPリクエストを送るだけで、埋め込まれた式が実行され得る。

すなわち、外形的には「Webhookへの無認証リクエストがRCEに見える」状況が成立し得る。だが本質は、式評価という“コード実行面”を、運用上の公開エンドポイントに結び付けてしまう設計にある。

設計指針: ワークフロー自動化基盤の式評価エンジンを安全にする

CVE-2026-25049は、単発の実装ミスというより「式を安全に実行する」ことの難しさを再確認させた。n8nのようなプラットフォーム、または同種のローコード基盤が採るべき指針は次の通りである。

  • Type Safety ≠ Runtime Safety: 入力が外部由来である限り、型注釈は無力である。サニタイズやポリシー判定は必ず typeof 等で実行時検証を行う。
  • denylist依存を減らす: 「危険なものを列挙して禁止」は破られやすい。可能なら、式言語をより制限されたものへ移行し、機能の許可制（allowlist）を採る。
  • AST検査の“網羅性”を前提にしない: JavaScriptは表現力が高く、同じ意味に到達する構文が多い。特定ノード型だけ見て安全だと結論づける設計は、長期的に破綻しやすい。
  • OSレベルの隔離で防御を重ねる: 式評価を別プロセス化し、権限を落とし、ファイルシステム・ネットワーク・環境変数・メタデータへのアクセスを最小化する。サンドボックスはアプリ内だけで完結させない。
  • ワークフロー権限を最小化する: 「閲覧」「実行」「編集」「公開（Webhook等）」を分け、公開エンドポイントを作れる主体を厳格に制限する。
  • 検知と監査: ワークフローの差分監査、式フィールドの監視、異常な実行（短時間の大量失敗、想定外の外部通信、プロセス起動）を検知する。

結論として、ワークフロー自動化は「便利な統合」ではあるが、同時に「権限・機密・実行環境が集約される」ため、脆弱性が発生した際の被害半径は大きい。CVE-2026-25049は、その現実を短い経路で示した事例である。

FAQ

影響を受けるn8nのバージョンはどれか？

GHSAおよびNVDでは、n8n < 1.123.17 と 2.0.0以上 < 2.5.2 が影響範囲で、1.123.17 と 2.5.2 で修正済みとされる。n8nコミュニティ告知では 2.4.5 にも修正が提供されたと明記されている。

「CVSS 9.4」と「9.9」はどちらが正しいのか？

GHSAはCVSS v4.0を主スコアとして9.4を採用し、互換目的でCVSS v3.1ベクターも併記している。外部データベースがCVSS v3.1を基準に9.9と表示することがあり、評価手法の差分として理解するのがよい。

“無認証RCE”なのか？

少なくともGHSA/NVDの説明は「認証済みでワークフロー作成・編集が可能なユーザー」が前提である。一方で、Webhook等の公開トリガーを組み合わせる運用では、外部からの無認証リクエストが脆弱な式を発火させる形になり得るため、外形的に無認証に見える攻撃パスが成立し得る。

パッチ適用までにできる現実的な対処は？

最優先は修正版へのアップグレードである。短期的には、(1) ワークフロー作成・編集権限を最小限に絞る、(2) n8n実行環境を権限最小化・ネットワーク制限などでハードニングする、(3) 既存ワークフローの式フィールドを監査し、不審な変更やテンプレート流入を点検する、といった対策が現実的である。

参考文献