Next.js 16.2.6と15.5.18はMiddlewareバイパスとRSC DoSを同時に塞ぐセキュリティ更新

TL;DR

影響 Next.js 13.xから16.xの一部。App Router、Middleware / Proxy、React Server Components、self-hosted Node.js serverの組み合わせで踏み方が変わる

対応 Next.js 16系は16.2.6、15系は15.5.18へ更新。リリースページは同じ13件のadvisoryを列挙

暫定すぐ更新できない環境では、Middlewareだけに認可を寄せないこと、WebSocket upgradeを不用意にoriginへ通さないこと、RSCレスポンスの共有キャッシュを疑うこと

Next.jsの16.2.6と15.5.18が2026年5月7日（UTC）に出た。
リリースページにはHigh 7件、Moderate 4件、Low 2件のsecurity advisoryが並んでいる。

今回は「Next.jsを上げれば終わり」ではある。
ただ、並んでいる名前を見ると、RSC、Middleware / Proxy、App Router、Pages Router、Image Optimization、WebSocket upgrade、Cache Componentsまで散っている。
去年のReact2Shell対応メモほど派手なRCEではないが、Next.jsのサーバー側機能を広く使っている環境ほど確認範囲が広い。

App RouterのMiddleware回避が複数ある

Highの中でいちばん嫌な並びは、Middleware / Proxy bypass系が複数あるところだ。
GHSA-267c-6grr-h53fは、App RouterでMiddlewareやProxyベースの認可チェックに頼っているアプリが、segment prefetch用の.rsc系URLから保護対象へ届く問題として説明されている。
CVSS（脆弱性の深刻度を0〜10で示すスコア）は7.5。Affected versionsは15.2.0以上15.5.16未満、16.0.0以上16.2.5未満。

これは「ログイン必須ページをMiddlewareで弾いているから大丈夫」という設計に刺さる。
advisory側のworkaroundも、すぐ更新できないならMiddlewareだけに頼らず、実際のrouteやpage側で認可をかけろ、という方向になっている。

同じreleaseには、segment-prefetch routeの不完全修正 follow-up、dynamic route parameter injection、Pages Routerのi18n利用時のMiddleware / Proxy bypass、redirectのcache poisoningも入っている。
個別の入口は違うが、運用側の見方はかなり近い。
「Middlewareは境界線」ではなく、「境界線の一部」として扱うほうがいい。

React Server Components由来のDoS（サービス拒否）とキャッシュ汚染

GHSA-8h8q-6873-q5fjは、React Server Components関連のDoSだ。
上流ReactのCVE-2026-23870として追跡されており、細工されたHTTPリクエストをApp RouterのServer Function endpointへ送ると、deserialize時にCPUを過剰消費する。
CVSSは7.5。Affected versionsは13.0.0以上15.5.16未満、16.0.0以上16.2.5未満。

React2Shellのときもそうだったが、RSCまわりは「自分で危ないAPIを書いたか」だけでは判断しづらい。
Next.jsのApp Routerを使っていて、サーバー側でRSCやServer Functionの経路が開いているなら、依存バージョンで見るほうが早い。

ModerateのGHSA-wfc6-r584-vfw7はRSCレスポンスのcache poisoningだ。
共有キャッシュがresponse variantを正しく分けない条件で、HTMLを期待しているURLからRSC payloadが配られる可能性がある。
すぐ更新できない場合は、CDNやreverse proxyがRSC関連ヘッダーをcache keyに含めること、Varyを尊重すること、対象レスポンスの共有キャッシュを切ることがworkaroundとして挙げられている。

静的HTML中心のサイトをAstroへ寄せた話は、以前Next.jsからAstroに移行した記事に書いた。
今回も同じで、SSGだけのサイトと、RSC・Middleware・Image Optimization・WebSocket upgradeを本番で動かしているサイトでは、同じNext.jsでも見るべき攻撃面が違う。

self-hosted Node.js serverのWebSocket upgrade SSRF

GHSA-c4j6-fc7j-m34rは、self-hostedのbuilt-in Node.js serverを使う環境でのSSRFだ。
SSRFはServer-Side Request Forgery、つまりサーバー側に意図しない宛先へリクエストを投げさせる攻撃。
advisoryでは、細工されたWebSocket upgrade requestにより、内部サービスやクラウドmetadata endpointへproxyされる経路として説明されている。
CVSSは8.6で、今回の一覧の中でも高い。

advisoryには「Vercelでホストしているデプロイは影響を受けない」と明記されている。
Vercelに載せているだけなら、このSSRFについては条件から外れる。
一方で、DockerやVMでNext.jsのNode.js serverを直接公開している構成、reverse proxy越しにoriginへupgrade requestを通している構成では、アップグレードを急いだほうがいい。

すぐ更新できない場合の暫定策は、origin serverを直接インターネットへ出さないこと、WebSocket upgradeが不要ならreverse proxyやload balancerで止めること、originからmetadata serviceや内部ネットワークへのegress（外向き通信）を絞ること。
これはNext.js固有というより、self-hosted SSRアプリ全般の基本に近い。

16.2.6と15.5.18へ上げる

release noteには、HighとしてRSC DoS、App Router / Pages RouterのMiddleware / Proxy bypass、Cache Components利用時のconnection exhaustion、WebSocket upgrade SSRFが並ぶ。
ModerateはCSP nonce（Content Security Policyのワンタイムトークン）利用時のXSS（クロスサイトスクリプティング）、beforeInteractive scriptのXSS、Image Optimization APIのDoS、RSC response cache poisoning。
LowはRSC cache-busting collisionとMiddleware / Proxy redirectのcache poisoning。

GitHub advisoryページのpatched versionsは、多くが15.5.16 / 16.2.5になっている。
一方で、2026年5月7日のreleaseとして出ているのは15.5.18 / 16.2.6なので、今から作業するならrelease tag側の最新へ寄せるのが自然だ。

更新自体は普通に依存を上げる。

pnpm up next@16.2.6

15系に残す場合はこう。

pnpm up next@15.5.18

npmやyarnなら同じバージョンを指定して更新する。
lockfileを更新したら、next build、認可が絡むroute、Middleware / Proxy、画像最適化、WebSocket upgradeを使う箇所を触る。
DependabotやRenovateがPRを出しているなら、今回は「通常のminor追従」ではなくsecurity releaseとして扱ったほうがいい。