Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Das Ende der Lebensdauer (EOL) von Nuxt 3 ist am 31. Juli 2026 erreicht; damit werden keine Sicherheitspatches mehr für das Framework, Nitro, h3, die Vue 3-Integration und die mitgelieferten Abhängigkeiten bereitgestellt.
- Für einwandfrei funktionierende Nuxt-3-Apps auf modernem Node.js ist das Upgrade auf Nuxt 4 wirklich unkompliziert. Das Nuxt-Team hat es bewusst so konzipiert: Ab Version 3.12 ist die Kompatibilität optional, und Codemods automatisieren den Großteil der Arbeit.
- Es gibt drei Situationen, in denen eine verlängerte Supportlaufzeit die bessere Wahl ist als ein Upgrade: eine strategische Entscheidung, Nuxt 4 zu überspringen und auf Nuxt 5 zu warten, Compliance-Umgebungen, die keine Migrationsfenster zulassen, sowie eine Vielzahl von Nuxt-Modulen von Drittanbietern, die noch nicht auf Version 4 aktualisiert wurden.
Wenn Sie Nuxt 3 in der Produktion einsetzen, hat das EOL-Datum am 31. Juli 2026 wahrscheinlich nicht dieselbe Panik ausgelöst wie die Fristen anderer Frameworks. Gut so. Das sollte auch nicht der Fall sein. Das Nuxt-Team hat offen kommuniziert, was das Upgrade beinhaltet, und für die meisten Apps handelt es sich um einen überschaubaren Arbeitsaufwand.
Allerdings ist der Ausdruck „die meisten Apps“ in diesem Satz etwas zu pauschal. Es gibt triftige Gründe, warum ein Team zu dem Schluss kommen könnte, dass ein Upgrade auf Nuxt 4 zum jetzigen Zeitpunkt der falsche Schritt ist. In diesem Artikel geht es um diese Gründe und darum, welche Optionen Sie haben, wenn Sie sich in einer dieser Situationen befinden.
Wie die Versionsverwaltung bei Nuxt tatsächlich funktioniert
Nuxt-Supportrichtlinie: Jede Hauptversion erhält nach Veröffentlichung der nächsten Hauptversion mindestens sechs Monate lang Wartungssupport. Patch-Versionen erscheinen etwa wöchentlich, Minor-Versionen etwa monatlich, wobei grundlegende Änderungen auf Hauptversionen beschränkt sind.
Nuxt 3 ist seit November 2022 verfügbar und wurde im Rahmen der umfassenden Modernisierung des Ökosystems nach dem EOL -Meilenstein von Vue 2 eingeführt. Nuxt 4 wurde Mitte 2025 zur aktuellen Hauptversion. Das ursprüngliche EOL für Nuxt 3 war auf den 31. Januar 2026 festgelegt, wurde jedoch vom Nuxt-Team als Reaktion auf das Feedback der Community verlängert, sodass der aktuelle Stichtag nun der 31. Juli 2026 ist. Nach diesem Datum erhält die 3.x-Reihe keine Updates mehr.
Nuxt 5 befindet sich derzeit in der aktiven Entwicklung. Nitro v3 und h3 v2 stehen kurz vor der Fertigstellung. Sobald Nuxt 5 veröffentlicht wird, erreicht Nuxt 4 sechs Monate später das Ende seines Lebenszyklus (EOL). Dieser Zeitplan ist für den weiteren Verlauf dieser Diskussion von Bedeutung.
Was das Ende der Lebensdauer von Nuxt 3 tatsächlich bedeutet
Nach dem EOL-Datum von Nuxt 3 am 31. Juli 2026 wird das Nuxt-Team keine Sicherheitspatches mehr für die 3.x-Reihe bereitstellen. Für nach diesem Datum bekannt gegebene CVEs wird es keine Korrekturen auf Upstream-Ebene geben.
Die CVE-Historie von Nuxt 3 ist real, nicht nur theoretisch. Hier sind drei Beispiele aus den letzten 18 Monaten, die verdeutlichen, welche Art von Problemen in jedem Produktions-Framework auftreten können:
CVE-2025-27415 (CVSS 7,5, Hoch): Eine Sicherheitslücke im Zusammenhang mit CDN-Cache-Poisoning, die Nuxt 3.0.0 bis 3.16.0 betrifft. Ein Angreifer sendet eine Anfrage wie https://yoursite.com/?/_payload.json. Nuxt gibt eine Antwort im JSON-Format zurück. Wenn der Cache-Schlüssel Ihres CDN-Anbieters Query-Strings ignoriert, wird diese JSON-Datei unter der Basis-URL zwischengespeichert und an legitime Besucher ausgeliefert, wodurch Ihre Website als defekt erscheint. Der Angriff erfordert keine Authentifizierung und kann automatisiert werden, um eine dauerhafte Nichtverfügbarkeit aufrechtzuerhalten. In Nuxt 3.16.0 behoben.
CVE-2024-34343 (CVSS 5.1, mittleres Risiko): Eine Cross-Site-Scripting-Sicherheitslücke in navigateTo. Die Funktion hat versucht, die javascript: Das Protokoll stützte sich jedoch auf eine Parsing-Logik, die bei fehlerhaften URLs leere Werte zurückgab, wodurch die Protokollprüfung umgangen werden konnte. In Nuxt 3.12.4 behoben.
CVE-2024-34344 (CVSS 8,8, Hoch): Ausführung von Remote-Code über den Browser bei lokaler Ausführung von Nuxt im Testmodus. Die NuxtTestComponentWrapper Komponentenpfade wurden ohne ausreichende Validierung geladen, wodurch eine bösartige Webseite, die im selben Browser geöffnet war, beliebiges JavaScript auf dem Testserver auslösen konnte. Behoben in Version 3.12.4.
Diese wurden während der aktiven Supportphase entdeckt und behoben. Nach dem 31. Juli 2026 wird es keine weitere Sicherheitslücke mit ähnlichem Schweregrad mehr geben.
In regulierten Umgebungen stellt dies eher ein Compliance-Problem als ein Sicherheitsproblem dar. Gemäß PCI DSS müssen Schwachstellen mit hohem Schweregrad innerhalb von 30 Tagen nach Bekanntwerden behoben werden. SOC-2-Prüfer weisen auf nicht mehr unterstützte Software in Produktionsumgebungen hin. In FedRAMP-Umgebungen werden EOL-Komponenten als Beanstandungen behandelt.
Die verborgene Seite: Der Abhängigkeitsbaum von Nuxt
Eine Nuxt-3-App in der Produktion läuft nicht mit nur einem Paket. Die Standardkonfiguration nuxt installiert Folgendes:
- Vue 3 und die
@vue/*Pakete als Darstellungsschicht - Nitro als Server-Engine
- h3 als das zugrunde liegende HTTP-Framework von Nitro
- Vite als Build-Tool
- Das unjs-Ökosystem (
ufo,c12,consola,defu,hookable,jiti(u. a.) für gemeinsam genutzte Versorgungsleistungen - Die
@nuxt/*Kernpakete (@nuxt/kit,@nuxt/schema,@nuxt/vite-builder,@nuxt/devtools)
Jedes dieser Pakete verfügt über eine eigene Abhängigkeitskette. Der gesamte gebündelte Baum einer Nuxt-3-Anwendung umfasst Hunderte von Paketen. Jede CVE an beliebiger Stelle in diesem Baum – sei sie direkt oder transitiv – stellt eine Sicherheitslücke dar, die nach dem Ende des Supports für Nuxt 3 am 31. Juli 2026 nicht mehr durch Upstream-Patches behoben wird.
Die oben genannte CVE zum Cache-Poisoning betraf die zentrale Anforderungsverarbeitung von Nuxt. Die navigateTo CVE lag in der Interaktion zwischen Nuxt und einem unjs-Dienstprogramm. Die EOL-Exposition erstreckt sich über die gesamte gebündelte Oberfläche, nicht nur über die nuxt das Paket selbst. Ein Patch nur für das Framework hilft nicht weiter, wenn die nächste Sicherheitslücke in Nitro oder einem der unjs-Pakete auftaucht.
Optional separat installierbare Module (@nuxt/image, @nuxt/content, @nuxt/ui, Community-Module von @nuxtjs/* (und an anderer Stelle) fallen nicht unter diese Kategorie. Sie haben ihre eigenen Veröffentlichungsrhythmen und CVE-Verläufe und erfordern eine eigene Patching-Strategie.
Ihre Optionen, wenn Nuxt 3 das Ende der Lebensdauer erreicht
Drei konkrete Wege, für die jeweils klar ist, wann sie der richtige ist.
Option 1: Upgrade auf Nuxt 4
Für die meisten Teams ist dies die richtige Lösung. Das Nuxt-Team hat Nuxt 4 speziell dafür entwickelt, diese Umstellung reibungslos zu gestalten. Ab Nuxt 3.12 können Sie das Nuxt-4-Verhalten aktivieren, indem Sie compatibilityVersion: 4 in deinem nuxt.config.ts, testen Sie isoliert und migrieren Sie in Ihrem eigenen Tempo. Offizielle Codemods automatisieren die Umstrukturierung der Verzeichnisse, um app/, API-Umbenennungen und die Umstellung auf flache Reaktivität für useFetch.
Nach Einschätzung des Nuxt-Teams lassen sich die meisten Nuxt-3-Projekte mit minimalem Aufwand aktualisieren. Dies deckt sich mit Berichten von Teams, die dies bereits umgesetzt haben.
Was Sie tatsächlich einplanen müssen:
- Mindestens Node.js 18.20. Falls Ihre Toolchain auf eine ältere Version festgelegt ist, ist dies eine erforderliche Migration.
- Die Verzeichnisstruktur wird wie folgt umgestaltet:
app/. Codemod übernimmt den technischen Teil. Du solltest jedoch weiterhin die Watcher-Muster, die Layer-Konfigurationen und alle benutzerdefinierten Pfade überprüfen. - Standardmäßig geringe Reaktivität.
useFetchunduseAsyncDataDaten sind in Nuxt 4 nur oberflächlich reaktiv. Code, der auf tiefer Reaktivität basiert, erfordert eine explizite Aktivierung. - Modulkompatibilität. Eigenes
@nuxt/*Die Module sind auf dem neuesten Stand. Die Community-Module variieren. - Überprüfung der Testinfrastruktur.
Bei einer gut gepflegten App, die auf einer aktuellen Node-Version läuft und nur wenig Speicherplatz beansprucht, dauert dies Tage statt Wochen. Der Grund, warum dieser Abschnitt existiert, anstatt Sie einfach auf die Upgrade-Anleitung zu verweisen, ist, dass die Beschreibung „gut gepflegt, aktuelle Node-Version, geringer Speicherbedarf“ nicht auf jede Nuxt-3-App in der Produktion zutrifft.
Option 2: Umstellung auf ein alternatives Framework
Falls Sie bereits über ein anderes Rendering-Modell oder eine andere Laufzeitumgebung nachdenken, ist das Ende der Lebensdauer von Nuxt 3 ein entscheidender Anstoß, diese Entscheidung zu treffen. Die realistischen Optionen für Vue-Teams sind begrenzter als für React-Teams. Sie können für SPA-Anwendungen auf reines Vue 3 mit Vite umsteigen, bei inhaltsreichen Websites zu Astro wechseln oder das Ökosystem komplett wechseln.
Jede dieser Optionen ist mit den üblichen Kosten für eine Framework-Migration verbunden: das Neuschreiben von Komponenten, das Ersetzen von Routing und Datenabruf, der Neuaufbau der Testinfrastruktur sowie der Verzicht auf das Nuxt-spezifische Modul-Ökosystem. Für die meisten Teams, die Nuxt 3 in der Produktion einsetzen, spricht die Kosten-Nutzen-Rechnung nicht für diesen Weg. Er wird hier eher der Vollständigkeit halber aufgeführt als als wahrscheinliche Empfehlung.
Option 3: Erweiterter Support mit TuxCare ELS
Diese Option ist in drei konkreten Situationen sinnvoll.
Der strategische Schritt, Nuxt 4 zu überspringen. Das Nuxt-Team hat offen kommuniziert, dass Nuxt 4 eine Übergangsversion ist. Nuxt 5 bringt Nitro 3, die Environment-API von Vite 6 und aktualisierte h3-Interna mit sich. Die Kompatibilitätsbrüche zwischen Version 4 und 5 sind umfangreicher als zwischen Version 3 und 4. Und Nuxt 4 selbst wird sechs Monate nach der Veröffentlichung von Nuxt 5 nicht mehr unterstützt.
Wenn Sie jetzt auf Version 3 oder 4 umsteigen, müssen Sie sich auf einen weiteren Migrationszyklus einstellen, sobald Nuxt 5 veröffentlicht wird. Das Nuxt-Team hat angekündigt, dass Nuxt 5 derzeit aktiv entwickelt wird und Nuxt 4 sechs Monate nach der Veröffentlichung von Nuxt 5 das Ende der Lebensdauer (EOL) erreicht. Realistisch betrachtet bedeutet das zwei Produktionsmigrationen innerhalb eines relativ engen Zeitraums.
Die Alternative wäre, bei Nuxt 3 mit ELS-Unterstützung zu bleiben, Nuxt 4 komplett zu überspringen und direkt von 3 auf 5 zu wechseln, sobald sich Nuxt 5 stabilisiert hat. Eine Migration statt zwei. Die Frage nach dem richtigen Timing lautet: Ist ELS kostengünstiger als ein überflüssiges Zwischen-Upgrade? Für die meisten Unternehmensteams ist dies eindeutig der Fall.
Umgebungen mit strengen Compliance-Vorgaben. PCI DSS, SOC 2, FedRAMP und ähnliche Rahmenwerke verlangen den Nachweis, dass die Software auf dem neuesten Stand ist und unterstützt wird. Sie lassen kein sechswöchiges Migrationsprojekt zu, nur weil der Prüfer vor der Tür steht. Wenn Ihr Prüfungszeitraum in die Zeit nach dem EOL fällt und Ihre Umgebung eine Nuxt-4-Migration in dieser Zeit nicht umsetzen kann, stellt ELS die Patch-Quelle und die Dokumentationsnachweise bereit, die die Kontrollanforderungen erfüllen.
Dies gilt auch für Umgebungen mit festgelegten Node.js-Versionen, von Kunden bereitgestellte oder White-Label-Anwendungen, bei denen Versionsaktualisierungen nicht erzwungen werden können, sowie für alle Fälle, in denen das Risiko von Änderungen über einen längeren Zeitraum verteilt werden muss, anstatt es innerhalb eines einzigen Zeitfensters zu akzeptieren.
Verzögerung im Modul-Ökosystem. Als Nuxt 4 veröffentlicht wurde, war der Kern @nuxt/* Die Pakete wurden reibungslos aktualisiert. Bei optionalen First-Party-Modulen und Community-Modulen dauerte es länger, und einige sind noch nicht migriert. Wenn Ihre App von einer Vielzahl dieser Module abhängt, könnten Sie durch Betreuer, auf die Sie keinen Einfluss haben, blockiert werden, bis diese die Kompatibilität mit Nuxt 4 bereitstellen.
ELS für Nuxt 3 sorgt dafür, dass das Framework und die darin enthaltenen Abhängigkeiten sicher bleiben, während Sie abwarten. Es patcht weder die optionalen noch die Community-Module selbst; diese bleiben in der Verantwortung ihrer Betreuer oder Ihres eigenen Teams. Stattdessen entlastet es das Framework von dem Druck, eine Migration durchführen zu müssen, bevor die Abhängigkeiten Ihrer Module bereit sind.
Keiner dieser Fälle trifft auf jede Nuxt-3-Anwendung zu. Alle drei sind realistisch, und jeder einzelne davon ist ein stichhaltiger Grund, die Planung im Hinblick auf das EOL von Nuxt 3 mit verlängertem Support anzupassen, anstatt eine Migration zu überstürzen, die nicht zur Situation des Teams passt.
Was TuxCare ELS für Nuxt 3 bietet
Der „Endless Lifecycle Support“ von TuxCare für Nuxt 3 EOL gewährleistet auch nach dem Stichtag am 31. Juli 2026 weiterhin die Bereitstellung von Sicherheitspatches. Der Support umfasst nuxt Paket, seine direkten Abhängigkeiten und deren transitive Ketten: Vue 3 und das @vue/* Pakete, Nitro, h3, Vite, das @nuxt/* Kernpakete, die Dienstprogramme des unjs-Ökosystems und die zugrunde liegenden Pakete, auf denen diese basieren. Patches werden über die üblichen npm-Workflows bereitgestellt.
Optional separat installierbare Module (@nuxt/image, @nuxt/content, @nuxt/ui, @nuxtjs/*(z. B. Community-Module) sind nicht im Standardumfang enthalten.
Einige Details, die im gesamten ELS-Portfolio dem TuxCare-Standard entsprechen:
- Patching-Workflow. TuxCare überwacht das NVD, die Sicherheitshinweise auf GitHub sowie die Kanäle der Anbieter. Wenn eine CVE bekannt wird, die von unseren Paketen betroffene Pakete betrifft, durchlaufen die Backports den kombinierten Prozess aus Automatisierung und Expertenprüfung bei TuxCare. Jeder Patch wird auf Integrität, Funktionalität und Regressionen getestet, bevor er in Ihre Repositorys gelangt.
- Bereitstellungsmethode. Patches werden über von TuxCare gehostete, npm-kompatible Repositorys bereitgestellt. Keine Änderungen an CI/CD, keine neuen Tools, keine Neuprogrammierung der Build-Pipeline.
- Compliance-Dokumentation. Jede Version enthält eine Aufstellung der behobenen CVEs und der geänderten Pakete, die den Nachweisanforderungen von PCI, SOC 2 und FedRAMP entspricht.
- SLA-gebundene Reaktion. Kritische und hochgradige CVEs (CVSS 7.0+) werden innerhalb eines festgelegten Zeitrahmens behoben.
Technische Einzelheiten zum Patching-Prozess von TuxCare finden Sie ausführlich im Whitepaper zum Thema Open-Source-Patching: „TuxCare Open Source Patching Process“.
Das ehrliche Fazit
Für die meisten Nuxt-3-Apps ist ein Upgrade auf Nuxt 4 die richtige Entscheidung. Die Migration wird umfassend unterstützt, und das Nuxt-Team hat dafür gesorgt, dass sie gut zu bewältigen ist.
Es gibt Fälle, in denen kein erweiterter Support für die Apps verfügbar ist. Teams, die sich bewusst dafür entscheiden, Nuxt 4 zu überspringen und auf Nuxt 5 zu warten. Apps, die an Compliance-Fristen gebunden sind, die eine Migration nicht zulassen. Codebasen, die von Community-Modulen abhängig sind, die noch nicht auf dem neuesten Stand sind. Wenn Ihre Situation in diese Kategorie fällt, bietet Ihnen ELS ein Mindestmaß an Sicherheit, während Sie auf den richtigen Zeitpunkt oder das richtige Upstream-Update warten.
Der Fehler besteht darin, das EOL-Datum von Nuxt 3 als zwingenden Ausschlaggeber zu betrachten, obwohl dies nicht der Fall ist. Das Nuxt-Team hat den Upgrade-Pfad so gestaltet, dass er reibungslos verläuft. Es hat zudem deutlich gemacht, dass Nuxt 4 eine Übergangsversion ist und Nuxt 5 in Vorbereitung ist. Beide Aspekte sollten in die Entscheidung Ihres Teams einfließen, nicht nur einer davon.
Um herauszufinden, ob ELS für Nuxt 3 zu Ihrer Umgebung passt, besuchen Sie die Seite „Endless Lifecycle Support für Nuxt“ von TuxCare oder kontaktieren Sie uns, um Ihre technische Infrastruktur zu besprechen.
