Next.js の脆弱性 CVE-N/A が FIX：認証不要の DoS 攻撃でセルフホスト型サーバがクラッシュ

New Unauthenticated DoS Vulnerability Crashes Next.js Servers with a Single Request

2025/11/27 CyberSecurityNews — Next.js フレームワークに発見された深刻な脆弱性 CVE-N/A を悪用する攻撃者は、単一の HTTP リクエストの送信のみで、ごくわずかなリソースを使用するだけで、セルフホスト型サーバをクラッシュさせる可能性がある。Harmony Intelligence の研究者が発見した、このサービス拒否 (DoS) 脆弱性は、パッチ適用前の最新の 15.x ブランチを含む広範なバージョンに影響を与える。

この脆弱性は “body-streams.ts” 内の cloneBodyStream 関数に存在する。この関数は、ストリーム化されたリクエストを、ミドルウェアに渡す前にメモリへコピーするコンポーネントである。この脆弱性の原因は、内部メモリバッファにサイズ制限が存在しない点にあり、この仕組みが悪用されると、一般的なリソース枯渇とは異なる方式の攻撃が成立する。

公開された情報によると、攻撃者はサーバに対して、データチャンクのストリームを無限に送信できる。つまり、攻撃者は自身のメモリから送信済みチャンクを解放できるが、Next.js サーバはストリーム全体を RAM にバッファリングしようとする。

この非対称性により、最小限のリソースしか持たないデバイスであっても、相手側のメモリを枯渇させて堅牢なエンタープライズ・サーバをクラッシュさせる、Smart Toaster と呼ばれる攻撃が可能になる。

別の既知の認証バイパスの脆弱性 (CVE-2025-29927) に関して、AI AppSec Agent のテストを行っていた Harmony Intelligence が、この脆弱性を偶然に発見した。その結果として作成された概念実証スクリプトにより、エージェントが自律的に実行してデモ・アプリケーションをクラッシュさせた。それにより明らかにしたのは、基盤となる Next.js フレームワークにゼロデイ脆弱性が存在することだった。

影響を受けるシステムと影響の範囲

この脆弱性の影響が顕著なのは、ミドルウェアを利用するセルフホスト型の Next.js アプリケーションである。Harmony Intelligence によると、Next.js デプロイメントの約 55% (エンタープライズでは 80% に上昇) がセルフホスト型であることから、潜在的な攻撃対象範囲は非常に大きい。その一方で、Vercel のインフラ上で直接ホストされているアプリケーションは、この問題の影響を受けないという。

現時点において CVE 識別子は割り当てられていないが、リクエストは提出済みとのことだ。研究者たちが CVSS v3.1 の深刻度スコアを 7.5 (High) を推奨するのは、侵入障壁が低く、攻撃実行に認証が不要な点にある。

すでに Vercel は、この脆弱性を 2025年10月13日の時点で修正し、内部バッファのデフォルト・サイズを 10 MB に設定した。管理者に強く推奨されるのは、直ちにアップグレードするか、プロキシレベルで厳格な制約を実施することである。

ComponentStatus / Recommendation
Vulnerability TypeUnauthenticated Denial of Service (DoS)
Affected VersionsNext.js 15.x (<= 15.5.4), 14.x, 13.x, and older
Patched Versions15.5.5, 16.0.0, or newer
Primary MitigationUpgrade to a patched version immediately
WorkaroundConfigure a reverse proxy (e.g., Nginx) to enforce client_max_body_size limits

研究者たちが指摘するのは、ミドルウェア・ベースのレート制限機能がリクエストを処理する前にクラッシュが発生するため、標準的なレート制限ソリューションでは、この攻撃に対処できない点である。それと同様に、Next.js の組み込み機能である bodyParser.sizeLimit 設定も、このメモリ枯渇攻撃ベクターを阻止できない。

この発見が改めて示すのは、セルフホスト型アーキテクチャにおける多層防御戦略の重要性である。

アップグレードが根本的な解決策であるが、アプリケーション・サーバの前段に適切に構成されたリバース・プロキシを配置し、過剰なリクエストをアプリケーション層に到達する前に拒否することは、依然として重要なベストプラクティスである。

Next.js の HTTP リクエスト処理で、ストリームをメモリに無制限に貯め込んでしまう設計が問題の根本にあります。ミドルウェアにデータを渡すための便利な仕組みが、サイズ制限の欠如により、攻撃者に一方的にメモリを使わせてしまう形になっているようです。また、レート制限や bodyParser の設定では防げず、ミドルウェアより前の層で制御できていなかったことも、この非対称な DoS 攻撃を成立させる原因になっていると、この記事は指摘しています。ご利用のチームは、ご注意ください。よろしければ、Next.js での検索結果も、ご参照ください。