Next.js 15 End of Life: Was das Support-Ende für Unternehmen bedeutet und was jetzt zu tun ist

Ihre Website oder Web-App läuft auf Next.js. Im Tagesgeschäft merken Sie davon nichts — bis jemand fragt, ob das System noch gepflegt wird. Seit Mittwoch, dem 21. Oktober 2026, ist die Antwort unbequem: Die Maintenance-Phase von Next.js 15 endet nach der offiziellen Support-Policy zwei Jahre nach dem Erst-Release, also genau an diesem Tag. Was das konkret bedeutet, was Sie sofort tun sollten und wie aufwendig ein Upgrade auf Next.js 16 wirklich ist — darum geht es in diesem Artikel.

Ein Hinweis vorab zur Begrifflichkeit: Vercel selbst verwendet den Begriff „End of Life" auf der Policy-Seite nicht. Dort heißt es „Maintenance LTS" für die aktive Support-Phase und „Unsupported versions" für alles, was danach kommt. Der Begriff „End of Life" ist der geläufige Suchbegriff, wie ihn etwa endoflife.date verwendet — er trifft die Sache, aber er stammt nicht aus Vercels eigenem Sprachgebrauch.

Was die Next.js Support-Policy tatsächlich aussagt

Die offizielle Support-Policy von Next.js unterscheidet zwei Phasen für jede Major-Version:

Active LTS gilt, solange eine Major-Version die aktuellste ist. In dieser Phase erhält sie neue Features, reguläre Bugfixes, Performance-Verbesserungen und Security-Patches. Maintenance LTS beginnt, sobald eine neue Major-Version veröffentlicht wird — ab diesem Moment bekommt die Vorgängerversion nur noch kritische Bugfixes und wesentliche Sicherheitsupdates. Diese Phase dauert zwei Jahre ab dem Erst-Release der jeweiligen Version.

Next.js 15 erschien am 21. Oktober 2024. Zwei Jahre später, am 21. Oktober 2026, endet damit rechnerisch die Maintenance-LTS-Phase. Die Policy-Seite selbst nennt dieses Datum nicht ausdrücklich — die Tabelle dort führt 15.x am 23. Oktober 2026 weiterhin unter „Supported versions" mit Status „Maintenance LTS". Auch einen offiziellen Blogpost oder eine Advisory-Meldung von Vercel, die das Ende von Next.js 15 explizit kommuniziert, gibt es nach aktuellem Stand nicht.

Die Policy enthält zudem eine seltene Ausnahme: „In rare circumstances, depending on the severity of the underlying bug, we will patch versions of Next.js that are outside of our LTS policy." Das ist kein Versprechen, sondern ein Vorbehalt für Extremfälle — darauf verlassen sollte sich niemand.

Zur Versionsübersicht (Stand 23. Oktober 2026):

Die letzte veröffentlichte 15.x-Version ist 15.5.28 vom 14. Oktober 2026. Sie schließt alle bis zu diesem Datum bekannten Sicherheitslücken. Wer auf diesem Stand ist, läuft nicht sofort in Gefahr — aber ab dem 21. Oktober 2026 sind laut Policy keine weiteren Sicherheitsupdates für 15.x mehr zugesagt.

Warum das mehr als eine technische Formalität ist

Next.js hatte 2026 eine außergewöhnlich dichte Folge kritischer Sicherheitslücken. Allein zwischen Mai und Oktober 2026 gab es Security-Releases in fünf unterschiedlichen Monaten, darunter zwei Out-of-Band-Patches außerhalb des regulären Zyklus. Ein Auszug aus den relevantesten Advisories:

• GHSA-2464-fhr4-w9xw / CVE-2026-96889 (kritisch, 14.10.2026): Unauthentifizierte Remote Code Execution in der Image Optimization API bei SVG-Dateien. Betroffen: alle Versionen ab 10.0.0 bis einschließlich 15.5.27. Gepatcht in 15.5.28.
• GHSA-p3m5-59mp-jv5r (hoch, 14.10.2026): Denial of Service im App Router mit Server Actions. Ebenfalls gepatcht in 15.5.28.
• GHSA-2xp9-vwfh-vxw4 (kritisch, 25.08.2026): RCE in der Image Optimization API bei AVIF-Dateien. Gepatcht in 15.5.24.
• GHSA-p293-qw3h-jr36 / CVE-2026-75604 (kritisch, 25.08.2026): RCE auf Windows-gehosteten Servern. Gepatcht in 15.5.24.
• CVE-2025-29927 (kritisch, März 2025): Middleware-Autorisierungs-Bypass. Gepatcht in 15.2.3.

Wer heute auf 15.5.28 läuft, ist gegen alle diese Lücken geschützt. Das Problem beginnt danach: Wird künftig eine neue Schwachstelle in Next.js 15 entdeckt — und die Frequenz der letzten Monate lässt das wahrscheinlich erscheinen — gibt es laut Policy keinen zugesagten Patch mehr. Die Lücke bleibt offen, bis entweder Vercel im Ausnahmefall doch reagiert oder das Projekt auf Next.js 16 migriert ist.

Das ist kein theoretisches Risiko. Wer mit OWASP oder dem BSI-IT-Grundschutz arbeitet, weiß: Ein bekanntes Sicherheitsproblem ohne Patch-Perspektive ist ein Compliance-Risiko, das dokumentiert und bewertet werden muss — unabhängig davon, wie wahrscheinlich eine Ausnutzung im konkreten Fall ist.

Was jetzt sofort zu tun ist — bevor Sie das Upgrade planen

Bevor ein Upgrade geplant wird, braucht es eine klare Bestandsaufnahme. In vielen KMU sind über die Jahre mehrere Next.js-Projekte entstanden: eine Marketing-Website, ein Kundenshop, vielleicht ein internes Dashboard oder eine Buchungsanwendung. Nicht alle laufen zwingend auf derselben Version.

Schritt 1: Projekte inventarisieren. Welche Systeme laufen auf Next.js, welche Version hat jedes, wo liegt das Hosting und welche Abhängigkeiten (npm-Pakete, CMS-Anbindungen, APIs) bestehen? Die Version lässt sich in der package.json des jeweiligen Projekts nachschlagen oder über npx next --version ermitteln.

Schritt 2: Sofort auf 15.5.28 aktualisieren. Wer noch eine ältere 15.x-Version betreibt, sollte diesen Schritt umgehend erledigen. 15.5.28 schließt alle bis zum 14. Oktober 2026 bekannten Lücken — darunter zwei kritische RCE-Schwachstellen. Das ist kein Major-Upgrade, sondern ein Patch-Update innerhalb derselben Major-Version, das in aller Regel ohne Breaking Changes funktioniert.

Schritt 3: Upgrade auf Next.js 16 planen. Dieser Schritt erfordert mehr Vorbereitung (dazu gleich mehr), sollte aber zeitnah terminiert werden — nicht irgendwann, sondern mit konkretem Datum und verantwortlicher Person.

Schritt 4: Monitoring der Security Advisories aktivieren. Die GitHub Security Advisories für das Next.js-Repository lassen sich per E-Mail-Benachrichtigung oder RSS-Feed abonnieren. Wer das noch nicht eingerichtet hat, tut das jetzt.

Was ein Upgrade auf Next.js 16 konkret bedeutet

Next.js 16 (aktuelle Version: 16.4.2, veröffentlicht am 15. Oktober 2026) ist seit dem Release von Next.js 16.0.0 im Oktober 2025 der Active-LTS-Stand. Der offizielle Upgrade-Guide beschreibt die notwendigen Schritte, und Vercel stellt Codemods zur Verfügung, die einen großen Teil der mechanischen Migration automatisieren.

Technische Mindestvoraussetzungen

Vor dem Upgrade müssen folgende Abhängigkeiten geprüft werden:

• Node.js: Mindestens Version 20.9.0. Node 18 wird von Next.js 16 nicht mehr unterstützt.
• TypeScript: Mindestens Version 5.1.0.
• Browser-Kompatibilität: Chrome 111+, Edge 111+, Firefox 111+, Safari 16.4+. Ältere Browser-Targets müssen in der Build-Konfiguration angepasst werden.
• React: Die Peer-Range von next@16.4.2 erlaubt React ab 18.2.0 und 19.x. Der offizielle Guide empfiehlt die Nutzung der neuesten React-Version.

Die wichtigsten Breaking Changes

Das Upgrade von 15 auf 16 ist kein trivialer Versions-Bump. Die relevantesten Änderungen, die aktiven Code betreffen:

Turbopack als Standard. next dev und next build nutzen ab Version 16 standardmäßig Turbopack. Wer bisher eine eigene Webpack-Konfiguration pflegt, muss diese entweder auf Turbopack migrieren oder explizit --webpack als Flag setzen. Ein Build, der Webpack-Plugins voraussetzt, schlägt sonst ohne weitere Meldung fehl.

Vollständig asynchrone Request-APIs. Der synchrone Zugriff auf cookies(), headers(), draftMode(), params und searchParams ist entfernt. Jeder Zugriff auf diese Werte muss jetzt await verwenden. Betroffen sind außerdem Metadaten-Generatoren wie opengraph-image, twitter-image, icon und apple-icon. Das ist die häufigste Quelle von Laufzeitfehlern beim Upgrade.

middleware → proxy. Die bisherige middleware-Datei und der gleichnamige Export sind deprecated. Die neue proxy-API ersetzt sie — mit dem wichtigen Unterschied, dass proxy nur auf Node.js läuft, nicht mehr auf der Edge Runtime.

next lint entfernt. Das integrierte Lint-Kommando ist weg. ESLint muss direkt über die CLI aufgerufen werden. Gleichzeitig ist ESLint Flat Config jetzt der Standard.

serverRuntimeConfig / publicRuntimeConfig entfernt. Wer diese Konfigurationsoption nutzt, muss auf Umgebungsvariablen wechseln.

Änderungen bei next/image. Der minimumCacheTTL wurde von 60 Sekunden auf 4 Stunden erhöht, das qualities-Array enthält nur noch [75], und lokale IPs werden standardmäßig blockiert. Wer lokal mit IP-Adressen entwickelt oder eigene Qualitätsstufen konfiguriert hat, muss das explizit in next.config eintragen.

Parallel Routes. Slots in Parallel Routes brauchen jetzt zwingend eine default.js-Datei, sonst schlägt der Build fehl.

Codemods: Was automatisch geht und was nicht

Vercel stellt einen Codemod-Runner bereit, der die häufigsten mechanischen Umstellungen automatisch durchführt:

npx @next/codemod@canary upgrade latest

Dieser Codemod stellt unter anderem die next.config auf Turbopack um, migriert next lint auf die ESLint-CLI, transformiert middleware → proxy, entfernt unstable_-Präfixe und bereinigt experimental_ppr. Für den Wechsel auf die asynchronen Request-APIs gibt es einen separaten Codemod:

npx @next/codemod@canary next-async-request-api .

Was kein Codemod abnimmt: Das Testen der tatsächlichen Funktionalität nach dem Upgrade, die Prüfung individueller Webpack-Plugins, die Migration von Edge-Middleware-Logik zu Node-only-proxy und die Validierung von Caching-Verhalten nach den geänderten next/image-Defaults.

Ein hypothetisches Beispiel aus der Praxis: Eine Next.js-Web-App mit App Router, eigenem Webpack-Plugin für SVG-Verarbeitung und drei API-Routes, die synchron auf cookies() zugreifen, braucht nach den Codemods noch manuelle Korrekturen an der SVG-Konfiguration und den API-Routes. Ohne eine Testsuite, die diese Endpunkte abdeckt, ist das Risiko, produktive Funktionen unbemerkt zu beschädigen, real. Deshalb sollte das Upgrade immer in einer Staging-Umgebung erfolgen, bevor es auf Produktion geht.

Praxisbeispiel: Next.js-Buchungsplattform nach dem Support-Ende

Zur Veranschaulichung ein hypothetisches, aber realistisches Szenario aus dem Mittelstand: Ein mittelständischer Freizeitbetrieb betreibt eine Buchungswebsite auf Next.js 15. Das System läuft stabil, der Betreiber hat seit dem Launch keine größeren Updates durchgeführt. Die aktuelle Version ist 15.3.1 — also mehrere Patch-Releases hinter 15.5.28.

In diesem Zustand wäre die Anwendung gegen alle Lücken verwundbar, die zwischen 15.3.1 und 15.5.28 gepatcht wurden — darunter die kritischen RCE-Schwachstellen in der Image Optimization API vom August und Oktober 2026. Der erste Schritt wäre das sofortige Update auf 15.5.28. Der zweite wäre die Planung des Upgrades auf Next.js 16, idealerweise mit Bestandsaufnahme aller genutzten npm-Pakete, einem Test-Setup und einem Rollback-Plan.

Vergleichbare Situationen kennen wir aus unserer Arbeit mit KMU-Websites, die auf Next.js basieren — etwa bei der Buchungsplattform für MobiKart Funracing GmbH, wo wir ein vollständiges Next.js-System aufgebaut haben und laufend betreuen. Wer keine interne Entwicklungskapazität hat, die solche Updates strukturiert durchführt, läuft Gefahr, dass Upgrades auf den nächsten Notfall warten.

Wann ein Upgrade komplex wird — und wann es einfach ist

Nicht jedes Next.js-Projekt hat denselben Migrationsaufwand. Die entscheidenden Faktoren:

Niedriger Aufwand (oft ein halber bis ein Arbeitstag):

• Standard-App-Router-Setup ohne custom Webpack-Konfiguration
• Keine Middleware oder Middleware, die problemlos als proxy auf Node.js läuft
• Testsuite vorhanden, die kritische Pfade abdeckt
• Abhängigkeiten (npm-Pakete) aktuell und mit Next.js 16 kompatibel

Höherer Aufwand (mehrere Tage bis Wochen):

• Eigene Webpack-Plugins oder Loader, die auf Turbopack nicht unterstützt werden
• Umfangreiche Middleware-Logik, die auf Edge Runtime angewiesen ist
• Viele synchrone Zugriffe auf cookies() / headers() / params verteilt über das gesamte Projekt
• Veraltete Drittanbieter-Pakete, die mit React 19 oder Node.js 20 inkompatibel sind
• Keine Staging-Umgebung und keine automatisierten Tests vorhanden

Wer eine umfangreiche Anwendung ohne Testsuite betreibt, sollte das Upgrade nicht als schnellen Nachmittagsjob planen. Ein strukturiertes Vorgehen mit Bestandsaufnahme, Testaufbau, stufenweisem Rollout und definiertem Rollback-Pfad ist bei solchen Projekten der realistischere Weg.

Wenn Sie unsicher sind, wie Ihr Projekt einzuschätzen ist, bieten wir einen Next.js-Upgrade-Check an: Bestandsaufnahme aller Next.js-Projekte mit Version, Abhängigkeiten und Hosting, Einschätzung des Migrationsaufwands und ein konkreter Upgrade-Plan — damit Sie wissen, was vor Ihnen liegt, bevor Sie loslegen.

Update-Strategie für den laufenden Betrieb

Ein Upgrade auf Next.js 16 löst das Problem für die nächsten zwei Jahre — bis Next.js 16 seinerseits in die Maintenance-Phase tritt (voraussichtlich mit Erscheinen von Next.js 17, das aktuell noch nicht existiert). Wer das nächste Support-Ende nicht wieder unvorbereitet erleben möchte, braucht eine dauerhafte Update-Strategie:

• Minor- und Patch-Updates innerhalb einer Major-Version zeitnah einspielen — nicht erst nach Monaten. Die meisten Sicherheitslücken in Next.js wurden 2026 als Patch-Releases veröffentlicht, oft mit kurzer Vorlaufzeit.
• Security Advisories beobachten: GitHub-Repository-Watch für vercel/next.js aktivieren, Kategorie „Security advisories".
• Abhängigkeiten regelmäßig prüfen: Tools wie npm audit oder Dependabot lassen sich direkt in GitHub integrieren und melden bekannte Schwachstellen in npm-Paketen automatisch.
• Node.js-Version im Blick behalten: Next.js 16 setzt Node.js 20.9.0 voraus. Node.js 20 hat selbst ein Support-Ende (April 2026 für Active LTS, April 2028 für Maintenance LTS) — auch das gehört in den Wartungsplan.

Wenn intern keine Kapazität für dieses Monitoring besteht, ist ein externer Wartungsvertrag die pragmatische Alternative. Wir betreuen mehrere Next.js-Projekte im Rahmen unserer Website-Wartung und stellen sicher, dass Updates strukturiert, getestet und dokumentiert eingespielt werden — inklusive Überwachung der Security Advisories.

Ist die eigene Anwendung jetzt sofort gefährdet?

Diese Frage stellen sich viele Verantwortliche nach solchen Nachrichten. Die ehrliche Antwort: Wer auf 15.5.28 aktualisiert ist, ist gegen alle bis zum 14. Oktober 2026 bekannten Sicherheitslücken geschützt. Zum heutigen Stand (23. Oktober 2026) ist keine offene, ungepatchte Lücke bekannt, die Next.js 15 betrifft und nur in Next.js 16 behoben wäre.

Das ändert sich, sobald eine neue Schwachstelle in Next.js 15 entdeckt und gemeldet wird. Dann gilt: Wer noch auf 15.x läuft, hat laut Policy keinen Anspruch auf einen Patch. Ob Vercel im konkreten Einzelfall dennoch reagiert (die Policy erlaubt das ausdrücklich als seltene Ausnahme), ist im Voraus nicht vorhersehbar.

Das ist kein Grund für Panik, aber ein klarer Grund, das Upgrade auf Next.js 16 nicht auf die lange Bank zu schieben. Der Unterschied zwischen „sofort gefährdet" und „strukturiert handeln" liegt meist darin, wie konsequent eine Organisation ihre Software-Wartung betreibt — und nicht darin, ob eine Lücke gerade aktiv ausgenutzt wird.

Wer sich einen Überblick über die allgemeine IT-Sicherheit seiner Systeme verschaffen möchte, kann das mit unserem kostenlosen IT-Sicherheits-Check tun.

Abgrenzung: Was dieser Artikel nicht behandelt

Dieser Artikel konzentriert sich auf das Support-Ende von Next.js 15 und den unmittelbaren Handlungsbedarf. Zwei verwandte Fragen werden hier bewusst nicht vertieft, weil sie eigene Artikel verdienen:

• Ob und wann Next.js das richtige Framework für Ihr Unternehmen ist, beantwortet unser Artikel Next.js für Unternehmen.
• Wie Sie die Performance Ihrer Next.js-Anwendung optimieren, lesen Sie in Next.js Performance Optimierung.

Zu Next.js 17 gibt es zum aktuellen Stand keine veröffentlichte Version, keinen npm-Tag und keine offizielle Ankündigung. Wer spekuliert, wann 17 erscheint und damit 16 in die Maintenance-Phase überführt, bewegt sich auf unsicherer Grundlage.

Der nächste Schritt

Wenn Ihre Website oder Web-App auf Next.js 15 läuft — oder Sie nicht sicher sind, welche Version im Einsatz ist —, ist jetzt der richtige Zeitpunkt für eine strukturierte Bestandsaufnahme. Wir analysieren alle Ihre Next.js-Projekte, prüfen Versionen, Abhängigkeiten und Hosting, bewerten den Migrationsaufwand realistisch und erstellen einen Upgrade-Plan mit Codemods, Tests und Rollback.

Wenn das Upgrade sinnvoll ist, setzen wir es um. Wenn ein Projekt so klein ist, dass es mit dem Codemod in wenigen Stunden migriert werden kann, sagen wir das auch. Und wenn anschließend eine dauerhafte Wartung sinnvoll ist, sprechen wir darüber — ohne Verpflichtung.

Next.js-Upgrade-Check anfragen — und innerhalb weniger Tage wissen, was auf Sie zukommt.