VercelのWAFだけで大丈夫？Node.js脆弱性で点検する外部取得と実行版

VercelでNext.jsやAPIを運用している場合、Node.jsのBrotli脆弱性CVE-2026-111497への対応は、入口のWAFだけでは完了しません。Vercelは10月21日付の公式告知で、受信する攻撃へのWAF対策と管理ランタイムへの修正版展開を案内しています。一方、関数が外部サーバーから取得する応答は、そのWAFの保護範囲外です。

本稿は2026年10月24日に公式資料を確認した、既報のNode.js更新に対する構成別の対応解説です。新しい脆弱性の発表として扱う記事ではありません。Vercel管理の関数、自前のバックエンド、外部データを取得する処理を分け、誰が何を更新し、どの記録で確認するかを整理します。以下の台帳や検証順序は本サイトの運用提案であり、実環境で攻撃・検証した結果ではありません。

Brotliを配信することと解凍することを区別する

Node.js｜2026年10月21日の公式セキュリティ更新によると、CVE-2026-111497は同梱Brotliデコーダーの境界外書き込みです。攻撃者が渡した圧縮データをアプリケーションが解凍する経路で、プロセスのクラッシュ、メモリー開示、コード実行につながる可能性があります。対象は22・24・26系列で、公式の深刻度はHighです。

ここでは、ブラウザーへBrotli圧縮したファイルを配信しているかだけで判断しないことが大切です。調べる対象は、Node.jsの処理が外部の圧縮データを解凍する場所です。受信本文の解析、HTTPクライアント、画像取得、外部データ同期など、依存ライブラリーの内部処理も含めて確認します。

たとえば画像URLを受け取り、サーバー側で元画像を取得する実装なら、利用者から来る要求と、画像サーバーが返す応答は別の入力です。受信側で要求を許可した後に、処理中のNode.jsへ別のデータが入ります。URLの文字列と取得した実データを、同じ検査を通ったものとして扱わないでください。この例は入力経路の説明であり、特定サイトの被害を示すものではありません。

Vercelの案内を三つの配置に分ける

Vercel｜Node.jsのBrotli脆弱性に関するセキュリティ告知の要点は、WAFが既知の受信攻撃パターンを遮断しても、外部から取得する応答の対策にはランタイム修正が必要という点です。管理ランタイムの22・24系列はVercelがパッチを管理し、20系列は22または24系列へ変更して再デプロイするよう案内しています。自前環境の修正版は22.23.4、24.22.1、26.12.1です。

配置・処理	確認する担当範囲	本サイトが勧める確認記録
Vercel管理のNode.js関数	提供元のパッチ展開と利用系列	対象デプロイ・実行版・確認日時
Vercelから呼び出す外部バックエンド	バックエンド管理者による更新	サーバーやイメージの版・反映先
関数やバックエンドによる外部取得	応答を解凍する実行環境	取得機能・利用ライブラリー・実行場所

本サイトが提案する最初の作業は、公開URLから処理の終点までを列挙することです。画面だけをVercelへ置き、APIや画像処理を別のコンテナで動かしている構成では、それぞれに担当と完了条件を設けます。「Vercelを利用中」という一項目だけでは、更新の責任範囲を説明できません。

外部バックエンドには、Vercel経由の経路に加えて、別のドメインや直接アドレスから到達できる経路がないかも確認します。許可元の制限は自社構成に合わせて設計し、ヘルスチェックや管理通信を止めないよう段階的に適用します。外部バックエンド自身の更新記録は、フロント側のWAF設定とは別に残します。

管理ランタイムの展開完了を推測しない

確認時点のVercel告知には、修正版を管理ランタイムへ展開中という表現が残っています。本記事では、これをすべてのデプロイで更新が完了した証拠にはしていません。特定環境の反映状況は、提供元の最新案内と自分の稼働記録で確認してください。

Vercel｜Node.jsの対応バージョンと設定方法では、利用者が選ぶのはメジャー系列で、マイナー・パッチ更新はVercelが必要に応じて適用すると説明されています。また、プロジェクト設定に加えてpackage.jsonのengines.nodeも確認対象で、設定を上書きする場合があります。管理画面だけを見て意図した系列だと決め付けないでください。

{
  "engines": {
    "node": "24.x"
  }
}

これは系列指定の例であり、特定のパッチ版を固定する設定ではありません。既存プロジェクトへ適用する際は、利用フレームワークと依存関係の対応を検証します。系列変更後のデプロイでは、通常のページ表示に加え、API、画像処理、認証後の画面、定期処理を確認します。

設定上は24系列なのに稼働ログが期待する修正版と一致しない場合は、まずログが本番・プレビューのどちらか、どのデプロイのものかを確認します。そのうえで実行版と確認時刻を添えて提供元へ照会します。ビルドキャッシュを消す操作だけで、管理ランタイムのパッチ反映が保証されたと判断しないことが重要です。

ビルド時と実行時に別々の証拠を残す

Node.js｜実行中の版を示すprocess.versionのprocess.versionは、そのコードを実行しているNode.jsの版を返します。運用上は、ビルドログのnode --versionと、実際に要求を処理する関数・バックエンドのログを分けて記録すると、どの環境を確認したかが明確になります。

console.info("runtime-check", {
  node: process.version
});

上のコードはアクセス制限された内部ログへ一時的に出力する最小例です。認証情報や環境変数をまとめて出力する必要はありません。一般公開の診断APIを新設するのではなく、既存の運用ログで対象の処理を実行し、デプロイIDとログ時刻を対応付けます。

本番へ変更を入れる前に、担当者が記録先と削除時期を決めます。長時間動く外部ワーカーや複数レプリカがある場合は、代表一台の結果で全体を完了にせず、配置先と稼働実体の一覧へ結果を戻してください。版の確認は修正の反映を調べる材料であり、過去に侵害がなかったことの証明にはなりません。

外部取得機能は成功・拒否・異常時の三つを試す

ここからは本サイトの検証提案です。自社が管理する検証用の応答を使い、通常の圧縮データが処理できること、許可していない取得先を拒否すること、解凍や通信の異常で処理が制御されたエラーになることを確かめます。脆弱性の攻撃データを本番へ投入する試験は不要です。

• 通常の画像・API応答を取得し、画面や後続処理が正常に動くことを確認する
• 取得先の許可条件、リダイレクト、タイムアウト、応答サイズ上限を実装に沿って点検する
• 通信・解凍エラーが起きた場合に、無期限再試行やジョブの滞留がないか確認する
• 更新前後でエラー率、応答時間、メモリー使用量を比較する

これらの試験はアプリケーションの動作と防御設計を確認するもので、ランタイムの修正を代替しません。また、要求サイズの制限と、展開後データの資源消費は別に考えます。小さな圧縮データでも処理の負担が大きくなる場合に備え、メモリーや処理時間の上限と監視を確認します。

チームの完了報告には対象と未完了を残す

本サイトが勧める完了記録は、サービス名、配置先、管理担当、利用系列、実行時の版、デプロイやイメージの識別子、検証日時、残る例外の組み合わせです。委託先へ依頼する場合も「WAFが入ったか」だけで終えず、関数が取得する外部応答と、自前バックエンドまで含む回答を求めます。

更新で不具合が出た場合は、修正版を維持したまま機能を一時停止できるかを先に検討します。旧版の成果物へ戻す必要があるなら、その成果物が使う実行環境と公開範囲を再評価し、次の対応期限を記録します。画面が復旧したことと、セキュリティ対応が完了したことを同じ一言で済ませない運用が役立ちます。

今回の実務上の要点は、入口の保護と処理中の外部入力を一緒にしないことです。WAF、管理ランタイム、自前バックエンド、外部取得機能を自分の構成へ対応付ければ、提供元の対策と利用者側の作業を具体的な確認項目にできます。

関連記事

Node.jsがBrotliのRCEなどを修正｜CIと本番のランタイムを更新するでは、10月21日の更新全体と、TLS・乱数・権限モデルを含む確認点を扱っています。本稿はそのうちVercel利用時の責任範囲と外部応答の経路に絞った解説です。