Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- „Moment“ und „Moment Timezone“ sind ältere Projekte, die sich im Wartungsmodus befinden; für neue Projekte sollten Alternativen verwendet werden.
- Der Status als veraltete Software bedeutet nicht, dass eine schnelle Deinstallation erforderlich ist, und er macht auch nicht jede Installation anfällig.
- Migrationen weg von Moment scheitern weitaus häufiger an der Veränderbarkeit und der nachsichtigen Analyse als an der Syntax.
- Wählen Sie einen Ersatz anhand der Zeitzone und des Parsing-Verhaltens, auf die Sie angewiesen sind, und nicht anhand von Benchmarks zur Bundle-Größe.
Moment ist eine der wenigen Bibliotheken, die ihre Nutzer öffentlich dazu aufgefordert hat, sie nicht mehr zu verwenden. Das Projekt wurde bereits 2020 als veraltet deklariert und in den Wartungsmodus versetzt; auf seiner npm-Seite wird es nach wie vor als veraltetes Projekt gekennzeichnet, das keine neuen Funktionen mehr erhält, und die README-Datei von „Moment Timezone“ geht sogar noch einen Schritt weiter und rät den meisten Nutzern, eine andere Bibliothek zu wählen. Das ist auf dem Papier noch kein Ende der Lebensdauer. Für ein Team, das an Version 2.24.0 gebunden ist, sieht das praktische Problem jedoch sehr danach aus, da Upstream-Korrekturen in der aktuellen Moment-Version implementiert werden und niemand im Upstream sie auf eine so alte Version zurückportiert.
Die Schwierigkeit besteht darin, dass der Austausch von Moment keine reine Syntaxübung ist. Seine Objekte sind veränderbar, und seine Syntaxanalyse ist in einer Weise fehlertolerant, wie es moderne Alternativen bewusst nicht sind. Daher äußert sich eine verpfuschte Migration eher in falschen Datumsangaben als in Kompilierungsfehlern.
Moment hat das Problem gelöst, noch bevor die Plattform fertig war
Moment.js kam auf den Markt, als die Datumsverarbeitung in JavaScript noch eine echte Qual war. Das Parsen und Formatieren verhielt sich von Engine zu Engine unterschiedlich, die Berechnung von Zeitzonen glich einem Ratespiel, und das Formatieren eines Datums ohne Hilfsbibliothek bedeutete manuelle String-Manipulation, für die sich niemand verantwortlich machen wollte. Moment hat das Problem gelöst – und zwar so gut, dass es fast ein ganzes Jahrzehnt lang zum Standard wurde. Sein Alter als Misserfolg zu betrachten, bedeutet, die Geschichte verkehrt herum zu sehen. Es löste ein echtes Problem, noch bevor die Plattform damit Schritt halten konnte.
Genau das macht die aktuelle Situation so seltsam. Man öffnet die Paketseite, um eine Version zu überprüfen, und die README-Datei öffnet sich mit dem Hinweis, dass es sich um ein veraltetes Projekt im Wartungsmodus handelt. Dann durchsucht man seine eigenen Repos mit „grep“ und stellt fest, dass Moment in drei davon enthalten ist.
Man könnte den „Wartungsmodus“ leicht als sanften Anstoß in Richtung einer neueren Version interpretieren. Damit verfehlt man jedoch den Kern der Sache. Es handelt sich um eine Aussage darüber, was behoben wird und was nicht, und sobald man es so versteht, ist die Version, die in Ihrem package.json sieht langsam anders aus.
Ist Moment.js veraltet, und was bedeutet „Wartungsmodus“?
Nicht im strengen Sinne. Es gibt weder eine datierte Ankündigung zum Ende der Lebensdauer noch einen „Tombstone“-Commit. Das Projekt hat sich vielmehr selbst als „Legacy-Projekt im Wartungsmodus“ bezeichnet und rät von einer neuen Einführung ab – was eine präzisere und sinnvollere Antwort ist als ein pauschales Ja oder Nein.
Die Betreuer legen den Umfang klar fest und haben ihn im August 2026 zum ersten Mal seit 2020 neu definiert. Moment wird weiterhin kritische Sicherheitsprobleme beheben, und die Aktualisierungen der Moment-Zeitzonendaten werden weiterhin den IANA-Veröffentlichungen folgen. Es werden nach wie vor keine neuen, benutzersichtbaren Funktionen hinzugefügt, und die mutable API wird nicht überarbeitet. Was sich geändert hat, ist der Umfang. Die Richtlinie von 2020 schloss jegliche Arbeiten an der Bundle-Größe und am Tree-Shaking sowie an einer Version 3 aus. Die Aktualisierung von 2026 erweitert diesen Umfang und ermöglicht es den Betreuern, sich mit der Paketierung, TypeScript-Deklarationen, Build-Tools und der Zusammensetzung von Bundles zu befassen.
Das waren auch nicht nur leere Worte. Version 2.31.0 wurde am 14. September 2026 veröffentlicht und enthielt einen Sicherheitspatch, eine lange Liste von Fehlerbehebungen sowie Aktualisierungen der Sprachpakete – die erste Veröffentlichung seit Version 2.30.1 Ende 2023.
Das Projekt hat zudem sein Versprechen aus dem Jahr 2020 zurückgenommen, niemals eine Version 3 zu veröffentlichen. Es gibt keinen Zeitplan für 3.0, und jede Version 3.0 wäre nach wie vor eher ein Wartungsrelease als eine Rückkehr zur Entwicklung neuer Funktionen, doch die Tür, die 2020 noch fest verschweißt war, ist nun lediglich geschlossen. Das ist die derzeitige Grenze, und sie ist etwas weiter gefasst als noch vor sechs Jahren.
Moment wird von der OpenJS Foundation als „At-Large“-Projekt betrieben und verfügt somit über eine neutrale Verwaltungsstruktur sowie eine veröffentlichte Sicherheitsrichtlinie. Keines dieser Elemente sieht die Finanzierung von Backports auf alte Release-Zweige vor. Ein Sicherheitspatch wird ausschließlich auf den aktuellen Code angewendet.
Realitätscheck: Für ein Team, das an die Version 2.24.0 gebunden ist, führt der Wartungsmodus zu einem Supportproblem, das dem Ende der Lebensdauer (EOL) gleicht. Die Sicherheitsmaßnahmen im Upstream-Bereich zielen auf die aktuelle Version von Moment ab, sodass der praktische Support-Horizont für Ihre Version bereits vor Jahren abgelaufen ist, auch wenn das Projekt selbst nach wie vor sehr lebendig ist.
Die CVE-Historie ist kurz und endet dort, wo man sie tatsächlich einsetzt
Die Anzahl der Sicherheitslücken bei Moment ist gering, was die gute Nachricht ist. Der Haken daran ist, dass sich jeder Eintrag im Code befindet, der Eingaben verarbeitet (Auswertung von Datums- und Zeitangaben sowie Laden der Ländereinstellungen), und genau diese Pfade werden in Anwendungen häufig mit Benutzerdaten gefüttert.
| CVE | Typ | Betroffene Versionen | Behoben in | CVSS |
|---|---|---|---|---|
| 31129 | ReDoS beim Parsen von RFC 2822 | 2.18.0 bis 2.29.3 | 2.29.4 | 7,5 Hoch |
| 24785 | Pfaddurchlauf über die Locale | 1.0.1 bis 2.29.1 | 2.29.2 | 7,5 Hoch |
| 18214 | ReDoS bei älterer Syntaxanalyse | vor 2.19.3 | 2.19.3 | 7,5 Hoch |
| 4055 | ReDoS bei der Daueranalyse | vor 2.11.2 | 2.11.2 | 6,5 Mittel |
CVE-2022-31129 weist ein quadratisches (N^2) Verhalten in preprocessRFC2822 Wenn die Funktion veraltete Kommentare aus einer Datumszeichenfolge entfernt. Gibt man ihr eine ausreichend lange Eingabe, kommt die Analyse zum Stillstand – eine klare Denial-of-Service-Primitiv. CVE-2022-24785 ist ein Pfadtraversal über eine vom Benutzer bereitgestellte Locale-Zeichenkette, die zum Umschalten der Locale von Moment verwendet wird; diese Schwachstelle wurde in Version 2.29.2 behoben. CVE-2017-18214 ist ein früherer ReDoS in den Parsing-Regexes älterer Versionen, und CVE-2016-4055 ist ein damit zusammenhängender ReDoS in duration(), behoben in Version 2.11.2.
Die Frage, die über den Schweregrad in Ihrer Anwendung entscheidet, ist eng gefasst. Kann eine vom Angreifer kontrollierte Eingabe den „Moment“-Konstruktor erreichen, moment.duration()oder den Locale-Switch – und was überprüft dies bei der Eingabe? Wenn nichts Unzuverlässiges diese Pfade erreicht, ist Ihr tatsächliches Risiko geringer, als es die reine Punktzahl vermuten lässt.
Vorsicht: Begrenzen Sie die Länge aller Datums- oder Zeitangaben, bevor diese an Moment weitergeleitet werden. Die Empfehlung der Maintainer zu CVE-2022-31129 sieht 200 Zeichen vor, wodurch der RFC2822-Fehler umgangen und das Risiko der beiden anderen Fehler deutlich verringert wird. In derselben Empfehlung heißt es, dass ein solcher Filter auch bei den meisten zukünftigen ReDoS-Fehlern hilft. Gegen den Locale-Fehler hilft er jedoch nicht. In diesen Fällen hilft nur manuelle moment.locale() eine Zeichenfolge aus einer Liste der tatsächlich ausgelieferten Sprachumgebungen.
Der unbegrenzte Lebenszyklus-Support von TuxCare für Moment.js betrifft die Versionen 2.0.0, 2.10.6 und 2.24.0, wobei alle drei unterhalb der 2.29.x-Korrekturen liegen. Die Path-Traversal-Sicherheitslücke (CVE-2022-24785) betrifft jede einzelne davon. Die ReDoS-CVE-Einträge unterscheiden sich je nach Version. Die RFC2822-ReDoS-Schwachstelle (CVE-2022-31129) betrifft nur Versionen ab 2.18.0, trifft also auf 2.24.0 zu, nicht jedoch auf die beiden älteren Versionen. Der ReDoS-Fehler durch veraltete Parsing-Verfahren (CVE-2017-18214) wurde bereits vor der Veröffentlichung von 2.24.0 behoben, sodass er nur in den Versionen 2.0.0 und 2.10.6 auftritt. Der ReDoS-Angriff über die Dauer (CVE-2016-4055) ist noch enger eingrenzt und betrifft nur Version 2.10.6. Version 2.0.0 fällt zwar in den veröffentlichten Bereich, aber ihre duration() analysiert Zeichenketten überhaupt nicht, daher ist der anfällige reguläre Ausdruck schlichtweg nicht vorhanden.
TuxCare hat bereits Patches für alle diese CVEs veröffentlicht, die für die von TuxCare unterstützten Versionen relevant sind. Im CVE-Tracker finden Sie alle Sicherheitslücken und verfügbaren Korrekturen für die von TuxCare unterstützte Open-Source-Software und deren Abhängigkeitsketten.
Die Wahl einer Alternative zu Moment.js ist der einfache Teil
Wenn Sie sich für eine dieser Optionen entschieden haben, ist die Auswahl überschaubar, und die Entscheidung fällt schnell. Die erste Option ist eine Bibliothek, die niemals an Ort und Stelle mutiert. Luxon und Day.js geben neue, unveränderliche Objekte zurück, während date-fns mit einfachen Date Werte und gibt neue zurück. Die zweite Variante stützt sich auf die integrierte Intl API für Formatierung und die Verarbeitung von Ländereinstellungen. Die dritte ist die native Temporal-API, die im März 2026 die TC39-Stufe 4 erreicht hat und bereits in Chrome, Edge und Firefox integriert ist. In Safari ist sie bislang nur als Technology Preview verfügbar, doch sobald sie überall verfügbar ist, wird eine Bibliothek eines Drittanbieters für viele Anwendungsfälle überflüssig.
Die schwierigere Frage ist, auf welche Funktionen von Moment Ihre Anwendung derzeit angewiesen ist, denn davon hängt ab, was beim Austausch nicht mehr funktioniert. Selbst eine Bibliothek, die objektiv besser konzipiert ist, kann bei genau denselben Eingaben, die Ihr Code seit Jahren an Moment übergibt, dennoch unterschiedliche Ergebnisse liefern.
Behandeln Sie „Moment Timezone“ als eigenständige Entscheidung. Es verfügt über ein eigenes Zeitzonen-Datenpaket und eine eigene API-Oberfläche, und der darauf aufbauende zeitzonenbezogene Code stellt den schwierigeren Teil der Aufgabe dar. Code, der lediglich Datumsangaben formatiert, lässt sich problemlos übertragen. Code, der Zeitzonenberechnungen über Sommerzeitgrenzen hinweg durchführt, hingegen nicht.
Die Datums-Semantik, die Migrationen zum Scheitern bringt
Genau hier scheitern Moment-Migrationen tatsächlich. Die API-Struktur lässt sich leicht umsetzen. Die ihr zugrunde liegende Semantik hingegen nicht.
Beginnen wir mit der Veränderbarkeit. Moment-Objekte werden an Ort und Stelle verändert, daher .add() und .startOf() Ändern Sie die Instanz, auf die Sie die Funktionen aufgerufen haben. Code, der eine gemeinsam genutzte Moment-Instanz weitergibt und davon ausgeht, dass jeder Aufruf diese Instanz verändert, ist von diesem Verhalten abhängig – oft, ohne dass es jemand bemerkt. Luxon, Day.js und Temporal geben stattdessen neue Objekte zurück, und die Funktionen von date-fns geben neue Date Werte. Wenn Sie dieses Aufrufmuster unverändert übernehmen, liefert es stillschweigend das falsche Ergebnis, anstatt eine Fehlermeldung auszugeben, da der Wert, den Sie ändern wollten, nie geändert wurde.
Dann ist da noch das Parsen. Moment ist von Haus aus großzügig. Es akzeptiert Eingaben, die strengere Bibliotheken rundweg ablehnen oder anders interpretieren, und wenn eine Zeichenkette weder ISO 8601 noch RFC 2822 entspricht, greift es auf die native Date Konstruktor – eine klassische Ursache für „Off-by-one-Day“-Fehler. Wenn man einen strengeren Parser einsetzt, werden Eingaben, die zuvor „funktioniert“ haben, nun möglicherweise abgelehnt oder einem anderen Tag zugeordnet.
Insider-Tipp: Auch die Format-Tokens sind nicht portabel. Bei Moment sind YYYY-MM-DD ist yyyy-MM-dd in date-fns und Luxon. Day.js behält die Tokens von Moment bei, und date-fns löst zumindest einen Fehler aus bei YYYY standardmäßig. Luxon wirft überhaupt nicht. Es erkennt nicht YYYY und gibt es wörtlich aus, und DD bedeutet dort ein lokalisiertes Datum, also YYYY-MM-DD Das Ergebnis sieht in etwa so aus: „YYYY-12-29. Dez. 2026“. Ein automatisches Suchen und Ersetzen in Token-Zeichenketten ist eine gut dokumentierte Methode, um unbemerkt falsche Ausgaben zu liefern, die kein Compiler erkennen wird.
Bei den Zeitzonen sieht es noch schlimmer aus. Ortszeit im Vergleich zu UTC, Umstellungen auf Sommerzeit und historische Zeitzonendaten können sich von Bibliothek zu Bibliothek geringfügig unterscheiden, und diese Unterschiede treten erst an bestimmten Daten zutage. Auch Ländereinstellungen und Format-Tokens unterscheiden sich, und nichts davon führt zu offensichtlichen Fehlern.
Gerade diese Art des Fehlers macht die Sache so gefährlich. Ihre Tests laufen erfolgreich ab. Der Build ist fehlerfrei. In der CI gibt es keinerlei Fehlermeldungen. Dann erscheint ein Monatsabschlussbericht einen Tag zu früh – allerdings nur für Nutzer in einer bestimmten Zeitzone und auch nur an der Zeitzonengrenze.
Stellen Sie sich ein SaaS-Analysetool vor, das rund 400 Moment-Aufrufstellen umfasst, verteilt auf Diagrammkonfiguration, CSV-Export und geplante E-Mail-Zusammenfassungen. Die Diagramme und Exporte werden ständig genutzt, sodass Fehler dort schnell entdeckt werden. Die geplanten Zusammenfassungen laufen einmal im Monat, formatieren einen Datumsbereich in der Zeitzone des Empfängers und senden einem Teil der Kunden einen ganzen Abrechnungszyklus lang unbemerkt den falschen Zeitraum, bevor es jemand bemerkt. So sieht eine fehlgeschlagene Moment-Migration in der Praxis aus.
Ein auf dem Verhalten basierender Ersatzplan
Ein Plan, der sich in einer umfangreichen Codebasis bewährt, orientiert sich am Verhalten und nicht an einer globalen Suche nach der Zeichenkette. moment. Die riskanten Teile werden bis zum Schluss aufgeschoben, sobald man die Gewissheit hat, dass die einfachen Teile halten.
Ermitteln Sie zunächst alle Verwendungen von „Moment“ und „Moment Timezone“, einschließlich transitiver Abhängigkeiten und Kopien, die in Anbieter-Bundles oder Komponentenbibliotheken eingebettet sind. Kategorisieren Sie anschließend jede Aufrufstelle danach, was sie tatsächlich tut – sei es Parsen, Formatieren, arithmetische Operationen, Lokalisierung oder Zeitzonenoperationen. Diese Kategorien bergen sehr unterschiedliche Migrationsrisiken, und wenn man sie alle in einen Topf wirft, kommt es zu unerwarteten Überraschungen für die Teams.
Fügen Sie Regressionstests für reale Datumswerte und bekannte Randfälle hinzu, bevor Sie auch nur eine einzige Zeile ändern. Sommerzeitwechsel, Schaltjahre, Monatswechsel und Nutzer außerhalb der UTC-Zeitzone sind die Fallstricke, die Ihnen Probleme bereiten können. Leiten Sie anschließend die Datumsverarbeitung über ein internes Datumsmodul, sodass die zugrunde liegende Bibliothek zu einem Implementierungsdetail wird, das Sie hinter einer stabilen Schnittstelle austauschen können – anstatt 400 direkter Aufrufe, die über den gesamten Code verstreut sind. Dieser Wrapper ist das Muster, das sich tatsächlich bewährt.
Erst dann sollten Sie die einfachen, risikoarmen Anwendungsfälle ersetzen – das schafft Vertrauen und liefert die Grundlagen für die schwierigeren Fälle. Vermeiden Sie vor allem, zwei Datumsmodelle ohne klare Abgrenzung zueinander im selben Geschäftsablauf zu verwenden, denn eine Mischung aus veränderbarer und unveränderbarer Logik in einem Ablauf ist eine wahre Fehlerquelle.
Entscheidungsfindung: Geringer Platzbedarf, solide Testabdeckung und keine Zeitzonenlogik? Dann migrieren Sie jetzt. Intensive Nutzung von Zeitzonen oder Ländereinstellungen? Führen Sie zunächst eine Umhüllung durch und migrieren Sie dann Modul für Modul. Ein „eingefrorenes“ Bundle oder eine Herstellerkomponente, die „Moment“ mit einbezieht? Aktualisieren Sie die Abhängigkeit oder überschreiben Sie sie, sofern die Paketierung dies zulässt, und betrachten Sie die vollständige Entfernung nicht länger als vorrangigen Punkt auf der Roadmap.
Wann es die vernünftigste Entscheidung ist, Moment vorübergehend zu behalten
Manchmal lautet die ehrliche Antwort, dass Sie in diesem Quartal keine Migration durchführen werden – und das kann die richtige Entscheidung sein. Denken Sie an regulierte Systeme oder Finanzdatenlogik, bei der ein Fehler von nur einem Tag bereits einen Verstoß gegen Compliance-Vorgaben darstellt, an große internationalisierte Anwendungen, deren lokalisiertes Verhalten niemand vollständig dokumentiert hat, an eingebettete Produkte mit langen Release-Zyklen oder an Anwendungen, bei denen die Testabdeckung nicht ausreicht, um eine überstürzte Migration zu validieren. In all diesen Fällen ist es riskanter, Moment unter Zeitdruck komplett zu entfernen.
Die Einschränkung ist eindeutig. „Vorübergehend“ erfordert einen Verantwortlichen, ein Datum und einen Beleg. Ohne diese drei Elemente bedeutet „vorübergehend“ lediglich, dass es bei der nächsten Prüfung immer noch dort steht.
Genau für diese Lücke sind die vom Hersteller unterstützten Patches gedacht. Das ELS von TuxCare deckt moment 2.0.0, 2.10.6 und 2.24.0 sowie moment-timezone 0.4.1, im Rahmen seiner Abdeckung von JavaScript-Bibliotheken. Korrekturen werden über npm mit SBOM- und VEX-Daten, sodass die Herkunft nachvollziehbar ist. Moment selbst hat keinerlei Laufzeitabhängigkeiten, daher konzentriert sich die Frage nach der Abdeckung auf Moment und nicht auf eine darunterliegende Paketkette.
Die Sicherheitspatches für die festgelegte Version werden weiterhin bereitgestellt, während Ihre verhaltensorientierten Migrationstests in einem angemessenen Tempo voranschreiten. Dadurch entfällt der Druck, die Datumslogik innerhalb einer Frist neu zu schreiben, die durch eine nicht damit in Zusammenhang stehende Offenlegung vorgegeben wurde. Sie können die Migration nach Ihrem eigenen Zeitplan durchführen und sind nicht an den Zeitplan der Offenlegung gebunden.
Wo OpenJS und Nachhaltigkeit ins Spiel kommen
Moment wird von der OpenJS Foundation gehostet, die das „Ecosystem Sustainability Program“ betreibt, damit archivierte, nicht mehr unterstützte und ältere Versionen ihrer Projekte kommerziellen Sicherheitsschutz erhalten, wobei ein Teil dieser Einnahmen an die Projekte zurückfließt. TuxCare beteiligt sich als Gold-Mitglied und Anbieter, und das Programm ist nicht exklusiv.
Die beste Alternative ist die, die sich bewährt hat
Benchmark-Zahlen helfen Ihnen am Monatsende nicht weiter. Die beste Alternative zu Moment.js ist diejenige, deren Semantik Sie anhand der Daten überprüft haben, bei denen sich Ihr Unternehmen keine Fehler leisten kann.
