

Alle Versionen von Next.js von 11.1.4 bis 13.5.6, 14.x vor 14.2.25 und 15.x vor 15.2.3 sind von dieser Sicherheitslücke betroffen. Die Auswirkungen sind besonders schwerwiegend für Anwendungen, die Middleware zur Implementierung von Zugriffskontrollen verwenden, da Angreifer ohne Authentifizierung unbefugten Zugriff auf geschützte Ressourcen erhalten können.
Die Sicherheitslücke in CVE-2025-29927 beruht auf einem Designfehler in der Art und Weise, wie Next.js den x-middleware-subrequest-Header verarbeitet. Dieser Header war ursprünglich für die interne Verwendung im Next.js-Framework vorgesehen, um Endlosschleifen bei der Middleware-Ausführung zu verhindern.
Wenn eine Next.js-Anwendung Middleware verwendet, wird die Funktion runMiddleware aufgerufen, um eingehende Anfragen zu verarbeiten. Im Rahmen ihrer Funktionalität prüft diese Funktion das Vorhandensein des x-middleware-subrequest-Headers. Wenn dieser Header existiert und einen bestimmten Wert enthält, wird die Middleware-Ausführung vollständig übersprungen und die Anfrage wird direkt über NextResponse.next() an ihr ursprüngliches Ziel weitergeleitet.
Die Sicherheitslücke liegt darin, dass diese Header-Prüfung von externen Benutzern ausgenutzt werden kann. Durch Hinzufügen des x-middleware-subrequest-Headers mit dem korrekten Wert zu einer Anfrage kann ein Angreifer jegliche auf Middleware basierende Schutzmechanismen vollständig umgehen.
Klonen Sie das Repository:
git clone <repository_url>
Wechseln Sie in das Projektverzeichnis:
cd nextjs-docker-app
Erstellen Sie das Docker-Image:
docker build -t nextjs-app .
Führen Sie den Docker-Container aus:
docker run -p 3000:3000 nextjs-app
Greifen Sie im Browser unter http://localhost:3000 auf die Anwendung zu.
Die Ausnutzungsmethode variiert je nach Next.js-Version geringfügig:
In diesen Versionen mussten Middleware-Dateien den Namen _middleware.ts tragen und im Ordner pages abgelegt werden. Der Wert von middlewareInfo.name setzte sich aus dem Verzeichnisnamen und dem Dateinamen zusammen:
x-middleware-subrequest: pages/_middleware
Bei verschachtelten Routen konnte es mehrere Middleware-Dateien auf verschiedenen Ebenen geben, was zu mehreren möglichen Werten für den Header führte:
x-middleware-subrequest: pages/dashboard/_middleware
oder
x-middleware-subrequest: pages/dashboard/panel/_middleware
Ab Version 12.2 hat Next.js die Middleware-Konventionen geändert. Die Datei sollte middleware.ts (ohne Unterstrich) heißen und sich nicht mehr im Ordner pages befinden. Für diese Versionen ist das Payload einfacher:
x-middleware-subrequest: middleware
Zusätzlich erlaubt Next.js eine alternative Projektstruktur mit einem /src-Verzeichnis. In solchen Fällen wäre das Payload:
x-middleware-subrequest: src/middleware
Für Versionen 13.2.0 und höher hat Next.js eine maximale Rekursionstiefe für die Middleware-Ausführung eingeführt. Dies wurde implementiert, um Endlosschleifen zu verhindern, hat aber keinen Einfluss auf die Sicherheitslücke. Die Ausnutzung bleibt gleich, da die Header-Prüfung vor allen Rekursionstiefenprüfungen erfolgt.
x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware
Alternativ für Projekte, die eine /src-Verzeichnisstruktur verwenden:
x-middleware-subrequest: src/middleware:src/middleware:src/middleware:sr
=======
# cve-2025-29927
>>>>>>> 56c7b2dcd548caf771750519107bf7c57749a864