Das Ende von Express.js und die APIs, die nicht einfach so weiterbestehen können

Wichtigste Erkenntnisse

• Express 4 befindet sich seit April 2025 in der Wartungsphase, wobei das Ende der Lebensdauer (EOL) für Oktober 2026 vorgesehen ist.
• Nur die neueste Version einer Hauptreihe erhält Fehlerbehebungen, daher sind „angeheftete“ 4.x-Nebenversionen davon ausgenommen.
• Express 3 wurde im Juli 2015 aus dem Support genommen, und seitdem – seit August – wurden keine Fehler mehr behoben.
• Express 5 erfordert Node.js 18 oder höher, sodass ein Framework-Upgrade oft zu einer Laufzeitmigration wird.

Express hat sich seinen Ruf dadurch erworben, dass es sehr wenig tut. Minimalistisches Routing, eine Middleware-Pipeline und gerade so viele Konventionen, dass sich die Teams nicht mehr über die Ordnerstruktur streiten. Genau diese Zurückhaltung ist der Grund, warum so viele Dienste letztendlich auf Express gelandet sind, ohne dass jemand eine bewusste Entscheidung darüber getroffen hat, und warum niemand mehr einen Blick darauf wirft, sobald das Ganze einmal funktioniert.

So kommt es, dass eine Zahlungs-API sieben Jahre lang unverändert mit Express 4.17.1 läuft, bis ein Abhängigkeitsscanner sie meldet. Im Code hat sich nichts geändert. Was sich geändert hat, ist alles drumherum.

Der Widerspruch liegt in zwei Aussagen. Auf der Express-Website heißt es, dass die 4.x-Reihe weiterhin unterstützt wird. Ihr Abhängigkeitsscanner zeigt jedoch an, dass der Dienst anfällig ist. Beides ist gleichzeitig richtig, da die Unterstützung für die 4.x-Reihe nicht gleichbedeutend ist mit der Unterstützung für jede einzelne historische 4.x-Version.

Das ist keine Nachlässigkeit. Das ist Langlebigkeit. Der Verizon DBIR 2026 ergab, dass die Ausnutzung von Schwachstellen mittlerweile der häufigste Auslöser für Sicherheitsvorfälle ist: Sie macht 31 Prozent der Erstzugriffe aus – ein Anstieg von 20 Prozent im Vorjahr und zum ersten Mal in der 19-jährigen Geschichte des Berichts vor dem Missbrauch von Anmeldedaten. Die mittlere Zeit bis zur vollständigen Behebung verlängerte sich im gleichen Zeitraum von 32 auf 43 Tage. Anfällige Systeme sind in der Regel diejenigen, die gut genug funktionieren, sodass niemand ein Gefühl der Dringlichkeit verspürt, sich um sie zu kümmern.

Wird Express 4 nicht mehr weiterentwickelt?

Kurze Antwort: Nein. Express 4 hat bis August 2026 noch kein EOL erreicht, und für die 4.x-Reihe werden weiterhin Releases veröffentlicht. Die ausführlichere Antwort lautet: Die Uhr tickt bereits, und die Hauptversionsnummer sagt nichts darüber aus, ob das in Ihrer Lockfile festgelegte Release weiterhin Fehlerbehebungen erhält.

Während des größten Teils seiner Existenz gab es für Express überhaupt keinen LTS-Zeitplan. Das änderte sich im März 2025, als das Projekt eine LTS-Strategie veröffentlichte und gleichzeitig 5.1.0 zum npm-Standard machte. Hauptversionen durchlaufen nun die Phasen „CURRENT“, „ACTIVE“ und „MAINTENANCE“. Express 4 trat am 1. April 2025 in die „MAINTENANCE“-Phase ein, was bedeutet, dass nur noch Sicherheitspatches und Fehlerbehebungen mit hoher Priorität bereitgestellt werden, wobei das Ende der Unterstützung (EOL) frühestens für den 1. Oktober 2026 vorgesehen ist. Das Projekt bezeichnet diese Zeitpunkte als Ziele und nicht als verbindliche Zusagen und stuft v4 als Sonderfall ein, der möglicherweise verlängert werden könnte, doch die Richtung ist eindeutig.

Unterdessen werden auf der offiziellen Support-Seite für die Versionen 4.x und 5.x weiterhin als „laufend“ ohne Enddatum aufgeführt, neben einer Mindestversion von Node.js und einem Startdatum für den Support für jede Hauptversion. Die beiden Dokumente stimmen nicht überein, was eine heikle Antwort für einen Prüfer ist, der fragt, wann Ihr Framework nicht mehr unterstützt wird.

Die Regel, auf die es tatsächlich ankommt, steht in einer einzigen Zeile ganz oben auf dieser Support-Seite. Es wird nur die aktuellste Version einer jeweiligen Hauptversionsreihe unterstützt. Auf der Seite mit den Sicherheitsupdates wird dann Version für Version aufgeführt, welche Sicherheitslücken in welcher Version behoben wurden. Zusammengenommen sagen diese Angaben etwas aus, was die Versionsnummer allein nicht verrät: Eine unterstützte Hauptversion zu nutzen ist nicht dasselbe wie eine unterstützte Version zu nutzen.

Diese Unterscheidung entscheidet darüber, ob ein Prüfungsergebnis abgeschlossen oder offen bleibt. Die Tatsache, dass 4.x noch aktuell ist, sagt nichts über 4.17.1 aus, da Fehlerbehebungen in der neuesten 4.x-Version erfolgen und nicht in der Minor-Version, die 2019 festgelegt wurde. Wenn Sie die genaue Version in Ihrer Lockfile nicht angeben können, wissen Sie noch nicht, ob Sie unterstützt werden. Finden Sie sie heraus, bevor Sie sich mit dem Scanner anlegen.

Die Middleware-Zeitkapsel

Express an sich ist klein. Was einen alten Express-Dienst anfällig macht, ist alles, was daran angehängt wurde – Body-Parser, Session-Speicher, Authentifizierungsstrategien, Template-Engines und benutzerdefinierte Middleware, die vor Jahren von Leuten geschrieben wurde, die inzwischen das Unternehmen verlassen haben und nichts davon dokumentiert haben.

Allein durch die Aktualisierung von Express entsteht der falsche Eindruck, dass das Problem behoben ist. Auch wenn man das Framework aktualisiert und sieht, dass die Warnung auf oberster Ebene nicht mehr angezeigt wird, kann ein anfälliges, transitives Paket eine Ebene tiefer weiterhin unberührt vorhanden sein.

Express 4 deklariert etwa 30 direkte Abhängigkeiten, darunter qs, body-parser, send, serve-static, path-to-regexp, proxy-addrund forwarded, unter denen sich ein umfangreicherer, aufgeschlüsselter Baum befindet. Niemand hat diese Bibliotheken ausgewählt. Sie werden mit Express mitgeliefert, und eine Sicherheitslücke in einer dieser Bibliotheken wird zu einer Sicherheitslücke in Ihrer Anwendung, sobald der betroffene Codepfad erreichbar ist. Vier CVEs aus dem Jahr 2024 veranschaulichen, wie sich das auswirkt.

Das Problem dabei ist, dass 4.19.2 die Version ist, in der die „Open Redirect“-Sicherheitslücke behoben wurde, und dass sie dennoch älter ist als alle nachfolgenden Versionen. Eine Anwendung, die auf 4.19.2 läuft, hat die Sicherheitslücke CVE-2024-29041 behoben, weist jedoch weiterhin die XSS- und beide „Path-to-Regexp“-ReDoS-Schwachstellen auf, da diese Korrekturen erst in späteren Versionen der 4.x-Reihe implementiert wurden. Erwähnenswert ist auch, dass die Behebung der „Open Redirect“-Schwachstelle drei Anläufe erforderte: eine erste Korrektur in Version 4.19.0, die Behebung eines Regressionsfehlers in Version 4.19.1 und die endgültige Behebung der Umgehungsmöglichkeit in Version 4.19.2. Daher sind alle Versionen vor 4.19.2 hinsichtlich dieses Problems nicht vollständig gepatcht.

Warnung: Führen Sie vor der Triage folgenden Befehl aus: npm ls path-to-regexp qs send Vergleichen Sie den Abhängigkeitsbaum, den Ihre Anwendung tatsächlich enthält, und vergleichen Sie die aufgelösten Versionen mit Ihrer Lockdatei. Eine transitiv festgelegte Kopie, die von einer anderen Abhängigkeit eingebunden wird, kann ein Sicherheitsrisiko darstellen, selbst wenn Express selbst auf dem neuesten Stand ist.

Ein Vorbehalt sollte dabei beachtet werden: „Betroffen“ ist nicht gleichbedeutend mit „ausgenutzt“. Ob es sich bei einem Befund um einen Vorfall oder einen einzelnen Eintrag handelt, hängt davon ab, ob Ihre Anwendung den anfälligen Codepfad tatsächlich für von Angreifern kontrollierte Eingaben freigibt.

Genau diese Lücke sollen die Patches der Anbieter für Open-Source-Software schließen. Der Schutzumfang von TuxCare für Express erstreckt sich auf die unterstützten Komponenten, die zusammen mit einer abgedeckten Version ausgeliefert werden, und nicht auf die oberste Ebene express das Paket allein – darin liegt der Unterschied zwischen der Behebung eines Befunds und dessen Zurückstellung. Untersuchungen von Endor Labs schätzt, dass etwa 95 Prozent der Open-Source-Sicherheitslücken in transitiven Abhängigkeiten liegen und nicht in denen, die Entwickler direkt ausgewählt haben, und bei einer älteren Installation besteht selten die Möglichkeit, einfach auf den Zweig zu wechseln, in dem der Fix implementiert wurde. TuxCare’s CVE-Tracker zeigt den Patch-Status pro Version an, sodass Sie sehen können, auf welcher Seite dieser Linie Sie sich befinden.

Express 5 bringt Node.js mit sich

Was oft übersehen wird, wenn ein „Upgrade auf Express 5“ in den Budgetplan aufgenommen wird, ist, dass Express 5 Node.js 18 oder höher erfordert. Aus einem Framework-Upgrade wird somit eine Laufzeitmigration, an die ein Framework-Upgrade gekoppelt ist.

Express 5 hat zudem Verhaltensweisen geändert, auf die sich ältere Anwendungen stillschweigend verlassen haben. Abgelehnte Promises und von asynchronen Handlern ausgelöste Fehler werden nun automatisch an die Middleware zur Fehlerbehandlung weitergeleitet. Eine Reihe veralteter Signaturen wurde entfernt, darunter res.send(body, status) und die magische Zeichenfolge „back“ in res.redirect. Die Routenabgleichung wurde auf „path-to-regexp 8“ umgestellt, wodurch reguläre Ausdrücke mit Unterausdrücken in Pfadzeichenfolgen als Maßnahme zur Verhinderung von ReDoS entfernt wurden; daher müssen Routen, die auf diesen Mustern basieren, umgeschrieben werden.

Stellen Sie sich einen internen Schadensbearbeitungsdienst vor, der noch auf einem Container-Image aus der Node-14-Ära basiert. Der Umstieg von Express 4 auf 5 ist der einfache Teil. Der schwierige Teil besteht darin, dieses Image auf eine aktuell unterstützte Node.js-Version zu migrieren, die ohnehin die Mindestanforderungen von Express 5 erfüllt, ohne dass dabei native Module, die gegen die ältere ABI kompiliert wurden, nicht mehr funktionieren.

Der Migrationsleitfaden von Express selbst weist offen darauf hin, dass eine v4-Anwendung unter v5 möglicherweise nicht unverändert läuft, und diese Sichtweise ist hilfreich. Dadurch wird dies in erster Linie zu einem Laufzeit- und Testproblem und erst in zweiter Linie zu einem Framework-Problem.

Expertenrat: Bevor Sie Express aktualisieren, sollten Sie Ihre bestehende Testsuite mit der Node.js-Version ausführen, die Sie tatsächlich bereitstellen möchten. Etwas so Einfaches wie nvm use <target> && npm test wird Fehler bei nativen Modulen und der ABI aufdecken, die nichts mit Express zu tun haben.

Drei realistische Wege und ihre jeweiligen Kosten

Hier gibt es keine allgemeingültige Antwort, sondern nur diejenige, die zu Ihrem Abhängigkeitsgraphen, Ihrer Testabdeckung und Ihrer Laufzeit passt. Drei Ansätze decken die meisten Situationen ab.

Zu Express 5 wechseln

Dies ist die Option, wenn der Abhängigkeitsbaum aufgeräumt ist und die Integrationstests zuverlässig sind. Aktualisieren Sie die Laufzeitumgebung, aktualisieren Sie Express, arbeiten Sie sich durch die asynchrone Fehlerbehandlung und die Routing-Muster, und beobachten Sie, wie die CI-Ergebnisse auf „grün“ springen. Der Wechsel des Frameworks kann leicht den geringeren Teil der Arbeit ausmachen.

Bleiben Sie bei Version 4.x und verfolgen Sie die neueste Version

Für Anwendungen, die sich an herkömmliches Routing und gängige Middleware halten, ist dies noch vertretbar, auch wenn die Zeitspanne immer kürzer wird. Halten Sie sich an die aktuellste 4.x-Version, derzeit 4.22.2, und betrachten Sie dies als Routine und nicht als einmalige Maßnahme. Es ist auch nicht kostenlos. Am 1. Dezember 2025 veröffentlichte Express eine Änderung am Abfrage-Parser auf beiden Live-Zweigen, die unter der Kennung CVE-2024-51999 gemeldet worden war. Die CVE-Meldung wurde daraufhin als keine Sicherheitslücke zurückgewiesen, und in den Versionen 4.22.1 und 5.2.1 wurde die Änderung noch am selben Abend rückgängig gemacht – etwa vier Stunden nach Veröffentlichung der ursprünglichen Versionen. Doch damit war die Angelegenheit noch nicht abgeschlossen, da in Version 4.22 . 2 im Mai 2026 das Array-Parsing-Verhalten für wiederholte Abfrageschlüssel wiederhergestellt werden musste. Auf dem neuesten Stand zu bleiben bedeutet, dies in Kauf zu nehmen. Das Festhalten an einer unterstützten Hauptversion hilft nur so lange, wie man mit der Version weitermacht; sobald man bei einer älteren 4.x-Version stehen bleibt, befindet man sich wieder in derselben Lage wie alle, die auf 4.17.1 festgesetzt sind.

Erweiterter Support, während die Migration geplant wird

Damit bleiben die Fälle, die die ersten beiden nicht abdecken – eine eingefrorene Node.js-Laufzeitumgebung, benutzerdefinierte Authentifizierungs-Middleware oder eine Migration, die tatsächlich mehrere Quartale in Anspruch nimmt. Eine regulierte API mit einer maßgeschneiderten Authentifizierungsschicht und einer festgelegten Laufzeitumgebung kann leicht mehr als ein oder zwei Sprints erfordern, und wenn man das Projekt überstürzt, nur weil ein Scanner auf „rot“ gesprungen ist, kommt es zu Ausfällen. TuxCare ELS deckt bestimmte Express-Versionen ab, darunter 3.4.8, 3.21.2, 4.17.1, 4.18.1, 4.18.2, 4.18.3 und 4.19.2, die als „scoped“ verteilt werden @els-js Pakete über eine authentifizierte TuxCare-Registry.

Die Kurzfassung: Ein übersichtlicher Diagramm und Tests, von denen Sie überzeugt sind, sprechen für Express 5. Herkömmliches Routing und Standard-Middleware sprechen dafür, die neueste 4.x-Version im Auge zu behalten und dabei zu bleiben. Eine eingefrorene Laufzeitumgebung oder eine über mehrere Quartale erstreckende Migration deuten auf einen geplanten, statt unbefristeten Support hin – was jetzt umso wichtiger ist, da für 4.x ein Zieltermin für das Ende der Lebensdauer (EOL) festgelegt wurde.

Wie TuxCare Express-Versionen unterstützt, für die kein Support mehr angeboten wird

Die erweiterte Unterstützung für eine Bibliothek ist keine glamouröse Aufgabe, und genau darum geht es ja. Sie beginnt mit der Überwachung von Sicherheitslücken in der betreffenden Express-Version und den damit ausgelieferten, unterstützten Komponenten. Bei jeder neuen Offenlegung stellt sich zunächst die Frage, ob diese tatsächlich Auswirkungen auf diese Version hat oder ob sie nur später eingeführte Codepfade betrifft.

Wenn ein Patch erforderlich ist, wird ein diszipliniertes Backporting durchgeführt. Dabei wird die sicherheitsrelevante Änderung aus dem Upstream-Fix übernommen, die damit verbundene, aber nicht relevante Refactoring-Maßnahme wird zurückgelassen und es wird vermieden, ein Framework-Upgrade mit einzubeziehen, das niemand geplant hatte. Das Ergebnis wird vor der Veröffentlichung als gepflegtes Paket anhand des bisherigen Verhaltens auf Regressionen getestet, wobei gleichzeitig SBOM- und VEX-Daten veröffentlicht werden. Diese maschinenlesbaren Nachweise ermöglichen es einem Sicherheitsteam, einen Befund ordnungsgemäß zu dokumentieren, anstatt ihn auf das nächste Quartal zu verschieben. Dabei handelt es sich um eine Spezialisierung und nicht um einen Ersatz für den Upstream, was die langfristige Pflege von Zweigen bedeutet, die das Projekt bereits hinter sich gelassen hat, einschließlich Kompatibilitätstests, bevor etwas veröffentlicht wird.

Compliance-Teams fragen immer nach den Zeitvorgaben, daher hier die veröffentlichten Zielvorgaben: Für hohe und kritische Schwachstellen – also solche mit einem CVSS-Wert von 7,0 oder höher – gilt eine Zielreaktionszeit von 14 Tagen ab der öffentlichen Bekanntgabe, für mittlere Schwachstellen 60 Tage und für geringe Schwachstellen 90 Tage. Die betroffenen Versionen und Installationsschritte finden Sie in der Dokumentation zu „TuxCare ELS for Express“, einen Überblick erhalten Sie unter „EOL-Support für Bibliotheken“.

Wo OpenJS-Nachhaltigkeit ins Spiel kommt

Express ist ein „Impact-Projekt“ der OpenJS Foundation, und das ist von Bedeutung, da die Stiftung einen offiziellen Rahmen für den kommerziellen Support von archivierten, nicht mehr weiterentwickelten und älteren Projektversionen bietet. Das „OpenJS Ecosystem Sustainability Program“ wurde im Mai 2024 ins Leben gerufen, um kommerzielle Anbieter mit diesen Versionen zu vernetzen, wobei die Partner einen Teil ihrer Unternehmensumsätze an die teilnehmenden Projekte zurückführen.

TuxCare wird neben HeroDevs und NodeSource als ESP-Partner aufgeführt, und das Programm setzt voraus, dass die Partner Gold- oder Platin-Mitglieder der Stiftung sind. Auf der Node.js-Seite zum Produktlebenszyklus werden dieselben drei Anbieter genannt, was ein deutliches Zeichen dafür ist, dass es sich hierbei um ein etabliertes Modell und nicht um eine Improvisation handelt.

Zwei Einschränkungen sollten klar hervorgehoben werden: Das Programm ist nicht exklusiv und steht jedem Anbieter offen, der die Anforderungen erfüllt, und es hindert Maintainer nicht daran, öffentliche Korrekturen für beliebige Versionen zu veröffentlichen, einschließlich solcher, die von einem ESP-Partner abgedeckt werden. Außerdem ist zu beachten, dass auf der Support-Seite des Express-Projekts derzeit HeroDevs als kommerzielle Option aufgeführt ist. Daher sollten Sie die Abdeckung Ihrer spezifischen Version direkt bei dem Anbieter klären, den Sie in Betracht ziehen.

Realitätscheck: Ein Backport des Anbieters kann die in Version 4.17.1 betroffenen Sicherheitslücken beheben, macht 4.17.1 dadurch jedoch nicht zu einer vom Upstream unterstützten Version. Wenn eine Compliance-Anforderung ausdrücklich „Upstream-Unterstützung“ vorschreibt, beantwortet der Anbieter-Patch eine andere Frage – und es lohnt sich zu wissen, welche Frage genau gestellt wird.

So bewerten Sie eine alte Express-Anwendung

Bevor Sie sich für einen Weg entscheiden, sollten Sie sich darüber klar werden, wo Sie tatsächlich stehen. Beginnen Sie mit der genauen „Express“-Version in Ihrer Lockfile und nicht mit dem Bereich in package.json. Durchlaufen Sie die direkten und transitiven Abhängigkeiten mit npm ls und vergleichen Sie diese mit bekannten Sicherheitshinweisen. Erstellen Sie eine Bestandsaufnahme der benutzerdefinierten Middleware und aller undokumentierten Verhaltensweisen, auf die sich die Anwendung stützt. Stellen Sie fest, welche Node.js-Version die Anwendung nutzt und ob diese Laufzeitumgebung noch unterstützt wird, da dies darüber entscheidet, ob Express 5 überhaupt in Frage kommt. Gewichten Sie anschließend alle Aspekte nach Risiko und geschäftlicher Relevanz, sodass die Zahlungs-API Vorrang vor einem internen Dashboard mit geringem Datenverkehr erhält.

Eines kann leicht übersehen werden: Express kann auch indirekt über SDKs, Middleware-Pakete und andere Abhängigkeiten eingebunden sein, sodass Versionen, die niemand bewusst installiert hat, dennoch im Diagramm erscheinen. Eine Bewertung, die den Lebenszyklusstatus und indirekte Abhängigkeiten außer Acht lässt, liefert eher eine Liste als ein Gesamtbild.

Führen Sie Upgrades nach einem architektonischen Zeitplan durch – und nicht, weil eine Offenlegung den Zeitplan erzwungen hat. Der „Endless Lifecycle Support“ dient dazu, diesen Spielraum zu schaffen, sodass die laufende Version stets auf dem neuesten Stand bleibt, während die Migration nach einem Zeitplan erfolgt, den Sie testen und kontrollieren können.

Zusammenfassung

Artikel Name

Express.js: Ende des Lebenszyklus und Support für EOL-Versionen | TuxCare ELS

Beschreibung

Express 4 EOL ist ab Oktober 2026 vorgesehen, und nur die neueste Version erhält Fehlerbehebungen. Vergleichen Sie die Entwicklungswege und TuxCare ELS.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers