Next.js hat 13 Sicherheitslücken geschlossen. Self-hosted Teams tragen die größte Last.

Am 7. Mai hat Vercel ein koordiniertes Sicherheitsrelease veröffentlicht, das 13 Advisories für Next.js und React Server Components umfasst. Das Paket enthält schwerwiegende Schwachstellen für Denial-of-Service, Server-Side Request Forgery, Cache-Poisoning sowie mehrere Middleware-Bypass-Fehler im App Router. Wenn Ihr Team Next.js selbst auf Node betreibt, haben Sie am meisten Handlungsbedarf.

Die Korrekturen sind in 15.5.18 und 16.2.6 enthalten. React-Nutzer mit react-server-dom sollten je nach verfolgter Version auf 19.0.6, 19.1.7 oder 19.2.6 wechseln. Die Versionen 13.x und 14.x erhalten keine Patches, sodass alle, die noch darauf setzen, ein Upgrade planen müssen, anstatt auf einen Backport zu warten.

Was das Paket tatsächlich enthält

Die meistgenannte CVE ist CVE-2026-23870, eine schwerwiegende DoS-Schwachstelle in der React-Flight-Protokoll-Deserialisierung. Eine speziell gestaltete HTTP-Anfrage an eine beliebige App-Router-Serverfunktion kann einen CPU-Kern blockieren. Schlimm, aber eine bekannte Art von Fehler, die ein WAF oder ein Rate-Limiter abschwächen kann.

Besondere Aufmerksamkeit verdient die Klasse der Middleware-Bypasses. Die Advisories beschreiben Varianten, bei denen .rsc- und Segment-Prefetch-URLs zur selben Seite wie eine normale Anfrage aufgelöst werden, jedoch die Middleware-Matcher-Regeln umgehen. Konkret: Wenn Ihre middleware.ts das einzige Hindernis zwischen einer nicht authentifizierten Anfrage und einer geschützten Seite ist, kann ein Angreifer denselben Inhalt über einen anderen Transport abrufen und Zugang erlangen. Es gibt eine verwandte Pages-Router-Variante, die mit der i18n-Locale-Verarbeitung zusammenhängt, sowie ein Follow-up-Advisory für den Turbopack-Codepfad, da der ursprüngliche Fix diesen nicht abdeckte.

Die übrigen Advisories betreffen SSRF über WebSocket-Upgrade-Anfragen auf selbst gehostetem Node (Vercel-gehostete Apps sind nicht betroffen), DoS in der Image-Optimization-API, XSS und Cache-Poisoning von RSC-Antworten.

Warum „Middleware als Authentifizierung“ Teams immer wieder schadet

Bei unseren Pentesting-Einsätzen ist dies eines der ersten Muster, das wir prüfen, wenn Next.js im Scope ist. Das Muster wiederholt sich: Eine einzelne middleware.ts prüft das Session-Cookie, leitet bei fehlendem Cookie zur Anmeldung weiter, und das Team betrachtet alle darunter liegenden Routen als geschützt. Es wirkt sauber. Es liest sich gut in PRs. Und es hat meistens eine Lücke durch Transportvarianten, die jemand schließlich findet.

Middleware in Next.js ist eine Routing-Angelegenheit. Sie läuft früh, hat begrenzte APIs und hatte historisch gesehen Eigenheiten dabei, wie Matcher auf interne Anforderungsformen angewendet werden (RSC-Payloads, Prefetches, dynamische Segmente, locale-präfixierte Pfade). Jede dieser Eigenheiten hat sich irgendwann als CVE-Klasse manifestiert. Das aktuelle Paket ist die jüngste Erinnerung daran.

Wenn wir cloud-native Apps mit dem App Router entwickeln, behandeln wir Middleware als schnellen Vorfilter und platzieren echte Autorisierungsprüfungen im Route-Handler, der Server-Aktion oder der Server-Komponente selbst. Der Cookie-Wert wird zur Eingabe, nicht zum Urteil. Diese zusätzliche Prüfung kostet kaum etwas und eliminiert eine ganze Familie von Bypass-Risiken.

Was Sie diese Woche tun sollten

Eine kurze Liste:

1. Aktualisieren Sie next auf 15.5.18 oder 16.2.6. Wenn Sie über den OpenNext-Adapter mit i18n auf dem Pages Router veröffentlichen, aktualisieren Sie diesen ebenfalls auf 5.15.11.
2. Wenn Sie direkt von react-server-dom-* abhängen, wählen Sie den passenden 19.x-Patch-Stand (19.0.6, 19.1.7 oder 19.2.6).
3. Planen Sie den Umstieg von 13.x oder 14.x. Diese Branches erhalten keine Korrekturen.
4. Prüfen Sie Ihre middleware.ts. Wenn eine Route nur durch Middleware geschützt ist, fügen Sie eine serverseitige Authentifizierungsprüfung im Route-Handler, der Server-Aktion oder dem Layout hinzu. Überspringen Sie dies nicht, nur weil Sie bereits ein Upgrade durchgeführt haben.
5. Überprüfen Sie bei selbst gehostetem Node die Edge- oder Proxy-Logs auf ungewöhnliche .rsc-Anfragen, WebSocket-Upgrades zu unerwarteten Ursprüngen und Traffic-Spitzen bei der Image-Optimierung. Die SSRF- und DoS-Probleme werden zuerst in selbst gehosteten Umgebungen auftreten.

Hinweis zu Self-Hosted vs. Plattform

Mehrere dieser Schwachstellen betreffen explizit selbst gehostetes Node. Vercel gibt an, dass gehostete Projekte bereits vor dem Patch durch WAF-Regeln geschützt waren. Netlify gibt an, dass einige der Advisories für ihr serverloses Modell gar nicht relevant sind. Diese Unterschiede sind es wert, beim Entscheid über den Betriebsort von Next.js berücksichtigt zu werden.

In unserer cloud-nativen Entwicklungsarbeit haben wir viele Teams gesehen, die sich aus Kosten- oder Compliance-Gründen für Self-Hosting entschieden haben (insbesondere Schweizer Unternehmenskunden), und das ist eine legitime Entscheidung. Aber Sie tragen mehr Verantwortung für die Laufzeitsicherheit selbst, und der Patch-Rhythmus wird Teil des Betriebsbudgets, nicht ein vierteljährlicher Nachgedanke.

Wenn Ihnen die Absicherung und das regelmäßige Patchen eines selbst gehosteten Next.js-Stacks bekannt vorkommt, sprechen Sie mit uns. Wir erledigen diese Arbeit im Rahmen von Web- und Mobile-Projekten sowie Sicherheitsprüfungen, und die Antwort ist selten „mehr Middleware“.