Neun Schwachstellen angekündigt, sieben tatsächlich geschlossen, zwei verschoben, und das alles innerhalb einer einzigen Kalenderwoche. Wer produktiv mit Next.js arbeitet, kennt dieses Muster inzwischen aus dem September 2026: Erst ein kritischer Zero-Day-Patch, dann ein umfassendes Security Release. Das Next.js Sicherheitsupdate September 2026 markiert den vorläufigen Abschluss dieser Serie und bringt zwei neue Versionslinien: 15.5.27 für die Maintenance-LTS-Schiene und 16.3.8 für die Active-LTS-Schiene.
Am 30. September 2026 veröffentlichte das Next.js-Team bei Vercel das offizielle Security Release, nachdem bereits am 23. September eine Vorab-Ankündigung neun Schwachstellen benannt hatte. Aus technischen Gründen, Verzögerungen bei Upstream-Abhängigkeiten, wurden zwei dieser Lücken, eine kritische und eine hohe, nicht rechtzeitig geschlossen. Die finale Fassung behebt sieben Schwachstellen: eine mit hohem, fünf mit mittlerem und eine mit niedrigem Schweregrad. Dieser Artikel ordnet die Fakten ein, erklärt die Risiken und liefert konkrete Upgrade-Schritte.
Inhaltsverzeichnis
Key Takeaways
- Das Next.js Sicherheitsupdate September 2026 erschien am 30.9.2026 als Next.js 15.5.27 (Maintenance LTS) und 16.3.8 (Active LTS).
- Von ursprünglich neun angekündigten Schwachstellen wurden sieben final behoben: 1 hoch, 5 mittel, 1 niedrig; zwei Fixes (kritisch und hoch) verschoben sich wegen Upstream-Verzögerungen.
- Die gravierendste behobene Lücke ist eine SSRF-Schwachstelle in der Image Optimization (CVE-2026-94483), die nur Projekte mit konfiguriertem images.remotePatterns betrifft.
- Mehrere Cache-Poisoning- und Information-Disclosure-Bugs betreffen vor allem selbst gehostete Deployments, Webpack-Builds und Projekte mit aktivierten Cache Components.
- Das Release folgt auf einen Out-of-Band-Patch vom 22. September 2026 gegen eine kritische RCE-Lücke (CVE-2026-94545) in der next/og ImageResponse-API.
Was ist beim Next.js Sicherheitsupdate September 2026 passiert?
Der Ablauf folgte dem inzwischen etablierten Muster koordinierter Offenlegung: Zunächst informierte Vercel am 23. September 2026 vorab über neun identifizierte Schwachstellen, ohne technische Details preiszugeben, um Angreifern keinen Vorsprung zu verschaffen. Betroffenen Teams blieb damit eine Woche Vorlaufzeit zur internen Vorbereitung.
Am 30. September folgte die eigentliche Veröffentlichung mit vollständigen Advisories, CVE-Nummern und den gepatchten Paketen. Zwei der ursprünglich neun Lücken, eine kritische und eine mit hoher Schwere, ließen sich bis zu diesem Termin nicht final schließen, weil die zugrunde liegenden Fixes von externen Upstream-Abhängigkeiten abhingen, die noch nicht verfügbar waren. Das Next.js-Team entschied sich, die bereits fertigen sieben Fixes planmäßig auszuliefern, statt das gesamte Release zu verzögern.
Für die Praxis bedeutet das: Wer jetzt aktualisiert, schließt sieben reale Angriffsvektoren, sollte aber die Kommunikation des Next.js-Teams zu den beiden offenen Punkten weiter beobachten. Bestätigt wurde die Veröffentlichung zusätzlich durch den Netlify-Changelog, was für Teams mit Netlify-Hosting als unabhängiger Verifizierungspunkt dient.
Die sieben behobenen Schwachstellen im Detail
Die Fixes verteilen sich über mehrere Funktionsbereiche von Next.js, von der Bildoptimierung bis zum Dev-Server. Die folgende Tabelle fasst Schweregrad und Kernrisiko zusammen.
| Nr. | Schwachstelle | Schweregrad | CVE / GHSA |
|---|---|---|---|
| 1 | SSRF in Image Optimization | Hoch | CVE-2026-94483 (GHSA-cjq9-62q9-8jv4) |
| 2 | Cache Poisoning SSG/ISR (self-hosted) | Mittel | , |
| 3 | Cache Poisoning via Catch-all-Seiten | Mittel | , |
| 4 | Info Disclosure in Metadata-Image-Routen | Mittel | , |
| 5 | Cache-Leck bei verschachtelten 'use cache' | Mittel | , |
| 6 | Draft-Mode-Leck via pending 'use cache' | Mittel | , |
| 7 | Info Disclosure über MCP-Endpunkt (next dev) | Niedrig | CVE-2026-94486 (GHSA-39w2-rjm5-chcv) |
1. SSRF in Image Optimization (Hoch). Wenn images.remotePatterns so konfiguriert ist, dass eine Angreifer-kontrollierte Remote-URL als zulässig durchgeht, kann die Image-Optimization-Komponente dazu gebracht werden, Requests gegen beliebige Ziele zu senden, etwa gegen private IP-Bereiche im internen Netzwerk. Ist images.remotePatterns gar nicht gesetzt, besteht keine Angriffsfläche.
2. und 3. Cache Poisoning. Zwei verschiedene Mechanismen erlauben es, den geteilten Response-Cache zu vergiften: einmal bei SSG/ISR-Seiten im Pages Router auf selbst gehosteten Deployments, einmal über Root-Level-Catch-all-Seiten in Kombination mit SSG/ISR. Im zweiten Fall reicht ein einzelner unauthentifizierter, präparierter Request, um Inhalte für andere Nutzer zu verfälschen und einen anhaltenden Denial-of-Service auszulösen. Vercel-gehostete Apps sind von Fall 2 nicht betroffen.
4. Information Disclosure in Metadata-Image-Routen. Über einen dynamicParams-Bypass lassen sich bei App-Router-Routen wie opengraph-image oder twitter-image Informationen offenlegen, allerdings ausschließlich bei Apps, die mit Webpack statt Turbopack gebaut wurden.
5. Cache-Leck bei verschachtelten 'use cache'-Funktionen. Bei aktivierten Cache Components kann der Cache-Key einer äußeren Funktion einen Root-Parameter fälschlich auslassen. Die Folge: Nutzer erhalten Inhalte, die eigentlich für einen anderen Parameterwert bestimmt waren.
6. Draft-Mode-Leck. Ein noch "ausstehender" Cache-Fill unter 'use cache' kann dazu führen, dass Draft-Mode-Vorschauinhalte in reguläre, persistente Antworten durchsickern, relevant für Seiten mit aktivierten Cache Components bzw. experimental.useCache.
7. Information Disclosure über den MCP-Endpunkt (Niedrig). Der Dev-Server next dev prüft die Origin eingehender Requests an seinem Model-Context-Protocol-Endpunkt nicht. Besucht ein Entwickler im Browser eine bösartige Website, kann diese Projektpfade, Code-Schnipsel aus Fehlermeldungen, das Routen-Inventar und Dev-Logs auslesen. Produktions-Deployments sind nicht betroffen, nur die lokale Entwicklungsumgebung.
Wer ist betroffen? Scope-Check für das Next.js Sicherheitsupdate September 2026
Nicht jedes Projekt ist von allen sieben Lücken gleichermaßen betroffen. Ein kurzer Scope-Check hilft bei der Priorisierung:
- images.remotePatterns gesetzt? Wenn ja, prüfen Sie dringend die SSRF-Lücke (Nr. 1), das ist der Fix mit dem höchsten Schweregrad in diesem Release.
- Self-hosted statt Vercel? Dann sind die Cache-Poisoning-Probleme (Nr. 2, teilweise Nr. 3) relevant.
- Root-Level Catch-all-Seiten mit SSG/ISR? Betrifft praktisch jedes Hosting-Modell, nicht nur self-hosted.
- Build mit Webpack statt Turbopack? Dann ist die Metadata-Info-Disclosure (Nr. 4) zu beachten.
- Cache Components bzw. experimental.useCache aktiv? Prüfen Sie Nr. 5 und Nr. 6.
- next dev lokal im Einsatz? Jeder Entwickler-Rechner ist potenziell für Nr. 7 exponiert, unabhängig vom Produktionssetup.
Eine pauschale "Alle sind betroffen"-Aussage wäre übertrieben, die meisten Lücken greifen nur bei bestimmten Konfigurationen. Dennoch gilt: Ein Upgrade behebt alle sieben Punkte gleichzeitig, unabhängig davon, welche Konfiguration aktuell genutzt wird.
Handlungsempfehlung: So aktualisieren Sie jetzt
Der Fix ist technisch unkompliziert. Je nach eingesetzter Versionslinie reicht ein einzelner Befehl:
npm install next@15.5.27
für Projekte auf der 15.5-Linie, beziehungsweise
npm install next@16.3.8
für Projekte auf der 16.3-Linie. Nach der Installation ist ein erneutes Deployment erforderlich, damit der Patch in Produktion wirksam wird, ein reiner Dependency-Update ohne Redeploy schließt keine Lücke.
Empfohlene Reihenfolge für Teams:
- Versionslinie identifizieren (15.5 oder 16.3) und entsprechenden Befehl ausführen.
- Konfiguration auf images.remotePatterns, Webpack-Build und Cache-Components-Nutzung prüfen, um die Dringlichkeit einzuschätzen.
- Staging-Deployment testen, insbesondere Image-Optimization- und Cache-Verhalten.
- Produktions-Redeploy durchführen.
- Bei selbst gehosteten Setups: Cache-Invalidierung nach dem Update prüfen, um bereits vergiftete Cache-Einträge zu entfernen.
- Lokale Entwicklungsumgebungen (next dev) ebenfalls aktualisieren, auch wenn keine Produktionsgefahr besteht.
Da zwei Schwachstellen, eine kritische, eine hohe, noch offen sind, sollten technische Verantwortliche die offiziellen Kanäle (nextjs.org/blog und den jeweiligen Hosting-Changelog) in den kommenden Wochen weiter beobachten.
Einordnung: Die Sicherheitsupdate-Serie im September 2026
Das Security Release vom 30. September steht nicht isoliert. Nur acht Tage zuvor, am 22. September 2026, hatte das Next.js-Team bereits ein Out-of-Band-Update veröffentlicht: Next.js 16.3.6 und 15.5.26 schlossen eine kritische Remote-Code-Execution-Schwachstelle (CVE-2026-94545, CVSS 9.5) in der next/og ImageResponse-API. Ursache war unzureichendes Escaping in der von der Satori-Bibliothek erzeugten SVG-Ausgabe.
Damit erlebte das Next.js-Ökosystem innerhalb eines Monats zwei separate Sicherheitsereignisse: einen ungeplanten kritischen Hotfix und ein geplantes, umfassendes Monats-Release. Für technische Entscheider ergibt sich daraus eine klare Lehre: Patch-Management-Prozesse für Next.js sollten nicht auf einen einzelnen jährlichen oder quartalsweisen Rhythmus ausgelegt sein, sondern kurzfristige Out-of-Band-Patches einschließen können. Die Tatsache, dass zwei Fixes aus der Vorab-Ankündigung vom 23. September in die finale Fassung vom 30. September nicht rechtzeitig einflossen, zeigt zudem, dass Upstream-Abhängigkeiten auch für ein gut organisiertes Framework-Team ein limitierender Faktor bleiben.
Fazit
Mehr Hintergrund zum Next.js-Oekosystem im Vergleich mit anderen Backend-Stacks liefert unser Vergleich von PHP, Node.js und MySQL für Backend-Einsteiger.Das Next.js Sicherheitsupdate September 2026 schließt sieben konkrete Schwachstellen, von einer SSRF-Lücke in der Image Optimization mit hohem Schweregrad bis zu einem niedrig eingestuften Informationsleck im Dev-Server. Keine der Lücken erfordert Panik, aber jede verdient eine nüchterne Prüfung der eigenen Konfiguration. Besonders images.remotePatterns, der Hosting-Modus (self-hosted versus Vercel), der verwendete Bundler (Webpack versus Turbopack) und die Nutzung von Cache Components entscheiden darüber, welche der sieben Fixes für ein konkretes Projekt tatsächlich sicherheitsrelevant sind.
Der konkrete nächste Schritt ist einfach: npm install next@15.5.27 oder npm install next@16.3.8 ausführen, anschließend neu deployen und die eigene Konfiguration anhand der oben genannten Scope-Kriterien durchgehen. Angesichts des vorangegangenen kritischen Patches vom 22. September empfiehlt sich zusätzlich, den next.js-Versionsstand im gesamten Projektportfolio einmalig zu auditieren, damit kein Deployment mit veralteten Paketen zurückbleibt. Wer diese Schritte zeitnah umsetzt, reduziert die Angriffsfläche auf das in diesem Release dokumentierte Minimum und ist für die noch ausstehenden zwei Fixes vorbereitet, sobald das Next.js-Team sie nachliefert.
