Sicherheitslücken in Node.js: Die größten Risiken und wie man Apps im Jahr 2026 absichert

Wichtigste Erkenntnisse

• Sicherheitslücken in Node.js entstehen über drei Angriffsvektoren: die Laufzeitumgebung, npm-Abhängigkeiten (einschließlich transitiver Abhängigkeiten) sowie falsch konfigurierte HTTP-, TLS- oder Dateisystem-APIs.
• Pfadtraversierung, Prototyp-Verunreinigung, ReDoS und HTTP/2-DoS-Fehler sind die Schwachstellenklassen, die im Jahr 2026 in Produktionsumgebungen tatsächlichen Schaden anrichten.
• In den jüngsten Sicherheitsupdates wurden schwerwiegende Sicherheitslücken in den aktiven Release-Zweigen behoben – allerdings sind die Korrekturen für Node.js 20.x und darunter nicht mehr unterstützt und erhalten keine Upstream-Korrekturen mehr.
• Zur Erkennung ist eine Kombination aus npm audit, einem SCA-Scanner und Versionsprüfungen zur Laufzeit erforderlich; kein einzelnes Tool deckt alle Fälle ab.

Die meisten Sicherheitslücken bei Node.js beginnen nicht mit einem Zero-Day. Sie beginnen mit einer `package.json`-Datei, die seit 14 Monaten nicht mehr aktualisiert wurde und auf einer LTS-Version läuft, deren Support stillschweigend ausgelaufen ist. Sicherheitslücken bei Node.js lassen sich ungewöhnlich leicht übersehen – bis eine CVE in einer transitiven Abhängigkeit auftaucht, von der man gar nicht wusste, dass man sie hat, und plötzlich schreit einen der Scanner an und man kann nicht sofort erkennen, was tatsächlich angreifbar ist.

Dieser Artikel befasst sich mit den tatsächlichen Risiken im Jahr 2026: Was wurde mit den jüngsten Sicherheitsupdates behoben, welche Schwachstellenklassen tauchen in der Praxis immer wieder auf, wie lassen sie sich in Ihrer Infrastruktur aufspüren und welche Patch-Verfahren halten dem Druck von Audits stand.

Warum Node.js-Anwendungen häufig ins Visier genommen werden

Node.js befindet sich an der Schnittstelle dreier Faktoren, die Angreifer besonders schätzen: ein riesiges öffentliches Paket-Ökosystem, eine Single-Thread-JavaScript-Ereignisschleife, die CPU-Missbrauch ahndet, und eine Laufzeitumgebung, die häufig über HTTP-Server und APIs direkt mit dem Internet verbunden ist. Diese Kombination führt zu einer großen Angriffsfläche und einer sehr langen Reihe von nicht gepatchten Installationen.

Genauer gesagt:

• npm ist die größte Paket-Registry der Welt – und das am stärksten betroffene Ziel für bösartige Pakete. Sonatype blockierte allein im ersten Quartal 2026 136.107 Open-Source-Malware-Angriffe, wobei 75 % aller in diesem Quartal entdeckten neuen bösartigen Pakete auf npm entfielen.
• Single-Thread-Ausführung bedeutet, dass ein langsamer Regex-Ausdruck oder eine CPU-intensive Anfrage den gesamten Prozess zum Stillstand bringen kann – keine anderen Anfragen werden bearbeitet, bis dieser Vorgang abgeschlossen ist.
• Langfristige Produktionsbereitstellungen laufen oft auf EOL-Node-Versionen, da ein Upgrade bedeutet, jede Abhängigkeit auf kompatibilitätsbrechende Änderungen zu testen – was Teams auf unbestimmte Zeit aufschieben.
• Frameworks wie Express, Next.js und NestJS bilden die öffentlich zugängliche Ebene für einen Großteil der Web-APIs, sodass jede Schwachstelle bei der HTTP-Analyse, den Headern oder dem Routing direkt über das Internet ausnutzbar ist.
• Transitive Abhängigkeitstiefe – Eine typische Node.js-Anwendung bezieht Hunderte von Paketen ein, und die meisten Teams prüfen nur diejenigen, die sie selbst deklariert haben. Alles darunter läuft auf Vertrauensbasis.

Die häufigsten Sicherheitslücken bei Node.js

Dies sind die Kategorien, die in CVE-Meldungen, Scanner-Ausgaben und Nachbetrachtungen nach Vorfällen häufiger als alle anderen auftauchen. Da jede Kategorie ein anderes Behebungsmuster aufweist, spart es Zeit, sie auf den ersten Blick zu erkennen, wenn eine CVE-Meldung eingeht.

Prototyp-Verschmutzung

Eine Prototyp-Sicherheitslücke ermöglicht es einem Angreifer, Eigenschaften in Object.prototype, das dann in der Laufzeitumgebung auf jedem Objekt erscheint. Meistens schleicht es sich durch ungeprüfte Merge- oder Klonvorgänge bei JSON-Eingaben ein – so etwas, das harmlos erscheint, bis man merkt, dass die soeben festgelegte Eigenschaft nun von völlig unabhängigem Code gelesen werden kann. lodash, minimist, und verschiedene Konfigurationslader haben hierfür bereits CVEs gemeldet. Die Auswirkungen reichen von der Umgehung der Authentifizierung bis hin zur Ausführung von beliebigem Code, je nachdem, welcher nachgelagerte Code die kompromittierte Eigenschaft aufgreift.

Pfaddurchlauf in Datei- und HTTP-APIs

Das Thema „Path Traversal“ taucht immer wieder auf dieser Liste auf, weil Node.js immer wieder neue Randfälle entdeckt. 27210 war eine unvollständige Behebung eines Windows-spezifischen Fehlers in path.normalize() und path.join() die Gerätenamen wie CON, PRN und AUX betreffen – also genau die Art von Problem, die nur unter Windows auftritt und auf die fast niemand testet. CVE-2025-55130, behoben im Januar 2026, ist ein verwandtes Problem: Speziell gestaltete Symlink-Ketten können die Einschränkungen –allow-fs-read und –allow-fs-write des Berechtigungsmodells umgehen. Jeder Code, der einen vom Benutzer angegebenen Dateipfad akzeptiert, ist davon betroffen.

Denial-of-Service-Angriff mittels regulärer Ausdrücke (ReDoS)

ReDoS ist quasi eine typische Schwachstelle von Node.js. Aufgrund der single-threaded Event-Loop verlangsamt eine langsame Regex nicht nur eine einzelne Anfrage – sie blockiert den gesamten Prozess, bis die Regex abgeschlossen ist. Eine speziell gestaltete Eingabezeichenfolge – oft nur wenige hundert Zeichen mit dem richtigen Backtracking-Muster – kann von einem Angreifer aus der Ferne gesendet werden, um die CPU auf 100 % auszulasten und alle anderen Anfragen zu blockieren.

CVE-2024-21538 in Cross-Spawn ist ein gutes Beispiel dafür, wie weitreichend die Auswirkungen sind. Cross-Spawn ist eine transitive Abhängigkeit von Jest, ESLint, Webpack, Create-React-App und Tausenden anderer Tools – die meisten Node.js-Projekte nutzen es, ohne es zu wissen, über mehrere Ebenen hinweg. Eine einzige Sicherheitslücke in einem solchen Paket betrifft gleichzeitig Millionen von Projekten.

Angriffe auf die Lieferkette über npm

Schädliche Pakete in der npm-Registry – die entweder direkt veröffentlicht oder über kompromittierte Konten von Betreuern eingeschleust werden – stellen ein wachsendes Problem dar. Typosquatting (die Veröffentlichung von „lodesh“ in der Hoffnung, dass jemand das „e“ übersieht) gibt es schon seit Jahren, doch die ausgefeilteren Angriffe kompromittieren direkt legitime, weit verbreitete Pakete. Sobald sich eine bösartige Version in der Registry befindet, wird sie bei der nächsten Installation von jedem Projekt übernommen, das einen Versionsbereich (^ oder ~) anstelle einer festgelegten Version verwendet.

HTTP/2 und TLS-Denial-of-Service

Die HTTP/2-Implementierung in Node.js ist seit jeher eine häufige Quelle für DoS-Schwachstellen. CVE-2025-59465 ist das jüngste Problem im Zusammenhang mit dem HTTP/2-Server: Ein fehlerhaft formatierter HTTP/2-HEADERS-Frame führt zu einem Denial-of-Service-Absturz, ohne dass eine Authentifizierung erforderlich ist. CVE-2025-59464 betrifft einen Speicherleck bei der TLS-Fehlerbehandlung während der Verarbeitung von Client-Zertifikaten, das sich so lange aufbaut, bis dem Prozess der Speicher ausgeht. Für beide Schwachstellen ist keine ausgeklügelte Ausnutzung erforderlich; es müssen lediglich die richtigen Bytes an einen offenen Port gesendet werden.

In den Sicherheitsupdates von 2026 behobene Sicherheitslücken in Node.js

Node.js veröffentlichte im Jahr 2026 zwei wichtige Sicherheitsupdates – am 13. Januar und am 24. März –, die beide alle aktiven Release-Zweige betrafen. Das Release vom März ist besonders aufschlussreich: Eine der Korrekturen mit hohem Schweregrad war ein unvollständiger Patch vom Januar, was bedeutet, dass die TLS-Sicherheitslücke beim ersten Mal nicht vollständig geschlossen wurde. Das ist bei komplexen Laufzeiten nicht ungewöhnlich, unterstreicht jedoch, warum es wichtig ist, immer auf dem neuesten Point-Release zu bleiben, nicht nur auf dem neuesten Major-Release.

13. Januar 2026 Sicherheitsupdate:

Aktualisierte Versionen: 20.20.0, 22.22.0, 24.13.0, 25.3.0.

24. März 2026 – Sicherheitsupdate

Aktualisierte Versionen: 20.20.2, 22.22.2, 24.14.1, 25.8.2.

Hinweis: Node.js 20.x und darunter sind nun EOL – 18.x seit April 2025, 20.x seit dem 30. April 2026 – und es werden keine Upstream-Patches mehr bereitgestellt. v24.16.0 Die derzeit aktive LTS-Version ist 24.x (aktuellste Version: v24.16.0).

So erkennen Sie Sicherheitslücken in Node.js

Kein einzelnes Tool deckt alles ab. Gerade in den Lücken zwischen den Tools verbergen sich Schwachstellen am längsten – etwa etwas, das im npm-Audit nicht auftaucht, weil es noch nicht in der Advisory-Datenbank enthalten ist, oder etwas, das in Ihrem SCA-Scanner erkannt wird, aber nicht bei Ihrer Laufzeit-Versionsprüfung. Die folgenden Schritte stellen die Mindestanforderungen dar.

Führen Sie „npm audit“ aus – aber belassen Sie es nicht dabei

„npm audit“ ist kostenlos und standardmäßig integriert und überprüft Ihre npm-Pakete anhand bekannter CVE-Einträge (Common Vulnerabilities and Exposures) in der Sicherheitsdatenbank. Dennoch ist es nach wie vor die schnellste erste Überprüfung:

npm audit--audit-level=high
npm audit fix

Es werden Schwachstellen in der Node.js-Laufzeitumgebung selbst, in unveröffentlichten internen Paketen und in allem, was noch nicht an den GitHub Advisory Feed gemeldet wurde, übersehen. Betrachten Sie dies als Mindeststandard, nicht als Obergrenze.

SCA-Scanner hinzufügen

Ein Tool zur Software-Kompositionsanalyse – wie Snyk, Trivy oder GitHub Dependabot – schließt die Lücken, die ein npm-Audit hinterlässt: transitive Abhängigkeiten, Lizenzprobleme, Laufzeit-CVEs und Container-Basisimages. Der „Snyk State of Open Source Security“-Bericht 2024 ergab, dass 25 % der Teams nur direkte Abhängigkeiten überwachen und fast 5 % gar keine. Genau so bleiben transitive Schwachstellen monatelang ungepatcht. Derselbe Bericht ergab, dass der Anteil der Unternehmen, die in Schulungen zur Supply-Chain-Sicherheit investieren, von 53 % im Jahr 2023 auf nur noch 35 % im Jahr 2024 gesunken ist – obwohl die Zahl der Teams, die anfällige Pakete patchen oder ersetzen müssen, unverändert bei über 40 % blieb. Die Teams tun weniger, um dem Problem einen Schritt voraus zu sein, während dieses nicht kleiner wird.

Überprüfen Sie die Version Ihrer Node.js-Laufzeitumgebung

ausführen. node -v unter Berücksichtigung des Node.js-Veröffentlichungsplans und der neuesten CVE-Bulletins. Stand Mai 2026 ist die aktuelle LTS-Version 24.x, wobei 22.x noch im LTS-Wartungszyklus ist. Unterhalb von 22.x setzen Sie eine anfällige Laufzeitumgebung ein, unabhängig davon, wie sauber Ihr Abhängigkeitsbaum aussieht. Diese Überprüfung wird oft übersprungen, da die Laufzeitumgebung eher wie Infrastruktur wirkt – etwas, das das Plattformteam verwaltet – und nicht wie Anwendungscode, der in der Verantwortung des Entwicklers liegt. In der Praxis ist es beides.

Eine SBOM erstellen und überwachen

A Software-Stückliste liefert Ihnen den vollständigen transitiven Abhängigkeitsgraphen in einem Format, das Sie später erneut einlesen können, ohne den Code neu kompilieren zu müssen. Erstellen Sie einen solchen mit cyclonedx-npm oder syft, speichern Sie sie und vergleichen Sie sie wöchentlich mit den aktualisierten CVE-Feeds. Mit einer SBOM können Sie Schwachstellen aufspüren, die erst nach der Auslieferung bekannt wurden – ohne eine solche müssten Sie das Programm von Grund auf neu kompilieren, um sie zu finden.

Behalte die Node.js-Sicherheits-Mailingliste im Auge

Abonnieren Sie die Mailingliste „nodejs-sec“ – sie deckt alle sicherheitsrelevanten Veröffentlichungen im gesamten Node.js-Projekt und der vom Node.js-Team betreuten GitHub-Organisation ab. Vorab-Hinweise erscheinen in der Regel 3–7 Tage vor den Patches, was genügend Vorlaufzeit bietet, um Wartungsfenster einzuplanen und das Bereitschaftsteam zu informieren. Die meisten Entwickler erfahren von Node.js-CVEs über ihren Scanner – der dem Hinweis-Feed bereits ein oder zwei Tage hinterherhinkt.

Bewährte Verfahren zur Minderung von Sicherheitslücken in Node.js

Patches automatisieren

Manuelle Patch-Zyklen sind nicht skalierbar. Bis ein Mitarbeiter einen Fix geprüft, getestet und bereitgestellt hat, ist die CVE bereits so lange öffentlich, dass opportunistische Scans sie aufspüren können. Der Snyk-Bericht von 2024 ergab, dass 74 % der Teams SLAs von einer Woche oder weniger für Schwachstellen mit hohem Schweregrad festlegen – dennoch verfehlen 52 % diese Fristen regelmäßig. Das Problem liegt nicht im Aufwand, sondern in der schieren Menge an zu patchenden Problemen.

Automatisierung ist es, die diese Lücke tatsächlich schließt: automatisierte Abhängigkeitsaktualisierungen in der CI, automatisierte Laufzeit-Patches auf der Infrastrukturebene und automatisierte Warnmeldungen, die die richtigen CVEs an die richtigen Personen weiterleiten, anstatt alle mit Scanner-Meldungen zu überfluten.

Sichere und fixiere deine Abhängigkeiten

Verwenden Sie package-lock.json (oder pnpm-lock.yaml oder yarn.lock) und speichere die Änderungen. Gehe dann noch einen Schritt weiter: Lege für direkte Abhängigkeiten feste Versionen fest in package.json, keine Bereiche. Das ^ und ~ Operatoren sorgen dafür, dass eine „Korrektur“ in einem transitiven Paket das Laufzeitverhalten unbemerkt verändert, ohne dass Sie etwas tun müssen. In der CI führen Sie npm ci statt npm install – Der Build bricht ab, sobald Abweichungen zwischen der Lock-Datei und dem Manifest auftreten, sodass Sie das Problem erkennen, bevor das Produkt ausgeliefert wird.

Bleiben Sie bei aktiven LTS-Versionen

Das Node.js-Projekt folgt einem vorhersehbaren LTS-Zeitplan: Versionen mit geraden Nummern werden zu LTS-Versionen, solche mit ungeraden Nummern nicht. Node.js 20.x hat am 30. April 2026 das Ende der Lebensdauer erreicht, und 24.x ist die aktive LTS-Version. Node.js 18.x hat im April 2025 das Ende der Lebensdauer erreicht; 16.x im September 2023. Wenn Sie eine dieser Versionen verwenden, sammeln sich bei Ihnen CVEs an, für die es keine Behebungsmaßnahmen seitens des Upstream-Entwicklers gibt.

Der Upgrade-Pfad von 16.x, 18.x oder 20.x auf 22.x oder 24.x ist in der Regel gut zu bewältigen, erfordert jedoch die Überprüfung aller Abhängigkeiten. Das eigentliche Hindernis sind meist ein oder zwei Pakete, die nicht mit den neueren Node-APIs Schritt gehalten haben – es lohnt sich, diese zu identifizieren und zu beheben, anstatt eine Laufzeitumgebung, deren Lebensdauer bald endet, auf unbestimmte Zeit weiter zu nutzen.

Alle Eingaben an der Grenze validieren

Prototyp-Verunreinigung, Pfaddurchlauf, ReDoS, Befehlsinjektion – all dies sind im Grunde Fehler bei der Eingabevalidierung. Ein Schema-Validator wie zod, joi oder ajv an jeder HTTP-Grenze fängt das meiste davon ab, bevor es Ihre Anwendungslogik erreicht. Fügen Sie Benutzereingaben nicht in Objekte ein. Leiten Sie Benutzereingaben nicht an exec, eval, Function oder unbegrenzte Regex-Muster weiter. Das ist alles keine glamouröse Arbeit, aber genau hier liegt das eigentliche Risiko.

Mit minimalen Berechtigungen ausführen

Verwenden Sie das Node.js-Berechtigungsmodell, wo es sinnvoll ist (beachten Sie dabei, dass es sich noch im Versuchsstadium befindet und dokumentierte Lücken aufweist). Führen Sie Container als Nicht-Root-Benutzer aus. Verwenden Sie nach Möglichkeit schreibgeschützte Dateisysteme, entfernen Sie nicht benötigte Berechtigungen und betrachten Sie das Berechtigungsmodell als eine von mehreren Schichten und nicht als vollständige Sandbox.

Verwenden Sie eine veraltete Version von Node.js? TuxCare bietet erweiterten Sicherheitsschutz

Nicht jedes Unternehmen kann Upgrades nach dem Zeitplan des Anbieters durchführen. Node.js 16.x erreichte im September 2023 das Ende der Lebensdauer (EOL). Node.js 18.x folgte im April 2025. Für Teams, die diese Versionen noch nutzen – oft aufgrund einer bestimmten Abhängigkeitskette, einer Compliance-Anforderung oder einer laufenden Migration –, ist das praktische Problem offensichtlich: Es häufen sich immer mehr CVEs an, ohne dass ein Patch vom Hersteller verfügbar ist.

Der „Endless Lifecycle Support“ (ELS) von TuxCare für Node.js bietet hierfür eine direkte Lösung. TuxCare portiert Sicherheitspatches für Node.js 12, 14, 16, 18 und 20 zurück – und stellt sie Ihren Systemen so lange zur Verfügung, wie Sie sie benötigen, ohne dass Sie auf eine Upstream-Version warten müssen, die nicht erscheinen wird. Dies ist besonders nützlich für:

• Teams, die sich mitten in der Migration befinden und während des Umstiegs auf eine unterstützte LTS-Version Unterstützung benötigen
• Unternehmen mit Compliance-Anforderungen (PCI DSS, SOC 2, FedRAMP), die EOL-Laufzeitumgebungen als automatische Audit-Befunde behandeln
• Infrastrukturteams, die große Systemlandschaften verwalten, bei denen Node.js-Upgrades koordinierte Tests über Dutzende von Diensten hinweg erfordern

ELS-Patches decken die wichtigen Sicherheitslücken (CVEs) ab – also jene, die in Ihrem Scanner und in Compliance-Berichten auftauchen –, ohne dass Sie schneller vorgehen müssen, als es Ihr Migrationsplan zulässt.

Verringern Sie das Risiko von Node.js-Sicherheitslücken mit TuxCare

Die Sicherheitslücken bei Node.js werden nicht abnehmen. npm ist zu groß, die Laufzeitumgebung ist zu weit verbreitet, und die Zeitspanne zwischen der Veröffentlichung einer CVE und dem Zeitpunkt, zu dem die meisten Teams tatsächlich einen Patch installieren, ist nach wie vor beunruhigend lang. Die Teams, die dies gut im Griff haben, machen nichts Außergewöhnliches – sie haben die langweiligen Aufgaben automatisiert, sie überwachen die richtigen Feeds, sie wissen, was sich in ihrem Abhängigkeitsbaum befindet, und sie haben einen Plan für den Fall, dass eine Release-Linie das Ende ihrer Lebensdauer (EOL) erreicht.

Sowohl die Erkennung als auch die Behebung sind notwendig. Die Erkennung zeigt auf, wo ein Problem vorliegt; bei der Behebung wird die eigentliche Arbeit geleistet. Von beiden Faktoren ist die Zeit bis zur Patching-Maßnahme in der Regel der entscheidende Hebel – erst die Verkürzung des Zeitraums zwischen Bekanntgabe und Bereitstellung verringert das tatsächliche Risiko, nicht nur die „Sauberkeit“ der Scanner.

Bei Fragen zur Patch-Strategie oder zum erweiterten Support für Node.js -Versionen, deren Lebenszyklus abgelaufen ist, wenden Sie sich bitte an einen Sicherheitsexperten von TuxCare.

Zusammenfassung

Artikel Name

Sicherheitslücken in Node.js: Die größten Risiken und wie man Apps im Jahr 2026 absichert

Beschreibung

Die größten Node.js-Sicherheitslücken, mit denen Entwickler im Jahr 2026 konfrontiert sind, sowie bewährte Methoden zur Risikominimierung, schnelleren Patching und Absicherung der Anwendungsinfrastruktur.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers