Schrittweise Analyse der Sicherheitslücke und Aufbereitung des gesamten Forschungszyklus:

Sammlung und Strukturierung von Materialien.
Systematisierung öffentlicher Quellen zu CVE-2025-29927; Darstellung des Defekts, seiner Auslösebedingungen und bestätigten Versionen/Patches.

Bestimmung von CPE und Konfigurationsbedingungen.
Auflistung von CPE/Versionen und Beschreibung der Konfigurationen, unter denen die Sicherheitslücke reproduzierbar ist (z. B. Self-Hosted-Deployment und Autorisierung auf Middleware-Ebene).

Sichere Demonstration.
Erstellung einer reproduzierbaren Demo in einer Testumgebung (ohne destruktive Aktionen), die den Middleware-Bypass in anfälligen Versionen bestätigt.

Methoden zur Massenüberprüfung.
Beschreibung und Implementierung von drei sicheren Ansätzen:

• nuclei (aktiver Modus mit minimaler Beeinträchtigung),
• nuclei (passiver Modus basierend auf Versionen/indirekten Anzeichen),
• eigenes Skript in Python/Go (multithreaded aktive Prüfung auf Testhosts).

Kern der Sicherheitslücke

• Ursache. In Next.js wird der interne Header x-middleware-subrequest verwendet, um interne Unteranfragen zu verfolgen und Rekursion in der Middleware zu verhindern. In anfälligen Zweigen können externe Clients diesen Header mit einem „erwarteten“ Wert einfügen – und die Laufzeit überspringt die Ausführung der Middleware und leitet die Anfrage direkt an den Routenhandler weiter.

• Rolle des Headers. Der Header x-middleware-subrequest war ursprünglich als interner Indikator gedacht, dass die aktuelle HTTP-Anfrage vom Framework selbst als Zwischenunteranfrage gestartet wurde und nicht direkt vom Benutzer kommt.
  Er wird für die korrekte Funktion interner Next.js-Mechanismen benötigt: Neben dem Routing hilft dieses Flag, Endlosschleifen zu vermeiden, indem jeder aufgerufene Zwischenschicht „markiert“ wird.
  Aber genau diese Logik führte zu einem unbeabsichtigten Sicherheitsloch: Ein Client, der diesen Header selbst hinzufügt, kann das System dazu bringen, seine Anfrage als intern zu behandeln und somit die Autorisierungsprüfungen zu umgehen.

• Entwicklung der Logik.

  • In früheren Versionen wird der Header als eine durch Doppelpunkte getrennte Liste von Werten interpretiert, und der Mechanismus vergleicht ihn mit dem Namen/Pfad der aktiven Middleware.
  • In neueren Zweigen wurde ein Schutz gegen Endlosrekursion in Form eines Tiefenzählers hinzugefügt; bei Erreichen des Schwellenwerts (standardmäßig 5) wird die Middleware ebenfalls übersprungen. Dieser Mechanismus kann getäuscht werden, wenn der Header so formatiert ist, „als ob“ die Kette von Unteranfragen das Limit bereits erschöpft hätte.

Auswirkungen

• Vertraulichkeit und Integrität. Unautorisierter Zugriff auf geschützte Seiten oder APIs, wenn die Zugriffskontrolle nur auf Middleware-Ebene implementiert ist; potenzielle Datenänderung über geschützte Endpunkte.
• Verfügbarkeit. Nebenwirkungen wie Cache Poisoning können zu falschem Caching und Beeinträchtigung der Verfügbarkeit in bestimmten Konfigurationen führen.

CPE und Konfigurationsbedingungen

Offizielle CPE (CPE 2.3)

Aktuelle NVD-Einträge verweisen auf das Produkt Vercel Next.js mit der Zielsoftware node.js. Für die anfälligen Zweige gelten die folgenden Konfigurationen (Versionsbereiche auf CPE-Konfigurationsebene in NVD):

Anmerkung: In der CVE-Beschreibung wird auch angegeben, dass die Sicherheitslücke im Allgemeinen „ab 11.1.4 bis 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3“ unter den unten genannten Bedingungen reproduzierbar ist.

Relevanzbedingungen in der Produktionsumgebung

• Die Zugriffskontrolle (Authentifizierung/Autorisierung) ist in der Middleware implementiert und wird nicht in den Handlern/Backend dupliziert.
• Das Deployment erfolgt self-hosted (z. B. next start, Build mit output: 'standalone') oder in einer Umgebung, in der Middleware bei eingehenden Anfragen ohne Perimeter-Filterung interner Header ausgeführt wird.
• Es gibt keine externen Maßnahmen, die Benutzeranfragen mit x-middleware-subrequest verwerfen (z. B. WAF-Regeln).

Interner Mechanismus von x-middleware-subrequest

Um Endlosrekursion des Zwischencodes zu verhindern, erzeugt und liest die Laufzeit einen internen Header:

1. Der Header-Wert wird als Zeichenkette mit durch Doppelpunkte : getrennten Elementen interpretiert – es entsteht ein Array von „Unteranfragen“.
2. Die Laufzeit prüft dann:
   • ob der Name/Pfad der aktuellen Middleware in diesem Array vorkommt (dies führte in alten Zweigen zu einem sofortigen Überspringen über NextResponse.next()),
   • oder ob die maximale Rekursionstiefe erreicht ist (in neuen Zweigen wird eine Grenze verwendet, standardmäßig 5), und dann wird die Middleware ebenfalls übersprungen.
3. Zum Schutz vor Manipulation wurde in Patches eine separate Unteranfrage-ID (x-middleware-subrequest-id) hinzugefügt, die mit der aktuellen Prozesssitzung verknüpft ist; stimmt sie nicht überein, wird der eingehende x-middleware-subrequest serverseitig gelöscht.

Exploitation-Methode

Ein Angreifer sendet eine HTTP-Anfrage an die Ziel-Next.js-Anwendung und fügt den internen Header x-middleware-subrequest hinzu.
Als Wert wird der Pfad zur Middleware-Datei angegeben – z. B. pages/_middleware, middleware oder src/middleware.
Der benötigte Wert hängt von der verwendeten Next.js-Version und der Projektstruktur ab.

Wenn eine solche Anfrage die Anwendung erreicht, interpretiert die interne Framework-Logik sie als interne Unteranfrage und geht davon aus, dass die Zwischenschicht bereits ausgeführt wurde.
Infolgedessen werden die Authentifizierungs- und Autorisierungsprüfungen, die normalerweise in der Middleware stattfinden, tatsächlich umgangen.

PoC / Exploit

Wichtig: Dieses Material dient ausschließlich zur Überprüfung des Patches und zur Risikomodellierung in einer geschlossenen Testumgebung.
Prüfungen in der Produktionsinfrastruktur sind nur mit Genehmigung des Ressourcenbesitzers zulässig.

Allgemeines Prinzip

Next.js verwendet den internen Header x-middleware-subrequest, um interne Unteranfragen zu markieren und einen rekursiven Middleware-Start zu verhindern.
Bei der Verarbeitung einer Anfrage wird der Header-Wert anhand des :-Zeichens aufgeteilt und mit dem Namen der aktuellen Middleware verglichen.
In neueren Versionen wurde eine Tiefengrenze hinzugefügt (MAX_RECURSION_DEPTH, normalerweise 5).
Wenn die Bedingung (Namensübereinstimmung oder Erreichen des Limits) erfüllt ist, überspringt Next.js die Middleware und leitet die Anfrage weiter.
Ein Angreifer kann einen korrekten Header-Wert erzeugen, der eine interne Unteranfrage simuliert.

Exploitation nach Versionen

1️⃣ Versionen vor 12.2: Pages Router und _middleware.*

• Middleware-Dateien hießen _middleware.js/ts und befanden sich im Verzeichnis pages/.
• Der Header-Wert muss mit dem Pfad zur Datei übereinstimmen, z. B.: x-middleware-subrequest: pages/_middleware

2️⃣ Versionen 12.2 – 13.0.0: root middleware.*

• Ab Version 12.2 wurde der Unterstrich im Namen entfernt: Die Datei heißt nun middleware.js/ts.
• Sie kann im Stammverzeichnis des Projekts oder im Stammverzeichnis des Ordners /src liegen.
• Zum Umgehen der Middleware wird der Header verwendet: x-middleware-subrequest: middleware oder x-middleware-subrequest: src/middleware

3️⃣ Versionen 13.x und neuer: Rekursionstiefenbegrenzung

• Es wurde eine Tiefenprüfung hinzugefügt: Der Header-Wert wird nach : aufgeteilt, und wenn die Anzahl der Wiederholungen des Middleware-Namens ≥ 5 ist,
  geht Next.js davon aus, dass die Rekursionsbedingung erfüllt ist und überspringt die Middleware über NextResponse.next().
• Für den Angriff wird der Header wie folgt formatiert: x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware oder x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middleware

Besonderheiten in Next.js 15.x

In den Versionen 15.x wurde die Logik überarbeitet, um endlose rekursive Aufrufe zu verhindern.
Wenn eine Middleware auf einem Pfad ausgelöst wird (z. B. /api/*), erhält Next.js eine andere URL, die ebenfalls dieselbe Middleware auslöst.
Das Framework zählt die Anzahl der Auslösungen über den Header x-middleware-subrequest.
Wenn die Anzahl der Aufrufe den festgelegten Schwellenwert erreicht (MAX_RECURSION_DEPTH, standardmäßig 5), werden weitere Middleware-Aufrufe blockiert.
Ein Angreifer kann dieses Verhalten ausnutzen, indem er im Header vorab einen Wert mit der erforderlichen Anzahl von Wiederholungen angibt und so künstlich die Tiefengrenze erreicht – die Middleware wird dann vollständig übersprungen.

Beispielanfrage

Für alte Zweige wird der Header-Wert gemäß den oben genannten Optionen gewählt

Warum das funktioniert

x-middleware-subrequest war als interner Mechanismus zum Schutz vor Endlosrekursion gedacht.
In anfälligen Versionen fehlte jedoch eine Filterung externer Anfragen: Der Client konnte den Header fälschen,
die Bedingung für das Überspringen (Namensübereinstimmung oder Erreichen der Tiefengrenze) erfüllen
und direkt auf den Handler der geschützten Route zugreifen.

Starten des Teststandes

Testen:

(Beispiel basiert auf Next.js 15.2.2; für andere Zweige wählen Sie den Header-Wert gemäß der Tabelle im PoC-Abschnitt)

1. Standardanfrage:

2. Anfrage mit x-middleware-subrequest-Header:

Schutzempfehlungen

• Aktualisieren Sie Next.js mindestens auf die Versionen 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3.
• Wenn das Update verschoben wird – filtern oder verwerfen Sie den externen Header x-middleware-subrequest auf WAF/Proxy-Ebene.
• Duplizieren Sie kritische Autorisierungsprüfungen in API-Handlern, nicht nur in der Middleware.

Nuclei-Vorlage zum Testen

• Diese Vorlage kombiniert passive und aktive Prüfungen von Next.js-Anwendungen.
• Passiv analysiert sie Header und Weiterleitungen, um Anzeichen von Next.js und möglichem Middleware-Verhalten zu erkennen.
• Aktiv testet sie den Middleware-Bypass mithilfe eines speziell geformten X-Middleware-Subrequest-Headers.
• Sie verwendet mehrere Payloads, was die Wahrscheinlichkeit der Erkennung der Sicherheitslücke erhöht – etwa 60% unter Standardtestbedingungen.

⚠️ Achtung: Die Vorlage ist nur für Tests auf eigenen oder autorisierten Zielen bestimmt. Die Verwendung auf fremden Diensten ohne Zustimmung der Eigentümer ist illegal.

Skript für Massentests

• Das Skript unterstützt Multithreading, was eine schnelle Überprüfung einer großen Anzahl von Diensten und Pfaden ermöglicht.
• Es unterstützt die Eingabe von Ziellisten und Pfadlisten über Dateien.