Next.js Sicherheitsupdate: Welcher der 13 Hinweise wirklich zählt

Next.js Sicherheitsupdate: die Lage in einem Satz und die entscheidende Triage

Next.js veröffentlichte am 6. Mai 2026 insgesamt 13 koordinierte Sicherheitshinweise, am 7. Mai folgten die gepatchten Releases 16.2.6 und 15.5.18. Die Berichterstattung konzentrierte sich auf CVE-2026-44578, die WebSocket-SSRF – schließlich liefert sie das eindrucksvollere Bild: Ein Angreifer stuft eine Verbindung hoch, der Server steuert selbst 169.254.169.254 an, und der Metadatenendpunkt gibt IAM-Zugangsdaten zurück. Dramatisch.

Allerdings betrifft das nur selbst gehostete Installationen. Bei einem von Vercel verwalteten Deployment mit vorgeschaltetem Cloudflare ist der Pfad nicht erreichbar. Meine Leser kann stattdessen die kaum diskutierte, als Moderate eingestufte RSC-Cache-Poisoning-Lücke treffen: Eine manipulierte RSC-Antwort bleibt nicht auf die Anfrage des Angreifers beschränkt. Sie landet im gemeinsam genutzten Edge-Cache und wird an jeden Besucher ausgeliefert, bis ich das Tag lösche.

Wer Next.js >= 13.4.13 einsetzt, sollte noch in dieser Woche aktualisieren. Offen ist nur, auf welche Version, in welcher Reihenfolge und was anschließend erneut getestet werden muss. Die folgende Triage entspricht der Matrix, die ich für omidsaffari.com durchgearbeitet habe: App Router auf Vercel, davor Cloudflare mit Cache-Tag-Löschung und einem Revalidate-Webhook. Das Ergebnis hat meine Prioritäten weg von der Schlagzeilen-CVE verschoben.

Was das für Gründer ohne technischen Hintergrund bedeutet

Ist das Produkt eine Next.js-App, gehört das Thema noch in diese Woche und nicht ins Backlog. In Geld gemessen geht es weder um Latenz noch um Entwicklerstunden, sondern um verlorenes Kundenvertrauen: Ein einziger Screenshot einer Marketingseite mit Angreiferinhalten oder eine Meldung, dass jemand ohne Sitzung auf /admin gelangt ist – und schon besteht die nächste Woche aus Erklärungen statt aus Verkauf.

An das Engineering-Team gehört genau eine Frage: „Laufen wir auf 16.2.6 oder 15.5.18, und wurde der Edge-Cache nach dem Deployment geleert?“ Fällt die Antwort ungenauer aus – „wir patchen“, „ist in Arbeit“, „die SSRF betrifft uns nicht“ –, ist die Aufgabe nicht abgeschlossen. Selbst gehostete Deployments (ECS, EC2, Kubernetes und alles, was next start auf einem selbst betriebenen Server ausführt) fallen in die höhere Risikoklasse, weil dort neben allen anderen Lücken auch die SSRF greift. Welche Betriebsform vorliegt, sollte sich in zehn Sekunden beantworten lassen.

Die 13 Hinweise – sortiert nach ihrer tatsächlichen Reichweite im eigenen Stack

Der Fehler in all den derzeit kursierenden Beiträgen nach dem Muster „13 CVEs, sofort patchen“: Sie behandeln die Liste als gleichförmig. Das ist sie nicht. Jeder Hinweis hat eine Voraussetzung – Self-Hosting, Turbopack, Cache Components, CSP-Nonces oder i18n. Das reale Risiko umfasst nur die Teilmenge, deren Bedingungen zum eigenen Deployment passen. Hier sind dieselben 13 Hinweise nach ihren Auslösebedingungen gruppiert.

Cluster aus Middleware- und Proxy-Umgehungen (5 Hinweise, überwiegend High). Am schwersten wiegt GHSA-267c-6grr-h53f: Damit kann eine Segment-Prefetch-URL im App Router an den Authentifizierungsprüfungen der Middleware vorbeigeroutet werden. Zum Cluster zählen außerdem der am 7. Mai veröffentlichte Nachtrag zu einer unvollständigen Behebung (GHSA-26hh-7cqf-hhc6) für Turbopack, eine Umgehung über den Pfad der i18n-Standard-Locale im Pages Router sowie eine Parameter-Injection-Umgehung bei dynamischen Routen. Voraussetzung: Next.js-Middleware erzwingt Authentifizierung oder Rewrites. Das trifft auf fast alle zu.

SSRF, CVE-2026-44578. Der WebSocket-Upgrade-Handler des selbst gehosteten Servers erreicht interne HTTP-Endpunkte auf Port 80, darunter Cloud-Metadaten. Betroffen: 13.4.13+ bis <15.5.16 sowie 16.0.0–<16.2.5, ausschließlich selbst gehostet. Für von Vercel verwaltete Deployments ist bestätigt, dass sie nicht betroffen sind.

Denial of Service, zwei Hinweise. Beim ersten handelt es sich um den vorgelagerten RSC-DoS; der zweite ist ein DoS durch ausgeschöpfte Verbindungen in Apps, die Cache Components aktiviert haben (High, GHSA-q4gf-8mx6-v5v3). Voraussetzung für den zweiten: Cache Components wurden ausdrücklich eingeschaltet – bei den meisten Apps ist das nicht der Fall.

RSC Cache Poisoning (Moderate). Kollisionen beim Cache-Busting in der RSC-Payload-Pipeline ermöglichen es einer präparierten Anfrage, eine zwischengespeicherte Antwort zu manipulieren. Voraussetzung: RSC-Antworten werden irgendwo nachgelagert gecacht – in einem CDN, Reverse Proxy, an Vercels Edge oder bei Cloudflare. Genau diese Lücke ist in meinem Stack relevant.

XSS, zwei Hinweise. CVE-2026-44581 (Moderate) betrifft App-Router-Apps, die CSP-Nonces erzeugen; hinzu kommt eine XSS-Lücke in beforeInteractive-Skripten, wenn diese nicht vertrauenswürdige Eingaben verarbeiten. Voraussetzungen: Entweder wird eine CSP mit Nonces ausgeliefert oder eine Benutzereingabe an ein beforeInteractive-Script-Tag übergeben.

Entscheidend ist deshalb, die erfüllten Voraussetzungen für das eigene Deployment festzuhalten. Bei omidsaffari.com sieht die Liste so aus: Cluster der Middleware-Umgehungen (ja), SSRF (nein, Hosting bei Vercel), RSC-DoS (ja, vorgelagert), Cache-Components-DoS (nein, nicht aktiviert), RSC Cache Poisoning (ja, mit verstärkter Wirkung), CSP-Nonce-XSS (ja), beforeInteractive-XSS (nein). Von acht High-/Moderate-Hinweisen bleiben fünf übrig, die mich betreffen – und die Lücke mit dem größten Schadensradius ist nicht die bekannte.

Warum die viel diskutierte Next.js SSRF meist nicht das Problem ist – RSC Cache Poisoning aber schon

CVE-2026-44578 setzt voraus, dass der Node-seitige next start-Server das WebSocket-Upgrade verarbeitet und der Weiterleitung folgt. Vercel leitet meine Anfragen nicht so durch diesen Server, dass der SSRF-Pfad erreichbar wäre: Die Plattform terminiert WebSockets, und der Metadatenendpunkt liegt zusätzlich hinter IMDSv2 mit einem Hop-Limit, das diesen Pfad ohnehin nicht überstehen würde. Ein vorgeschaltetes Cloudflare ändert daran nichts. In einer Vercel-Cloudflare-Topologie lässt sich der dramatische Screenshot nicht reproduzieren.

Beim RSC Cache Poisoning verhält es sich genau umgekehrt. Die Schwachstelle liegt in dem Pfad der Anfrageverarbeitung, den jeder durchläuft. Das Ergebnis ist eine manipulierte RSC-Payload – also der serialisierte React-Baum, den die Leser erhalten. Auf meiner Website bleibt diese Payload nicht bei der Anfrage des Angreifers, sondern landet hier:

Cache-Control: public, s-maxage=300, stale-while-revalidate=86400
Cache-Tag: article:nextjs-may-2026-security-triage

s-maxage=300 bedeutet, dass Cloudflare die Antwort fünf Minuten lang vorhält. Mit stale-while-revalidate=86400 kann sie nach Ablauf noch einen Tag lang weiter ausgeliefert werden, während im Hintergrund die Revalidierung läuft. Über Cache-Tag lösche ich den Eintrag: Veröffentliche ich eine neue Revision, löst der Revalidate-Webhook eine Tag-Löschung aus und das Objekt verschwindet.

Was geschieht nun mit einer manipulierten Antwort? Der Angreifer ruft eine Route auf, bei der die Cache-Busting-Kollision greift. Cloudflare erkennt eine cachefähige Antwort, speichert sie unter dem Cache-Schlüssel dieser URL und versieht sie mit article:<slug>. Danach erhält jeder weitere Besucher dieses Slugs die manipulierte RSC-Payload direkt von der Edge – nicht vom Origin, nicht über irgendeine Middleware und nicht durch eine WAF-Regel, die ich zehn Minuten später ergänze. Das manipulierte Objekt liegt bereits nachgelagert. Es bleibt dort, bis das s-maxage-Fenster endet oder meine Veröffentlichungs-Pipeline eine Löschung auslöst. WAF-Regeln am Origin bewirken nichts bei einer Antwort, die schon in 300 PoPs liegt.

Gefährdet ist damit die veröffentlichte Inhaltsoberfläche – der Output der Content Engine – und nicht irgendeine interne API. Die Liste der 13 Hinweise stuft die SSRF als High und diese Lücke als Moderate ein. Auf einer RSC-Website mit vorgeschaltetem Cache kehrt sich die praktische Priorität um.

Das Next.js Sicherheitsupdate im Detail – einschließlich der Turbopack-Falle

Der erste Schritt ist die Ermittlung der tatsächlich installierten Version. Bei einer Caret-Versionsspanne sagt package.json nicht zuverlässig, welche Version aufgelöst wurde; maßgeblich ist die Lockdatei.

bun pm ls | grep next
# or
npm ls next

Anschließend wird exakt auf 16.2.6 (Next.js-16-Linie) oder 15.5.18 (Next.js-15-Linie) festgelegt. Nicht 16.2.5. Nicht 15.5.16.

bun add next@16.2.6
# or
npm install next@16.2.6 --save-exact

Der Grund für diese exakte Festlegung ist eine Falle, die kaum erwähnt wird. Die ursprünglichen 13 Hinweise wurden am 6. Mai in 16.2.5 / 15.5.16 behoben. Am 7. Mai veröffentlichte Vercel GHSA-26hh-7cqf-hhc6 – den Nachtrag zu einer unvollständigen Behebung der Segment-Prefetch-Middleware-Umgehung, die weiterhin ausnutzbar war, wenn Turbopack die Anfrage auslieferte. Ohne Turbopack boten 16.2.5 / 15.5.16 bereits Schutz. Mit Turbopack war das nicht der Fall. Vollständig behoben ist die Lücke erst in 16.2.6 / 15.5.18.

Für die 13.x- oder 14.x-Linie wird kein Patch mehr erscheinen. Vercel nimmt keine Rückportierung vor. Die Abhilfe besteht in einer Migration auf 15.x oder 16.x – und sie sollte als Migration geplant werden, nicht als bun update. Bei einer nicht trivialen App ist mindestens eine Woche einzuplanen; die Zahl möglicher Inkompatibilitäten ist real, besonders bei Middleware-Matchern und den Caching-Standards des App Routers.

Nach dem Deployment muss der Edge-Cache geleert werden. Dieser Schritt fehlt in jedem anderen Beitrag, den ich in dieser Woche dazu gelesen habe. Ohne Löschung bleiben RSC-Payloads, die Cloudflare vor dem Patch gespeichert hat, weiterhin vorhanden. Wurde die Lücke während dieses Zeitfensters ausgenutzt, können sie manipuliert sein und bis zum Ablauf von s-maxage weiter von der Edge ausgeliefert werden. In meinem Stack geschieht die Löschung so:

curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything": true}'

Danach folgt die Prüfung. Dafür eine durch Middleware-Authentifizierung geschützte Route auswählen, die Segment-Prefetch-URL-Form aus dem Sicherheitshinweis nachbilden und gegen die Produktion abspielen. Erwartet wird eine 401 / 302 oder der jeweils von der Middleware für nicht authentifizierte Anfragen gelieferte Status. Kommt stattdessen eine 200 mit Inhalt zurück, greift der Middleware-Patch nicht. Dann liegt ein Deployment-Problem vor, kein Next.js-Problem.

Was unter 16.2.6 tatsächlich kaputtgehen kann

Diese Releases sind keine reinen Sicherheitspatches. Mehrere Korrekturen verändern bewusst das Routing und das Verhalten der Cache-Schlüssel, denn genau dort lagen die Schwachstellen. Mit Abweichungen ist daher zu rechnen.

Strengere Middleware-Matcher für .rsc- und Segment-Prefetch-URLs. Die Behebung der Segment-Prefetch-Umgehung hat das Matching-Verhalten verändert. Matcher-Muster, die von der früheren Form ausgingen, müssen erneut geprüft werden – insbesondere negative Lookaheads zum Ausschluss von _next-Pfaden, bei denen angenommen wurde, .rsc liege immer darunter. Ich musste einen Matcher erweitern, damit er das Segment-Prefetch-Suffix einer geschützten Route ausdrücklich erfasst. Eine Korrektur von fünf Minuten, die ohne Replay-Test jedoch als unbemerkte Regression geblieben wäre.

Umgang mit CSP-Nonces. Der XSS-Fix (CVE-2026-44581) verändert die Weitergabe von Nonces beim Rendern im App Router. Werden Nonces in der Middleware erzeugt und in einer Script-Komponente referenziert, sollte die CSP nach dem Deployment einen Tag lang im Report-only-Modus laufen. Bei mir traten keine Verstöße auf, allerdings ist die Änderung real, und ein Team musste nach eigener Aussage seinen Ablauf zur Nonce-Erzeugung anpassen.

Verhaltensänderung bei Cache Components. Wer Cache Components nutzt und damit vom Fix für den DoS durch ausgeschöpfte Verbindungen betroffen ist, muss berücksichtigen, dass sich die Bündelung von Cache Misses unter Last ändert. Die Hot Paths sollten erneut getestet werden. Ich selbst nutze Cache Components nicht und musste das daher nicht tun.

Diese Prüfliste habe ich abgearbeitet, bevor das Upgrade für mich abgeschlossen war:

[ ] next version pinned to 16.2.6 in lockfile
[ ] middleware auth replay on /admin via segment-prefetch URL → 401
[ ] middleware auth replay via .rsc URL → 401
[ ] RSC cache key sanity: same URL, two clients, identical payload
[ ] forced edge purge after deploy
[ ] CSP report-only on for 24h with no new violations
[ ] one full revalidate cycle on a high-traffic page

Eine Staging-Runde sollte fest eingeplant werden. Dieses Patch-Upgrade ist nicht risikofrei, weil die Sicherheitskorrekturen Routing und Cache-Schlüssel bewusst verändern. Ob daraus ein Deployment am Dienstagnachmittag oder ein Vorfall am Dienstagabend wird, entscheidet sich daran, ob die Authentifizierungspfade vor der Produktionsfreigabe per Replay getestet wurden.

Patchen statt auf die WAF zu vertrauen – und die strukturelle Lehre daraus

Vercel hat für dieses Release keine WAF-Regeln veröffentlicht. Laut Changelog ist Patchen die einzige vollständige Abhilfe – zu Recht, denn keine dieser Schwachstellen lässt sich zuverlässig an der Edge filtern: Die bösartigen Anfrageformen überschneiden sich zu stark mit legitimen Anfragen. Cloudflare veröffentlichte am 6. Mai WAF-Regeln und Gegenmaßnahmen in den Framework-Adaptern, allerdings ausdrücklich als Defense in Depth und nicht als Ersatz für das Upgrade. Der Wortlaut ist entscheidend: Im Cloudflare-Changelog steht klar, dass die WAF-Regeln die Angriffsfläche während des Rollout-Zeitfensters reduzieren, nicht danach.

Darin liegt die strukturelle Lehre dieser Woche. Kann ein Stack innerhalb eines einzigen Nachmittags das Framework aktualisieren, neu deployen und seinen Edge-Cache leeren, wird aus der koordinierten Offenlegung von 13 CVEs ein Tagesordnungspunkt für Dienstag. Ist das nicht möglich – weil das Upgrade eine Migration erfordert, kein Mechanismus zum Löschen existiert oder die Deployment-Pipeline manuelle Freigaben enthält –, bleibt der Stack so lange exponiert, wie der Rollout dauert. Tage. Manchmal Wochen.

Es ist dasselbe Muster wie beim Argument zum Schadensradius von Agenten: Strukturell schnelle Wiederherstellung ist reaktivem Filtern überlegen. Weder lässt sich jede bösartige Anfrage verhindern noch jeder fehlerhafte Agentenaufruf. Entscheidend ist ein System, bei dem das Reaktionsfenster nach einem Treffer in Minuten gemessen wird und die Topologie den Schadensradius begrenzt – nicht die Hoffnung.

Noch heute aktualisieren. Auf 16.2.6 oder 15.5.18 festlegen. Anschließend den Cache leeren. Die CVE aus den Screenshots ist die falsche Sorge; entscheidend ist die als Moderate eingestufte Lücke, die jede zwischengespeicherte Seite berührt.