Fastify EOL: Versionen, Termine, Risiken und Optionen (2026)

Wichtigste Erkenntnisse

• Fastify v3 hat seit dem 30. Juni 2023 das Ende der Lebensdauer erreicht, und v4 folgte am 30. Juni 2025.
• Nur die v5-Reihe erhält noch Fehlerbehebungen vom Fastify-Team, während v6 bereits in die Alpha-Phase übergegangen ist.
• Fastify v5 benötigt Node.js 20 oder neuer, und Node 20 erreicht im April 2026 das Ende der Lebensdauer (EOL) – ein Framework-Upgrade zieht also ein Upgrade der Laufzeitumgebung nach sich.
• Der „Endless Lifecycle Support“ von TuxCare umfasst Fastify 3.29.5 und 4.29.1 mit laufenden CVE-Patches, während Sie die Umstellung planen.

Wenn Sie eine Bestandsaufnahme in einer großen Node.js-Umgebung durchführen, werden Sie in der Regel Dienste finden, die noch mit Fastify v3 laufen, dessen LTS-Unterstützung im Juni 2023 ausgelaufen ist. Das bedeutet, dass seit über drei Jahren keine Sicherheitspatches mehr für das Framework bereitgestellt wurden – und der Code läuft weiterhin in der Produktion.

Auch Fastify v4 wird nicht mehr unterstützt, da der LTS-Zeitraum am 30. Juni 2025 abgelaufen ist. Damit bleibt v5, das im September 2024 veröffentlicht wurde, die einzige Version, für die das Kernteam weiterhin Fehlerbehebungen bereitstellt. Der Umstieg darauf bedeutet auch den Umstieg auf eine Node.js-Version, die noch unterstützt wird, da Node 20 nun das Ende der Lebensdauer (EOL) erreicht hat und Node 22 bereits in die Wartungsphase übergegangen ist.

Im Folgenden erfahren Sie, was „Fastify EOL“ eigentlich bedeutet, welche Risiken bei den einzelnen Produktlinien real und welche theoretisch sind, wie eine v3-Flotte aussieht, wenn sich das Migrations-Ticket immer wieder auf das nächste Quartal verschiebt, und welche drei realistischen Optionen Sie haben.

Was ist Fastify?

Fastify ist ein Node.js-Web-Framework, das auf einen geringen Overhead pro Anfrage ausgelegt ist. Es verfügt über eine Plugin-Architektur, die für eine klare Kapselung sorgt, sodass die Dekoratoren einer Route nicht in eine andere Route übergreifen können. Die Validierung und Serialisierung erfolgt über JSON Schema, die Protokollierung über pinoprotokolliert. Als Version 5 veröffentlicht wurde, verzeichnete die OpenJS Foundation die monatlichen Downloads auf 7,8 Millionen, bei 296 offiziell anerkannten Plugins im Ökosystem. Bis Juli 2026 war diese Zahl laut npm-stat auf über 43 Millionen monatliche Downloads.

 

Im Vergleich zu den Frameworks, die Sie wahrscheinlich bereits verwendet haben, ist Express ist das ältere und wesentlich umfangreichere Framework, das monatlich etwa zwölfmal so viele npm-Downloads verzeichnet wie Fastify, obwohl es kaum über integrierte Validierungsfunktionen verfügt, und von dem die meisten Teams ursprünglich kommen. Hapi erfordert einen höheren Konfigurationsaufwand und bietet mehr integrierte Funktionen. Koa ist ein schlanker Middleware-Kern, bei dem fast alles andere eine separate Entscheidung ist, die Sie treffen müssen. NestJS ist kein wirklicher Konkurrent, da es sich um ein Anwendungsframework handelt, das entweder auf Express oder einem Fastify-Adapter aufsetzt.

Wenn es sich bei Ihrem Dienst um eine NestJS-App handelt, auf der der Fastify-Adapter läuft, ist Fastify in Ihrem Abhängigkeitsbaum enthalten – unabhängig davon, ob es in der Bestandsliste Ihres Teams als Fastify-App bezeichnet wird oder nicht. Das Gleiche gilt für die Node.js-Version darunter: Sie ist still und leise aus dem Verkehr gezogen worden und wird dort von einem Framework festgehalten, für das sich jemand vor zwei Teams und einer Umstrukturierung entschieden hat.

Profi-Tipp: Führen Sie folgenden Befehl aus: npm ls fastify –all in jedem Service-Repo aus, nicht nur in denen, von denen du glaubst, dass sie es verwenden. Adapter, Generatoren und interne SDKs beziehen Fastify als transitive Abhängigkeitein, und diese Kopien haben selten einen eindeutigen Verantwortlichen. So taucht in der Regel eine versehentliche v3-Installation auf.

Ist Fastify am Ende seiner Lebensdauer angelangt?

Fastify v1, v2, v3 und v4 haben alle ihre LTS-Enddaten überschritten. v5 ist die einzige Version, für die das Kernteam weiterhin aktive Fehlerbehebungen bereitstellt, und ihr Eintrag im offiziellen Zeitplan lautet nach wie vor „TBD“. Das wird jedoch nicht ewig so bleiben. Fastify 6.0.0-alpha.1 wurde im August 2026 veröffentlicht, und gemäß derselben Richtlinie wird v5 nach der Veröffentlichung von v6 für sechs Monate auf reine Sicherheitsupdates umgestellt.

Der Zeitplan ist nicht willkürlich, auch wenn es von außen so aussehen mag. Die LTS-Richtlinie von Fastify sieht für jede Hauptversion mindestens sechs Monate aktiven Support vor, gefolgt von weiteren sechs Monaten, in denen ausschließlich Sicherheitsupdates bereitgestellt werden, sobald die nächste Hauptversion erscheint. Diese Berechnung ergibt als Ende des LTS für Version 4 den 30. Juni 2025.

Nach Ablauf dieses Zeitraums heißt es in der Richtlinie zwar, dass die Betreuer weiterhin Sicherheitskorrekturen prüfen und veröffentlichen werden, jedoch nur, wenn die Community diese bereitstellt und sofern keine anderen Einschränkungen bestehen, wie beispielsweise die Mindestversion von Node.js, die unterstützt wird. Es handelt sich also um einen bedingten, von der Community getragenen Support und nicht um eine gepflegte Release-Reihe. Ein schwerwiegender Fehler in Version 4 könnte heute entweder einen Patch von der Community erhalten, eine höfliche Aufforderung zum Upgrade nach sich ziehen oder einfach als GitHub-Issue offen bleiben.

Wenn Teams darauf setzen, welches dieser drei Ergebnisse bei einer Produktions-API eintreten wird, geraten sie in Schwierigkeiten. Genau aus diesem Grund gibt es überhaupt erst den erweiterten Sicherheitssupport.

Lebenszyklus der Fastify-Versionen und wichtige EOL-Termine

Diese Daten stammen direkt aus dem von Fastify veröffentlichten LTS-Zeitplan. Die Spalte „Node.js“ gibt die dort für jede Hauptversion aufgeführten Release-Reihen wieder, weshalb sie neben den LTS-Reihen auch kurzlebige „Current“-Releases wie 9 und 11 enthält.

Fastify-Version	Erscheinungsdatum	Ende des LTS	Aktueller Stand	Aufgelistete Node.js-Zeilen
1.0.0	März 6, 2018	September 1, 2019	EOL	6, 8, 9, 10, 11
2.0.0	Februar 25, 2019	Januar 31, 2021	EOL	6, 8, 10, 12, 14
3.0.0	Juli 7, 2020	Juni 30, 2023	EOL	10, 12, 14, 16, 18
4.0.0	Juni 8, 2022	Juni 30, 2025	EOL	14, 16, 18, 20, 22
5.0.0	September 17, 2024	Noch nicht bekannt gegeben	Aktiv	20, 22

Eine Anmerkung zur Zeile „v5“: Dort ist vermerkt, was zum Zeitpunkt der Veröffentlichung von v5 getestet wurde. Die CI von Fastify auf dem „main“-Zweig führt ihre Unit-Tests mittlerweile mit Node 24 und 26 durch. Node 20 erscheint ebenfalls in dieser Zeile, wurde jedoch am 30. April 2026 als EOL (End of Life) eingestuft. Betrachten Sie diese Version daher eher als Mindestanforderung für die Kompatibilität und nicht als Laufzeitumgebung, auf der Sie eine Anwendung bereitstellen würden.

Schauen Sie sich nun die Zeile „v3“ neben dem heutigen Datum an. Drei Jahre nach Ablauf des LTS, in einem Node.js-Bereich (10 bis 18), der selbst vollständig EOL ist, und da auch v4 nicht mehr unterstützt wird, gibt es keinen Zwischenschritt mehr, auf den man ausweichen könnte. Deshalb ist „einfach upgraden“ für eine v3-Flotte eine viel größere Herausforderung, als es für eine v4-Flotte klingt.

Sicherheitsrisiken beim Einsatz von EOL-Fastify in der Produktion

Das Risiko besteht nicht darin, dass sich eine bestimmte CVE in Ihrem „node_modules“ befindet. Es ist die Asymmetrie, die an dem Tag zum Tragen kommt, an dem Ihre Version das EOL erreicht, und sich jedes Jahr danach weiter verschärft. Die Sicherheitsforschung zu Fastify schreitet mit voller Geschwindigkeit voran, und die daraus resultierenden Korrekturen werden für die unterstützte v5-Reihe entwickelt. Für eine v4-Umgebung bedeutet das bereits eine kumulierte Sicherheitslücke von über einem Jahr. Für eine v3-Umgebung sind es drei Jahre.

CVE-Meldungen für das Framework betreffen Ihre Version nicht mehr

Die Familie der Content-Type-Validierungen veranschaulicht sehr anschaulich, was das in der Praxis kostet. Im April 2025, wurde in CVE-2025-32442 eine Schwachstelle dokumentiert, bei der bei Anwendungen, die eine Validierung pro Content-Type definierten, diese Validierung vollständig umgangen werden konnte, indem lediglich ein leicht veränderter „Content-Type“-Header gesendet wurde. Der Sicherheitshinweis listet Fastify 5.0.0 bis 5.3.1 sowie 4.29.0 als betroffen auf; Korrekturen sind in den Versionen 5.3.2 und 4.29.1 enthalten. Für v4 wurde eine gepatchte Version veröffentlicht, da sie sich noch innerhalb des Supportzeitraums befand, und v3 wurde nie als betroffen aufgeführt. Ein Jahr später führte dieselbe Schwachstellenfamilie zu CVE-2026-33806, eine schwerwiegende Umgehung genau dieses Fixes, die nichts Exotischeres als ein führendes Leerzeichen im Header nutzte und erst in 5.8.5 behoben wurde.

Die Sicherheitsupdate der OpenJS Foundation für das erste Quartal 2026 umfasst 18 CVEs im Ökosystem, die in diesem Quartal im Rahmen ihrer CNA-Aktivitäten veröffentlicht wurden, davon drei im Fastify-Ökosystem. Zwei davon betrafen Fastify selbst. CVE-2026-3419 war ein Problem bei der Validierung eines fehlerhaften „Content-Type“, das die Versionen 5.7.2 bis 5.8.0 betraf und in 5.8.1 behoben wurde, was es zu einer Regression ausschließlich in Version 5 macht und nicht zu einem fehlenden Backport. CVE-2026-3635 ist besonders bemerkenswert: ein trustProxy -Header-Spoofing-Schwachstelle, deren Sicherheitshinweis alle Fastify-Versionen bis einschließlich 5.8.2 abdeckt, wobei der Fix erst in 5.8.3 bereitgestellt wurde. Jede v3- und v4-Installation fällt in diesen betroffenen Bereich, und keine davon erhielt eine gepatchte Version.

Die dritte, CVE-2026-2880, war eine schwerwiegende Umgehung der Autorisierung in der optionalen @fastify/middie , bei dem Middleware mit Pfad-Gültigkeitsbereich umgangen werden konnte, da das Plugin die Anfragepfade anders normalisierte als der Router. Die Korrektur ist in middie 9.2.0 enthalten, und die 9.x-Reihe wird auf Basis von Fastify v5 entwickelt. Die 8.x-Reihe, auf der v4-Anwendungen laufen, wurde im September 2024 mit Version 8.3.3 eingestellt und erhielt diese Korrektur nie.

Die Entwicklung schreitet unvermindert voran. OpenJS berichtet in seinem Update zum 2. Quartal 2026 , dass sein CNA in der zweiten Hälfte des Jahres 2025 drei CVEs und in der ersten Hälfte des Jahres 2026 49 CVEs veröffentlicht hat, wobei etwa zehn weitere noch auf ihre Veröffentlichung warten. Dieser Anstieg ist größtenteils auf eine strengere Triage und KI-gestütztes Scannen zurückzuführen und nicht auf eine plötzliche Welle neuer Fehler, doch die Auswirkungen auf eine EOL-Produktreihe sind in beiden Fällen dieselben. Mehr Offenlegungen – von denen keine in Ihrer Version landet.

Die zugrunde liegende Laufzeitumgebung verfügt über eine eigene Uhr

Fastify v3 wurde für Node.js 10 bis 18 verifiziert, wobei jede dieser Versionen mittlerweile selbst das Ende der Lebensdauer (EOL) erreicht hat. Teams bleiben bei der alten Fastify-Version, weil ein Upgrade kostspielig ist, und derselbe Budgetdruck, der sie dazu zwingt, dort zu bleiben, hält sie in der Regel auch bei einer alten Node-Version fest. Für einen v3-Dienst sind das häufig zwei Versionen, deren Support bereits vor Jahren abgelaufen ist, und die Laufzeitumgebung ist dabei diejenige, die die größere Angriffsfläche bietet – von TLS und HTTP-Parsing bis hin zum Netzwerkverkehr und allem anderen, was unterhalb Ihres Anwendungscodes liegt.

Das ist der eigentliche Grund, warum Teams ins Stocken geraten, und selten liegt es am Framework. Niemand definiert „Aktualisierung des Web-Frameworks“ als eine Migration der Laufzeitumgebung plus eine Änderung des Basis-Images plus einen Neuaufbau der nativen Module. Wenn es dann doch jemand tut, verdreifacht sich der geschätzte Aufwand, und das Ticket wird auf das nächste Quartal verschoben.

Wo Abhängigkeitsbeschränkungen Sie einschränken

Der Code-Baum von Fastify ist wirklich schlank, und das sollte man ehrlich zugeben. Ab Fastify 5.12.0 werden bei der Installation von Version 5 15 direkte Laufzeitabhängigkeiten mitgeliefert: avvio, find-my-way, fast-json-stringify, light-my-request, pino, secure-json-parse, semver, rfdc, toad-cache, process-warning, abstract-loggingsowie vier @fastify/* Pakete. Für ein Web-Framework ist das eine wirklich kleine Menge an direkten Abhängigkeiten.

Das Erreichen des EOL führt nicht automatisch dazu, dass dieser Baum eingefroren wird, und es lohnt sich, genau zu erklären, was tatsächlich passiert. Fastify legt Semver-Bereiche fest, und npm wechselt Abhängigkeiten auf neuere Versionen, die diese weiterhin erfüllen, sodass zahlreiche Sicherheitskorrekturen aus dem Upstream-Bereich einfließen, ohne dass jemand Fastify selbst anfassen muss. Das Problem ist jedoch enger gefasst und ärgerlicher als ein eingefrorener Baum. Wenn die einzige korrigierte Version außerhalb des Bereichs liegt, den Ihre Fastify-Zeile akzeptiert, bedeutet deren Übernahme eine Überschreibung, eine direkte Änderung der Abhängigkeiten oder ein Framework-Upgrade, für das Ihre Version nie getestet wurde.

Ihr Scanner meldet also eine transitive Warnung, und der saubere Behebungsweg lautet „Fastify aktualisieren“ – genau das, was Sie eigentlich vermeiden wollten. Bei einer v3-Anwendung bedeutet das in der Regel ein Node.js-Upgrade sowie Änderungen am Schema und an der API, nicht etwa die Veröffentlichung eines Patches. Aufgrund dieser Diskrepanz verwandelt sich ein eigentlich problemloses Audit in ein Quartal voller Diskussionen mit Ihrem Sicherheitsteam über akzeptable Risiken und Fehlalarme.

Ihre Optionen nach dem Ende des Supportzyklus von Fastify

Es gibt drei Optionen, und welche davon die richtige ist, hängt weniger vom technischen Geschmack ab als vielmehr davon, welche Version Sie tatsächlich einsetzen und wie viel Zeit Ihr Team in diesem Quartal zur Verfügung hat.

Wenn das auf Sie zutrifft	Mach das
Einsatz von Version 3 oder 4 in einem regulierten Umfeld, ohne Spielraum für eine Migration der Laufzeitumgebung und des Frameworks in diesem Quartal	Verlängerter Support für Ihre aktuelle Version, anschließend können Sie die Migration nach Ihrem eigenen Zeitplan durchführen
Läuft bereits auf einer unterstützten Node.js-Version, wenige veraltete APIs, Plugins werden gepflegt	Jetzt auf Version 5 aktualisieren
Das Framework ist über das EOL-Problem hinaus ungeeignet	Ersetzen Sie es und planen Sie die Kosten entsprechend ein

 Der lebenslange Support von TuxCare

Der „Endless Lifecycle Support“ (ELS) von TuxCare umfasst Open-Source-Laufzeitumgebungen, Bibliotheken und Frameworks, deren Lebenszyklus beendet wurde (EOL). Er stellt zurückportierte Sicherheitspatches für Versionen bereit, die vom Upstream-Projekt nicht mehr gepflegt werden – und zwar über das Standard-Paketmanagement, wodurch Änderungen an Ihrer Bereitstellungspipeline auf ein Minimum beschränkt bleiben. Speziell für Fastify sind die Versionen 3.29.5 und 4.29.1 abgedeckt, die letzten Veröffentlichungen der v3- und v4-Reihen. Korrekturen werden über npm bereitgestellt und öffentlich im CVE-Tracker von TuxCareverfolgt, sodass Ihr Sicherheitsteam vor der Freigabe genau sehen kann, was abgedeckt ist.

Für ein Team, das an einer Fastify-Linie am Ende des Lebenszyklus (EOL) festhängt – sei es eine v4-Flotte, deren LTS-Phase ein Jahr zurückliegt, oder eine v3-Flotte, deren LTS-Phase drei Jahre zurückliegt –, bedeutet dies, dass weiterhin Sicherheitspatches für die bereits im Einsatz befindliche Version erworben werden können, anstatt einen erzwungenen Sprung auf v5 vornehmen zu müssen, der ein Upgrade auf mehrere Node.js-Versionen mit sich bringt. Außerdem erhält man damit Patch-Dokumentation, die man bei einer SOC-2- oder PCI-DSS-Prüfung vorlegen kann, sowie einen Migrationszeitplan, den man selbst festlegt, anstatt sich nach einem Veröffentlichungskalender oder den Feststellungen eines Prüfers richten zu müssen.

Die Teams, die in diese Situation geraten, sind nicht faul. Sie haben mit echten Einschränkungen zu kämpfen: Grenzen der Plattformkompatibilität, bereits anderweitig gebundene technische Kapazitäten, die Komplexität von Tests über Dutzende von Diensten hinweg oder gesetzliche Vorschriften, die ein ungeplantes Framework-Upgrade zu einem Problem der Änderungskontrolle statt zu einem rein technischen Problem machen. Für einen Dienst aus der v3-Ära kommt dies oft eher einer vollständigen Umstellung auf eine neue Plattform gleich als einem einfachen Versionswechsel.

Die Rolle von TuxCare besteht hier darin, als Brücke zu fungieren und dafür zu sorgen, dass die von uns unterstützte Fastify-Version auf dem neuesten Stand bleibt, während die Migration nach Ihrem eigenen Zeitplan und nicht nach dem des Upstream-Projekts erfolgt.

Auf Fastify v5 aktualisieren

Das ist die richtige Entscheidung, wenn man es sich leisten kann, und bei einer v4-Flotte ist der Sprung kleiner als bei den meisten Upgrades auf eine neue Hauptversion. Der Migrationsleitfaden von Fastify ist wirklich kurz. Bei einer v3-Flotte sollten Sie eher mit den Kosten einer Plattformumstellung rechnen, da zwei Hauptversionen mit veralteten APIs abgearbeitet werden müssen und zudem ein Wechsel der Laufzeitumgebung von der derzeitigen, nicht mehr unterstützten Node-Version auf eine aktuell unterstützte Version erforderlich ist.

Vier Faktoren beeinflussen die Schätzung. Der erste ist die Laufzeitumgebung, da v5 Node.js 20 oder neuer erfordert und dieser Punkt nicht verhandelbar ist. Da Node 20 selbst ab April 2026 das Ende des Supports (EOL) erreicht, sollte eine neue Migration auf einer derzeit unterstützten LTS-Version basieren, was Ende 2026 Node 24 bedeutet, anstatt bei 20 stehen zu bleiben.

Die zweite Variante ist das vollständige JSON-Schema. Das jsonShorthand wurde entfernt, und wenn Sie den Standard-Validator verwenden, „querystring“, params, Bodysowie die „response“-Schemas erfordern alle vollständige Schemaobjekte, einschließlich des „type“ Eigenschaft.

Der dritte Punkt betrifft entfernte APIs. In Fastify v5 wurden die APIs entfernt, die im Laufe des v4-Lebenszyklus als veraltet markiert wurden. Die Veraltungswarnungen, an denen Sie in Ihren Protokollen bisher vorbeigescrollt sind, sind daher ein guter Ausgangspunkt für die Aufgabenliste. Wenn Sie von v3 kommen, müssen Sie also zwei Veraltungszyklen durcharbeiten statt nur einem.

Der vierte Punkt ist die Plugin-Kompatibilität. Jedes @fastify/* und jedes Community-Plugin benötigt eine v5-kompatible Version, und genau hier kommt es in der Regel zu Verzögerungen im Zeitplan. Am stärksten verzögert sich der Zeitplan bei älteren Plugin-Sets, an denen seit 2022 niemand mehr gearbeitet hat.

Wenn Ihr Plugin-Set ausschließlich aus First-Party-Plugins besteht, aktiv gepflegt wird und Sie von Version 4 umsteigen, bleibt der Aufwand in der Regel überschaubar. Wenn Sie hingegen von Version 3 umsteigen oder Community-Plugins verwenden, die schon seit Jahren nicht mehr weiterentwickelt werden, sollten Sie zunächst den Umfang der Ersatzarbeiten abschätzen. Denn genau dieser Teil kann aus einem überschaubaren Upgrade ein wesentlich umfangreicheres Migrationsprojekt machen.

Fastify ersetzen

Ein Framework-Wechsel zur Lösung eines EOL-Problems ist fast immer kostspieliger als ein Upgrade, und das gilt umso mehr ab Version 3, wo ohnehin schon eine umfassende Neuprogrammierung ansteht. Express 5, Hapi und Hono sind allesamt sinnvolle Frameworks, doch ein Wechsel zu einem dieser Frameworks kann erheblichen Aufwand bei der Neugestaltung von Routenregistrierung, Hooks und Middleware, Validierung, Plugins sowie dem frameworkspezifischen Anwendungscode bedeuten. Das ist eine Neuprogrammierung, die sich als Upgrade tarnt. Machen Sie es nur, wenn Fastify wirklich nicht zu Ihnen passt – und nicht, weil die Version zufällig das EOL erreicht hat.

Sichern Sie Fastify auch nach Ablauf der Lebensdauer mit TuxCare

Für Fastify v3 endete der LTS-Zeitraum im Juni 2023, für v4 folgte dieser Termin im Juni 2025. Keines dieser Daten stellte für sich genommen ein Risiko dar. Das Risiko besteht in der Zeitspanne zwischen dem für Ihre Flotte maßgeblichen Datum und dem Tag, an dem Ihr letzter EOL-Service auf einer unterstützten Plattform ausgeliefert wird – und für viele Teams lässt sich diese Zeitspanne im besten Fall in Quartalen, im schlimmsten Fall in Jahren messen.

Es gibt zwei Möglichkeiten, das Problem zu lösen: Entweder Sie steigen jetzt auf Version 5 um und nehmen das damit verbundene Laufzeit-Upgrade in Kauf, oder Sie patchen weiterhin die bereits installierten Versionen – einschließlich 3.29.5 und 4.29.1 –, während Sie die Migration nach einem Zeitplan durchführen, den Sie selbst bestimmen. Beide Vorgehensweisen sind vertretbar. Eine Version zu betreiben, deren Support ausgelaufen ist, und einfach auf das Beste zu hoffen, ist es hingegen nicht.

Wenn Sie zu dieser zweiten Gruppe gehören, bietet der „Endless Lifecycle Support“ von TuxCare sorgt dafür, dass EOL-Frameworks und -Laufzeitumgebungen, darunter Fastify 3.29.5 und 4.29.1, so lange mit Patches versorgt und auditfähig bleiben, wie Ihr Unternehmen sie benötigt.

FAQs