2026年2月に、ワークフロー自動化基盤n8nにリモートコード実行（RCE）の脆弱性CVE-2026-25049が公開された。GitHubのCNAスコアではCVSS v4で9.4（Critical）とされ、n8nの「式（expression）」機構に対するサニタイズの回避を通じて、任意コード実行に到達し得る点が問題となる。

本稿は、一次情報（GitHub Security Advisory、NVD、公開解析）をもとに、(1) 影響範囲と前提条件、(2) 型混同が「サニタイズ回避」へ接続する理由、(3) ローコード/ノーコード自動化基盤が持つ攻撃面の拡大要因、(4) 2025年12月に公開されたCVE-2025-68613の修正を再び破る回帰バグの読み方、(5) 実務上の防御策を整理するものである。

事実関係: CVE-2026-25049の影響範囲と深刻度

CVE-2026-25049はn8nの式評価に関わるRCE脆弱性であり、GitHubのアドバイザリでは、影響を受けるバージョン範囲としてn8n 1系（0.62.0以降〜1.123.16まで）および2系（2.0.0以降〜2.5.1まで）が示され、修正版は1.123.17および2.5.2とされている。NVDでは、CVEレコードの公開日が2026年2月5日として登録されている。

スコアリングは情報源により差がある。GitHubのアドバイザリ（CNA）ではCVSS v4 9.4（Critical）である一方、NVDではCVSS v3.1 9.9（Critical）として掲載されている。いずれの評価でも「侵害時の影響が極めて大きい」分類である点は一致する。

重要な前提条件は攻撃成立の起点である。GitHubのアドバイザリは、攻撃者が「ワークフローを作成または編集できる権限」を持つ場合に悪用可能と説明している。したがって、完全な無認証RCEと断定するより、自動化基盤における権限設計（誰がワークフローを編集できるか）が直接的にリスクへ変換される事案として理解すべきである。

技術要点: 式サニタイズを破る「型混同」と実行時チェックの限界

n8nはローコード基盤であるが、実装の中核には「式（expression）」がある。ワークフロー定義の中で、入力データや環境情報を参照して値を計算する用途で使われ、実質的にはJavaScript式に近い表現を受け付ける。そのためn8nは、危険な構文や到達経路を遮断するためのサニタイズ（パースと検査）を行う。

CVE-2026-25049のポイントは、サニタイズ側の検査ロジックが前提とする「型」と、ランタイムで実際に処理される「値」の形状が乖離し得る点にある。TypeScriptの型注釈が「ここにはこの型が来るはずだ」という前提を与える一方、実行時の入力はその前提を満たすとは限らない。入力の一部が想定外の型（あるいは想定外のオブジェクト形状）として扱われると、検査が意図せずすり抜け、危険な評価パスへ到達する余地が生まれる。

公開解析では、この問題が「検査対象のASTノード（式の構文木）に対する型前提の崩れ」として整理されている。一般に、この種のバグは「TypeScriptで書かれている」こと自体が防御にならない。防御の実体は、入力を境界で正規化し、期待する構造を実行時に検証すること（スキーマ検証）と、危険な到達可能性をテストで網羅すること（回帰テスト、ファジング）である。

攻撃シナリオ: ワークフロー編集権限とWebhookが組み合わさると何が起きるか

アドバイザリが示す成立条件は「ワークフロー作成/編集権限」である。実務では、ここがしばしば“低いハードル”になる。たとえば、業務部門の自動化担当に広く編集権限を付与していたり、外部委託先に一時的な編集権限を渡していたりするからである。攻撃者にとっては、最初に狙うべきは管理者権限ではなく、ワークフローを触れる権限である。

さらに自動化基盤には「トリガ」が存在する。n8nではWebhookトリガを含む複数の起動経路を持ち、ワークフローが外部入力で実行される設計が一般的である。すなわち、攻撃者が悪性のワークフローを仕込めた場合、次の段階では、外部からのリクエスト（Webhook等）でそれを起動できる構成が現実的に成立する。ここに「編集権限の侵害」と「外部公開トリガ」が連結し、爆発半径が拡大する。

ローコード基盤におけるRCEの本質的な危険は、単にホストOS上でコマンドが実行され得る点にとどまらない。自動化基盤は多様なSaaS連携のために資格情報（APIトークン、OAuthトークン、シークレット）を保持し、ワークフロー実行時に高権限で外部システムへアクセスする。公開解析でも、侵害が成立すると資格情報ストアから秘密情報を奪取し得る旨が指摘されている。RCEは、そのまま「連携先の横展開」の起点になり得る。

回帰バグとして読む: 2025-12-19公開のCVE-2025-68613と“修正の破られ方”

CVE-2026-25049は、過去の類似問題であるCVE-2025-68613（GitHubアドバイザリ公開日: 2025年12月19日）との連続性が指摘されている。セキュリティ修正の回帰は珍しくないが、ローコード基盤の式評価のように「表現力が高い入力」を扱う場合、パッチが特定パターンの遮断に偏ると、別表現で再び抜かれる可能性が高い。

ここから得られる教訓は、(1) ルールベースのブラックリスト検査に依存し過ぎない、(2) 仕様として守るべき不変条件（例: 危険な実行プリミティブへ到達しない）を明確化しテストで固定する、(3) ASTや入力構造に対するファジングで「想定外の型・形状」を継続的に探索する、の3点である。特にTypeScript前提の検査は「型が保証される」という錯覚を生みやすく、入力境界での実行時検証が省略されると、型混同の温床になり得る。

防御策: パッチ適用に加えて、運用で爆発半径を下げる

第一に、修正版へアップグレードすることである。GitHubアドバイザリが示す修正版（1.123.17または2.5.2）以降へ速やかに更新し、公開されている対処指針に従うべきである。

第二に、権限設計を見直すことである。ワークフロー作成/編集権限を最小化し、変更操作の監査（誰がいつどのワークフローを変えたか）を継続的に確認できる状態にする。自動化の利便性と引き換えに“編集権限を広く配る”運用は、RCEの成立条件を満たしやすい。

第三に、外部公開トリガ（Webhook等）の衛生を上げることである。n8nはセキュリティ監査機能を提供しており、例えば「保護されていないWebhook」などの指摘を含むインスタンスレポートを出力できる。外部入力経路を列挙し、認証・許可・レート制限を含めて運用のガードレールを明示することが重要である。

第四に、侵害時の横展開を前提にした“被害を小さくする設計”へ寄せることである。n8nが保持する接続資格情報は、最小権限・短寿命（可能なら）・ローテーション可能な形で管理し、ネットワーク上の到達範囲（アウトバウンド制限、メタデータサービスへのアクセス制限等）も含めてサンドボックス化する。ローコード基盤は「一度破られると連携先まで連鎖する」ため、パッチ適用だけでなく、権限と接続の設計が中核となる。

FAQ

CVE-2026-25049は無認証で悪用できるのか。

GitHubアドバイザリの説明では、攻撃者がワークフローを作成または編集できる権限を持つ場合に悪用可能とされている。従って「完全な無認証RCE」とは前提が異なる。ただし、悪性ワークフローが存在する状況では、Webhook等の外部トリガで実行が誘発され得るため、外部公開経路の衛生は別途重要である。

どのバージョンへ上げればよいか。

GitHubアドバイザリが示す修正版は1.123.17および2.5.2である。運用上は、これら以降の最新安定版へ更新する方針が望ましい。

「型混同」とは何を指すのか。

ここでは、TypeScriptの型注釈が与える前提と、ランタイムで実際に渡される値の型・形状が一致しないことで、検査ロジックが想定外の状態に置かれ、サニタイズが機能しなくなる現象を指す。型注釈はコンパイル時の補助であり、実行時の入力検証を代替しない。

ローコード/ノーコード基盤でRCEが特に危険な理由は何か。

自動化基盤は多くのSaaSと連携し、資格情報を保持するためである。RCEはホスト侵害に加え、APIトークン等の奪取や連携先の横展開につながり得る。したがって爆発半径は「1台のサーバ」ではなく「連携している業務システム群」になり得る。

パッチ適用後に追加で点検すべきことは何か。

ワークフローの変更履歴・不審な式の使用状況・外部公開Webhookの一覧・接続資格情報の棚卸しとローテーションを優先すべきである。加えて、セキュリティ監査機能を用いて、設定上の穴（例: 保護されていないWebhook）を継続的に検出する運用へ移行することが望ましい。

参考文献