Next.js Sicherheitslücken 2025: CVE-2025-29927 und was der Middleware-Bypass für Hosting bedeutet

Im März 2025 wurde eine Schwachstelle öffentlich, die für viele Teams unangenehm war: CVE-2025-29927, ein Authorization-Bypass in der Middleware von Next.js. Ein Jahr später ist der Lärm verklungen, aber die Lehren aus dem Fall sind es nicht wert, vergessen zu werden, denn sie treffen genau die Schnittstelle, an der moderne JavaScript-Anwendungen zum Server-Admin-Thema werden.

Was die Schwachstelle war

Next.js-Middleware ist Code, der vor der eigentlichen Anwendungslogik läuft und typischerweise Authentifizierung, Weiterleitungen oder Header-Regeln übernimmt. Viele Anwendungen prüfen hier Cookies oder Rollen und blockieren unangemeldete Zugriffe, bevor die Seite überhaupt erreicht wird. Das Muster ist beliebt, weil es zentral und bequem ist: Ein einziger Codepfad entscheidet über alles, was dahinterliegt. Genau diese Bequemlichkeit macht den Angriffstyp so folgenreich, denn eine umgangene Middleware-Schicht ist keine teilweise Lücke, sondern ein komplettes offenes Tor.

Intern verwendet Next.js einen Header namens x-middleware-subrequest, um Endlosschleifen bei rekursiven Requests zu verhindern. Der Fehler bestand darin, dass dieser interne Header von außen gesetzt werden konnte und sein erwarteter Wert vorhersagbar war. Ein entsprechend präparierter Request ließ das Framework die Middleware komplett überspringen. Folge: Autorisierungsprüfungen, die ausschließlich in der Middleware stattfanden, wurden umgangen, und geschützte Routen waren ohne Anmeldung erreichbar. Klassifiziert wurde das als CWE-285 (fehlerhafte Autorisierung), mit einer CVSS-Basisbewertung von 9.1 (kritisch) durch den CNA.

Betroffene Versionen und Fix

Nach der offiziellen Advisory waren Versionen von 11.1.4 an betroffen, jeweils bis unter die Fix-Stufen 12.3.5, 13.5.9, 14.2.25 und 15.2.3. Die Patches erschienen zeitversetzt über die Hauptlinien: 14.2.25 am 17. März 2025, 15.2.3 in der Nacht zum 18. März, 13.5.9 am 22. März und 12.3.5 am 23. März 2025. Die CVE wurde am 21. März 2025 veröffentlicht.

Betroffen war vor allem das selbst betriebene Hosting: Anwendungen, die über next start oder als output: 'standalone' laufen und Middleware für Sicherheitsprüfungen nutzen. Statische Exports liefen nicht in die Lücke, weil Middleware dort gar nicht ausgeführt wird, und auf einigen großen Hosting-Plattformen war die Routing-Logik vom Anwendungsserver entkoppelt, was die Lücke dort von vornherein ausschloss. Für selbst betriebene Server gab es diesen Schutz nicht.

Als Übergangsmaßnahme, falls ein Update nicht sofort möglich war, empfahl der Hersteller, Requests mit dem Header x-middleware-subrequest bereits am Reverse Proxy oder in der Infrastruktur vor der Anwendung zu filtern. Das ist ein sauberer Notnagel, aber kein Dauerzustand.

Was das für Hosting bedeutet

Drei Lehren aus diesem Fall haben wir seitdem in unseren Betriebsansatz übernommen, und wir würden sie jedem ans Herz legen, der Anwendungen für Kunden betreibt:

• 1. Framework-Updates sind Server-Updates. Die Vorstellung, dass die Anwendung „nur“ von der Entwicklerseite gepflegt wird, funktioniert nicht mehr. CVEs in Framework-Bibliotheken landen auf demselben Patch-Zyklus wie das Betriebssystem, und der muss automatisiert beobachtet werden. Ein Advisory, das man erst entdeckt, wenn ein Scanner es meldet, ist bereits zu spät entdeckt.

• 2. Version-Pinning und Update-Disziplin gehören zusammen. Paketversionen sauber zu pinnen, ohne einen Prozess für Sicherheitsupdates zu haben, verwandelt Stabilität in Stagnation. Die Praxis läuft anders: Version festnageln, Advisory-Feeds zu den eingesetzten Frameworks abonnieren, und Sicherheitspatches sofort über einen geprüften Weg ausrollen.

• 3. Middleware ist keine Sicherheitsgrenze. Die Empfehlung der Herstellerdokumentation nach dem Vorfall war eindeutig: Middleware sollte nicht der einzige Schutzpfad für Routen sein. Autorisierungsprüfungen gehören auch in die Datenzugriffs- und API-Schicht, sodass eine einzelne umgangene Prüfung nicht den ganzen Schutz aushebelt. Das ist klassische Defense in Depth, angewandt auf einen neuen Stack. Für Teams, die Bestandsanwendungen prüfen, ist das die schnellste Frage an den eigenen Code: Wenn die Middleware morgen wegfällt, was ist dann noch geschützt? Fällt die ehrliche Antwort knapp aus, weiß man, wo als nächstes gearbeitet wird.

Für die Aufteilung der Verantwortung zwischen Entwickler und Host haben wir im Fall eine klare Sicht bekommen: Der Host kann Reverse-Proxy-Filterung, Update-Monitoring und Rollout-Disziplin liefern, die Einschätzung, welche Prüfpunkte in der Anwendung selbst nötig sind, bleibt beim Entwicklerteam. Wer beide Seiten nicht zusammenbringt, hat am Ende eine Lücke wie diese, aber niemanden, der zuständig ist.

Ein konkretes Detail ist beim zweiten Lesen interessant: Der Zeitablauf zwischen Meldung und Veröffentlichung war kurz, die First-Line-Patches (14.2.25 und 15.2.3) waren tagelang verfügbar, bevor die CVE öffentlich wurde. Wer Advisory-Feeds für die eingesetzten Frameworks liest, hatte also einen realen Vorsprung von mehreren Tagen. Genau dieser Vorsprung ist der Unterschied zwischen Routine-Patch und Sicherheitsvorfall, und er kostet praktisch nichts außer Aufmerksamkeit. Der zweite Blick gilt der Notfallseite: Ein Reverse-Proxy-Filter für einen einzelnen Header lässt sich in Minuten einrichten, wenn man weiß, wie die eigene Kette aufgebaut ist. Wer das erst im Ernstfall herausfinden muss, verliert Zeit, die dann fehlt.

Der Fall passt in eine Reihe, die wir in diesem Blog regelmäßig fortführen: Auch die kritischen Sicherheitsupdates 2025 zeigen dasselbe Muster, dass Patch-Disziplin im regelmäßigen Rhythmus wichtiger ist als die einzelne Panikreaktion. Wer das laufend abgedeckt haben möchte, findet auf unserer Support-Seite die Beschreibung des Betriebsmodells.

Quellen

• GitHub Security Advisory GHSA-f82v-jwr5-mffw (Authorization Bypass in Next.js Middleware), 21.03.2025, https://github.com/vercel/next.js/security/advisories/GHSA-f82v-jwr5-mffw (abgerufen 2026-11-01)

• NVD: CVE-2025-29927, https://nvd.nist.gov/vuln/detail/cve-2025-29927 (abgerufen 2026-11-01)

• Hersteller-Postmortem zum Middleware-Bypass, 2025, https://vercel.com/blog/postmortem-on-next-js-middleware-bypass (abgerufen 2026-11-01)

• oss-security-Mailingliste: CVE-2025-29927, 23.03.2025, https://www.openwall.com/lists/oss-security/2025/03/23/3 (abgerufen 2026-11-01)