Das Problem mit der Lodash-Sicherheitslücke hat sich geändert, Ihre festgehaltene Version jedoch nicht

Wichtigste Erkenntnisse

• Lodash war inaktiv, aber nicht mehr unterstützt, und seine Wiederbelebung führte zu neuen CVEs in Bezug auf Versionen, die seit Langem fest eingefroren waren.
• Ein einzelnes Estate kann mehrere Lodash-Versionen enthalten, von denen die meisten transitiv eingebunden werden.
• Eine anfällige Stelle zu finden, ist einfach; herauszufinden, welcher Codepfad dorthin führt, ist die eigentliche Herausforderung.

Niemand sitzt in einer Planungssitzung und beschließt, Lodash einzuführen. Es taucht einfach auf. Ein erfahrener Entwickler bindet eine Hilfsfunktion ein, ein Build-Tool führt es als Abhängigkeit auf, eine drei Ebenen tiefer liegende Diagrammbibliothek benötigt es _.merge, und plötzlich ist es in jedem App-Paket enthalten, das man ausliefert. Eine unauffällige Infrastruktur, kein Framework, für das sich jemand bewusst entschieden hat.

Es ist überall dort zu finden, wo eine JavaScript-Datei ausgeführt wird: im Frontend-Code, in Backend-Diensten, in Build-Tools, in CLIs, in Automatisierungsskripten und in dem längst aufgegebenen internen Paket, das ein Team im Jahr 2019 geschrieben hat und das seitdem niemand mehr geöffnet hat. Laut dem Bericht von Sonatype aus dem Jahr 2024 wurden allein über npm schätzungsweise 4,5 Billionen Paketabrufe in diesem Jahr verzeichnet, und Lodash ist eines der am häufigsten verwendeten Pakete in dieser Flut.

Dann kam die Wende, die weder in den Versionshinweisen noch in den meisten Retrospektiven Erwähnung fand. Version 4.17.21 wurde im Februar 2021 veröffentlicht, und jahrelang folgte nichts darauf. Die Teams interpretierten das Schweigen als Zeichen der Stabilität, legten die Version fest und machten weiter.

Diese Interpretation war falsch. Das Fehlen von Sicherheitshinweisen war niemals ein Beweis für Sicherheit. Es sagte wenig über die tatsächliche Gefährdung aus, und das wurde deutlich, sobald das wiederbelebte Projekt damit begann, seinen Sicherheitsrückstand aufzuholen.

Wird Lodash noch weiterentwickelt?

Ja, schon wieder, nach einer langen Pause. Lodash lag jahrelang praktisch brach und wurde 2025 wieder aktiv weiterentwickelt. Die darauf folgenden Sicherheitshinweise aus dem Jahr 2026 sind der Grund dafür, dass alte Pins wieder aufleuchteten.

Lodash entstand 2012 als Fork von Underscore, und sein Entwickler war zunächst bei den Stiftungen Dojo und jQuery tätig, bevor das Projekt bei der OpenJS Foundation landete, wo es nun in die Reifephase „Feature-Complete“ übergeht. Die jüngste Geschichte lässt sich am besten anhand einer Zeitleiste nachvollziehen.

Der Neustart ging mit konkreten operativen Maßnahmen einher: einem Plan zur Reaktion auf Vorfälle, einem veröffentlichten Bedrohungsmodell, GitHub-Sicherheitshinweisen, CodeQL-Scans, „Renovate“ für die Aktualisierung von Abhängigkeiten, einer OpenSSF-Scorecard und einer neu aufgebauten CI.

Wussten Sie schon: Die Sicherheitsempfehlung vom 17.04.23 wurde über die OpenJS CVE Numbering Authority eingereicht. Es handelte sich um die erste Sicherheitsveröffentlichung von Lodash seit mehreren Jahren, und eine derart koordinierte Offenlegung ist das Kennzeichen eines funktionierenden Sicherheitsprozesses und nicht eines ruhenden.

Hier kommt der entscheidende Punkt für alle, die noch alten Code verwenden: Durch diese erneute Betreuung wird die aktuelle Release-Reihe gepflegt und sicher gehalten. Das bedeutet jedoch nicht, dass jemand neue Fehlerbehebungen auf Version 3.10.1 zurückportiert.

Was ein wiederbelebtes Projekt mit einer angehefteten Version macht

Der Mechanismus ist einfach und gnadenlos. Eine neue Sicherheitsempfehlung kann einen unveränderten Pin in einen neu identifizierten betroffenen Bereich einordnen, ohne dass jemand Ihren Code verändert hat. Ihre Versionsnummer hat sich nicht geändert. Das bekannte Risikoprofil hingegen schon.

Drei Angaben verdeutlichen dies besonders anschaulich.

Umweltverschmutzung durch Prototypen in _.unset und _.omit wurde in Version 4.17.23 behoben. CVE-2025-13465 betrifft die Versionen 4.0.0 bis 4.17.22, sodass eine fünf Jahre alte PIN in Version 4.17.21 genau in diesen Bereich fällt.

Eine Umgehung dieser Korrektur wurde als CVE-2026-2950 registriert. Der Patch für Version 4.17.23 schützte String-Pfadsegmente, nicht jedoch solche, die in ein Array verpackt waren, sodass derselbe Löschangriff weiterhin möglich war. Lodash 4.17.23 und frühere Versionen sind betroffen; das Problem wurde in Version 4.18.0 behoben.

Code-Injektion in _.template durch Importieren von Schlüsselnamen, CVE-2026-4800, geht auf eine unvollständige Korrektur des älteren CVE-2021-23337 zurück. Der ursprüngliche Patch überprüfte zwar die Variable „option“, nicht jedoch die Namen der Import-Schlüssel, und beide Pfade münden in denselben Function() sink. Die Schwachstelle betrifft die Versionen 4.0.0 bis 4.17.23 und wurde in der 4.18-Reihe behoben.

Die Versionsauswahl erfolgt hier nicht automatisch. Die Version 4.18.0 wies einen Regressionsfehler im modularen Build auf, weshalb npm sie nun als veraltet kennzeichnet und den Hinweis „Fehlerhafte Version. Bitte verwenden Sie stattdessen [email protected]“ anzeigt. Dadurch werden Nutzer direkt zu einer Version zurückgeleitet, die von allen drei oben genannten CVEs betroffen ist. 4.18.1 ist die Version, die Sie tatsächlich benötigen. Einige der Einzelfunktionen lodash.* Auch die Pakete wurden auf der neuen Zeile neu generiert. lodash.unset liegt nun bei 4.18.0, während andere wie beispielsweise lodash.merge bleiben auf dem Stand 4.6.2 aus dem Jahr 2019 eingefroren, sodass ältere Projekte, die diese Builds direkt bündeln, jeden einzelnen davon überprüfen müssen.

Achtung: Ein grünes Scanner-Ergebnis für „lodash 4.17.21“ aus dem Jahr 2024 bleibt nicht dauerhaft grün – im Jahr 2026 veröffentlichte Sicherheitshinweise gelten rückwirkend für genau diesen Build, und nichts in Ihrer Lock-Datei weist Sie darauf hin, bis Sie einen erneuten Scan durchführen.

Stellen Sie sich eine Angular-Admin-Konsole aus dem Jahr 2018 vor, bei der Lodash 3.10.1 im Bundle enthalten ist, und lodash.merge durch zwei veraltete Diagrammbibliotheken aufgefallen. Im Scanner-Bericht ist nichts falsch, und es gibt darin auch nichts, worauf man reagieren müsste. Genau in dieser Lücke zwischen „korrekt“ und „nützlich“ beginnt die eigentliche Arbeit.

„Prototype Pollution“ hat die Sichtweise der Teams auf Utility-Bibliotheken verändert

Ein reiner String-Helper, der Text in Großbuchstaben umwandelt, überschreitet diese Sicherheitsgrenze nicht. Eine Funktion, die Objekte zusammenführt oder einen Wert an einem Pfad zuweist, tut dies hingegen schon – und genau dieser Unterschied macht den entscheidenden Unterschied aus. Beim Zusammenführen von Objekten und bei der Pfadzuweisung werden Einträge in Strukturen vorgenommen, auf die sich Ihr Code später verlässt, was eine Grenze darstellt _.capitalize kommt nie in die Nähe.

Die Angriffsmethode ist nicht ungewöhnlich. Man gibt einen speziell gestalteten Schlüssel ein, wie zum Beispiel __proto__ oder constructor.prototype zu einem „vulnerable merge“ oder „path setter“, und Sie können auf die gemeinsamen Prototypen zugreifen, von denen gewöhnliche Objekte erben, beginnend mit Object.prototype. Im harmlosesten Fall kommt es zu einem Denial-of-Service, wenn nachgelagerter Code an einem fehlerhaften Objekt hängen bleibt. Im schlimmsten Fall, mit der entsprechenden Ausgabestelle wie beispielsweise einer Template-Engine oder einer Function() Bei einem Aufruf wird die Prototyp-Verfälschung zu einem Einfallstor für die Ausführung von Code. Ein Vorbehalt bei diesen speziellen Lodash-Sicherheitshinweisen: die _.unset und _.omit Aufgrund dieser Sicherheitslücken können Eigenschaften aus gemeinsam genutzten Prototypen gelöscht statt überschrieben werden, sodass die tatsächlichen Auswirkungen eher in Form von Funktionsstörungen und Denial-of-Service-Angriffen auftreten als in der klassischen Kette von „Pollution to RCE“.

Präzision ist jedoch entscheidend. Nicht jeder Aufruf einer betroffenen Funktion ist ausnutzbar. Entscheidend ist, ob ein Angreifer das zusammengeführte Objekt oder den Schlüsselpfad beeinflussen kann. Sind beide vollständig unter der Kontrolle des Entwicklers und können nicht durch nicht vertrauenswürdige Eingaben erreicht werden, ist das Risiko gering. Kann eines von beiden durch einen Request-Body, einen Query-String oder eine geparste Datei beeinflusst werden, sollten Sie den Pfad als potenziell ausnutzbar behandeln, bis Sie dies ausgeschlossen haben. Diese Unterscheidung ist es, die einen Behebungsplan von einer bloßen CVE-Liste unterscheidet, die Ihnen suggeriert, dass alles in Flammen steht.

Der Abhängigkeitsgraph ist das eigentliche Korrekturprojekt

Eine anfällige Lodash-Kopie zu finden, kann mit einem einzigen Scan gelingen. Herauszufinden, was dagegen zu tun ist, dauert jedoch deutlich länger. Der „Snyk State of Open Source Security“-Bericht 2022 ergab, dass eine durchschnittliche Anwendung in der Entwicklung 49 Schwachstellen in 69 Abhängigkeiten aufweist, und Hilfsbibliotheken wie Lodash gehören genau zu der Art von Bibliotheken, die mehrere Ebenen tief eingebettet sind.

Die Arbeit selbst ist konkret genug. Beginnen Sie damit, die übergeordnete Abhängigkeit zu identifizieren, die die jeweilige Lodash-Version einführt, und klären Sie dann, ob eine Duplikatsbereinigung wirklich sicher ist oder ob zwei Verbraucher tatsächlich unterschiedliche Hauptversionen benötigen. Entscheiden Sie, ob Überschreibungen oder Auflösungen nachhaltig sind oder lediglich aufgeschobene Schulden darstellen. Testen Sie gebündelte und serverseitige Kopien separat, da sie unabhängig voneinander aufgelöst werden. Machen Sie sich anschließend auf die Suche nach fest codierten oder manuell kopierten Builds, die npm überhaupt nicht erkennen kann.

Lodash wird ohne eigene Laufzeitabhängigkeiten ausgeliefert, daher ist der darunterliegende Baum leer. Das Problem kehrt sich um. Lodash ist als Blatt in Tausenden anderer Bäume vertreten, und genau dort vermehren sich die Kopien. Bei unterstützten Versionen kann TuxCare ELS anfällige direkte und transitive Kopien durch gepatchte Builds ersetzen – und genau darum geht es, wenn ein Scanner sechs verschiedene Versionen in einem Repository meldet.

Aus der Praxis: Teams können „Lodash aktualisieren“, das Ticket schließen und dennoch beim nächsten Scan durchfallen. Sie haben die oberste Abhängigkeit aktualisiert und drei transitive Kopien der Version 4.17.15 unverändert gelassen, da bei einer direkten Aktualisierung die festgelegten Versionen der untergeordneten Pakete nicht überschrieben werden.

Die Entfernung verdient eine ehrliche Anmerkung. Dank optionaler Verkettung, Spread-Syntax und moderner Array-Methoden sind viele Lodash-Hilfsfunktionen überflüssig geworden. Die Semantik der tiefen Zusammenführung, cloneDeep Randfälle, debounce Verhalten und die fp Module sind eine andere Sache.

Damit kommen wir zur Entscheidung. Wenn Lodash nur hinter einer Handvoll einfacher Aufrufstellen steht, ist es in der Regel die sauberere Lösung, es zu entfernen. Wenn _.merge oder _.cloneDeep Wenn die Finanz- oder Berichtslogik betroffen ist, sollten Sie die Entfernung als Verhaltensänderung mit einem eigenen Testplan behandeln, da eine solche Änderung zwar die kontinuierliche Integration (CI) bestehen kann, dann aber zu Fehlern im Monatsabschlussbericht führen kann.

Vier Sanierungswege

Es gibt keine Patentlösung, und wenn man so tut, als wäre es anders, kommt die Sanierung ins Stocken. Es gibt vier realistische Ansätze, und die meisten Immobilienbestände nutzen mehr als einen davon.

Genau hier kommt ein Hersteller-Patch ins Spiel. TuxCare ELS for Libraries deckt Lodash 1.3.1, 2.4.2, 3.2.0, 3.10.1, 4.5.0, 4.17.4, 4.17.5, 4.17.11, 4.17.15, 4.17.19, 4.17.21 und 4.18.1 ab. Somit profitiert auch die Version, von der Sie noch nicht umsteigen können, von den Sicherheitsvorteilen des Upstream-Patches.

Der Mechanismus ist nicht gerade spektakulär, aber genau darum geht es ja. Man fügt einen npm-Alias im Stammverzeichnis hinzu package.json neben overrides So werden transitive Kopien auf den gepatchten Build aufgelöst, oder Sie führen den TuxCare Patcher auf einem Repository aus, das mehrere abgedeckte Abhängigkeiten enthält. Das ist die direkte Lösung für das Problem der transitiven Kopien.

Insider-Tipp: Deklarieren overrides im Stammverzeichnis package.json, da npm Überschreibungen ignoriert, die innerhalb installierter Abhängigkeiten deklariert wurden. Verweisen Sie diese auf die gepatchte Version mit Alias, damit npm übereinstimmende Vorkommen des Namens des anfälligen Pakets im gesamten Abhängigkeitsbaum auf den gepflegten Ersatz auflöst.

Wie TuxCare ältere Lodash-Versionen sichert

Das Backportieren eines Fixes in eine zehn Jahre alte Utility-Bibliothek ist keine einfache Kopier-und-Einfüge-Aufgabe, und wenn man es so behandelt, bringt man genau jene Randfälle zum Absturz, auf die sich Anwendungen verlassen. Der Prozess läuft in vier Schritten ab.

Analysieren Sie zunächst, ob jede neue Offenlegung tatsächlich eine betroffene Version betrifft, anstatt davon auszugehen, dass ein veröffentlichter Versionsbereich die Ausnutzbarkeit in jeder Anwendung beschreibt. Portieren Sie zweitens die Sicherheitsabsicht zurück, ohne dabei irrelevante Verhaltensänderungen mit einzubeziehen. Diese Zurückhaltung ist hier wichtiger als fast überall sonst, da Anwendungen auf dem Verhalten von Lodash in Randfällen beruhen, das durch eine gut gemeinte Umgestaltung unbemerkt verändert würde.

Drittens sollten sowohl die allgemeinen Funktionen als auch die konkret betroffenen Pfade einer Regressionstest unterzogen werden, damit eine Korrektur der Prototyp-Kontamination keine Auswirkungen auf das hat, was _.merge gibt für ein gültiges verschachteltes Objekt Ergebnisse zurück. Viertens: Signieren Sie jedes erstellte Paket und veröffentlichen Sie SBOM- und VEX-Dokumente zusammen mit jeder Version, damit Ihre Prüfer eine nachweisbare Herkunft erhalten und nicht nur ein Versprechen.

Hierbei handelt es sich um Wartungsarbeit und nicht um Upstream-Innovation – und diese Unterscheidung ist bewusst gewählt. TuxCare hat sich darauf spezialisiert, Produktionscode sicher und stabil zu halten, nachdem die Upstream-Prioritäten sich anderen Themen zugewandt haben, und bietet dabei vorhersehbare, auf Kompatibilität ausgerichtete Patches für Systeme, die voraussichtlich noch jahrelang laufen werden.

Wer hat den Lodash-Reset bezahlt, und warum ist das Modell von Bedeutung?

Lodash ist das deutlichste Beispiel für ein Muster, das es verdient, namentlich genannt zu werden. Die von der Sovereign Tech Agency bereitgestellten Mittel, die mit Unterstützung der OpenJS Foundation verwaltet wurden, finanzierten die Arbeit an Governance und Sicherheit einer Bibliothek, auf die Millionen von Systemen angewiesen sind, und der Bericht der OpenJS Foundation ist es wert, vollständig gelesen zu werden.

Was diese Finanzierung jedoch nicht abdeckt, ist die unbefristete Weiterentwicklung von 3.10.1. Sie hat das aktuelle Projekt gestärkt; sie hat die Freiwilligen jedoch nicht dazu verpflichtet, Korrekturen auf eine Version aus dem Jahr 2015 zurückzuportieren, und wenn man so tut, als wäre es anders, führt das dazu, dass die Betreuer ausbrennen.

Das „Ecosystem Sustainability Program“ schließt diese Lücke auf kommerzieller Basis, wobei ein Teil der Einnahmen an die teilnehmenden Projekte zurückfließt. TuxCare ist Gold-Mitglied der OpenJS Foundation und einer der Anbieter des Programms, der neben HeroDevs und NodeSource auf der Node.js-Seite zum Produktlebenszyklus aufgeführt ist.

Das sollte klar gesagt werden, denn so bleiben alle ehrlich. Ein Hersteller-Patch für 4.17.21 ist ein Hersteller-Patch, keine Upstream-Version, und gute Tools machen diese Herkunft deutlich, anstatt sie zu verbergen. Und wenn eine Kopie überhaupt nicht aktualisiert werden kann, liefert ELS für Lodash die Korrekturen über npm an die Version, die Sie tatsächlich ausführen – so lange, wie Sie diese ausführen müssen.

FAQ

Ist Lodash nicht mehr aktuell?

Nein. Es lag jahrelang auf Eis, wird nun aber im Rahmen von OpenJS wieder aktiv weiterentwickelt – mit einem finanziell abgesicherten Neustart der Governance und einer aktuellen Version aus der 4.18-Reihe.

Ist 4.17.21 immer noch sicher?

Dies gilt nicht für die seit der Wiederaufnahme bekannt gewordenen Sicherheitslücken. Es fällt in den betroffenen Bereich der folgenden drei Sicherheitshinweise: CVE-2025-13465 und CVE-2026-2950 (Prototyp-Verfälschung in _.unset und _.omit, einschließlich einer Umgehung des ersten Fixes) und CVE-2026-4800 (_.template Code-Injektion). Durch ein Upgrade auf Version 4.18.1 werden alle drei Probleme behoben, ebenso wie durch eine gepflegte Version, die Korrekturen für jedes einzelne Problem enthält.

Sollte ich die Version 4.18.1 verwenden?

Bei aktiv gepflegten Projekten ja. 4.18.1 ist die aktuelle Version und behebt den in 4.18.0 enthaltenen Regressionsfehler beim modularen Build. Falls eine bestimmte ältere Version fest in Ihrem Graph integriert ist, bietet sich eine gepatchte und gepflegte Version im Rahmen des „Endless Lifecycle Support“ von TuxCare als Alternative an.

Brauche ich Lodash überhaupt noch?

Oftmals nicht. Die native Syntax hat viele der einfachen Hilfsfunktionen ersetzt, und structuredClone deckt gängige Fälle des Deep Cloning ab, verwirft jedoch Klassenprototypen und Metadaten zu Eigenschaften und löst einen Ausnahmetyp aus, wenn Werte nicht geklont werden können, einschließlich Funktionen. Deep Merge, debounce, und die fp Für das Modul gibt es noch immer keinen übersichtlichen Ersatz in einer Zeile.

Bevor Sie das Ticket schließen

„Lodash aktualisieren“ gilt erst dann als Abhilfemaßnahme, wenn alle erreichbaren Kopien erfasst sind. Im TuxCare-CVE-Tracker können Sie die aktuellen Sicherheitshinweise für jede betroffene Version nachverfolgen.

Zusammenfassung

Artikel Name

Warum Lodash 4.17.21 nicht mehr die sichere Lösung ist | TuxCare ELS

Beschreibung

Lodash blieb fünf Jahre lang bei Version 4.17.21, dann wurden neue CVEs veröffentlicht. Finden Sie heraus, wo sich alte Kopien verstecken und wie TuxCare diese behebt.

Autor

Tim Walker

Name des Herausgebers

TuxCare

Logo des Herausgebers