lodash 4.17.21: Die versteckten Kosten beim Einsatz veralteter JavaScript-Abhängigkeiten

Wichtigste Erkenntnisse

• Lodash 4.17.21 ist nicht mehr der sichere Endpunkt, als der es jahrelang galt, und weist nun drei bestätigte Sicherheitslücken auf – CVE-2025-13465, CVE-2026-2950 und CVE-2026-4800 –, die erst in Version 4.17.23 und der 4.18.x-Reihe behoben wurden.
• Die größte Herausforderung bei der Behebung liegt eher auf organisatorischer als auf technischer Ebene. Daher sind die Erfassung der tatsächlichen Aufrufstellen, die Absicherung der Eingaben an der Schnittstelle und die Überwachung auf Missbrauch die Maßnahmen, die Zeit gewinnen, wenn ein sofortiges Upgrade nicht realistisch ist.
• Durch einen Dienst wie den ELS for Libraries von TuxCare rückportierte Korrekturen ermöglichen es Teams, den als stabil geltenden Build 4.17.21 zu sichern und gleichzeitig eine wohlüberlegte Migration auf 4.18.x zu planen, anstatt eine riskante Migration überstürzt durchzuführen.

Ihr Team weiß um die Sicherheitslücken. Das Ticket ist seit neun Monaten offen. Niemand hat sich darum gekümmert. Hier geht es darum, warum das so ist – und was man tun kann, anstatt abzuwarten.

Es gibt eine bestimmte Art von Sicherheitslücke, die nicht behoben wird. Nicht, weil die Entwickler nachlässig sind, und auch nicht, weil die Sicherheitsteams schlummern – sondern weil die Behebung zwar technisch möglich, aus betrieblicher Sicht jedoch erschreckend ist. Die Lodash-Version 4.17.21 ist das Paradebeispiel für dieses Muster in modernen JavaScript-Projekten und ist seit Jahren in Produktionsumgebungen branchenweit im Einsatz.

Dieser Beitrag ist keine Aufschlüsselung der CVE-Nummern. Diese können Sie selbst nachschlagen. Hier geht es um die Kluft zwischen dem Wissen, dass etwas nicht stimmt, und der Fähigkeit, etwas dagegen zu unternehmen – sowie um die praktischen Wege, wie Teams diese Kluft überwinden, ohne so zu tun, als gäbe es sie nicht.

Wie es zu Lodash 4.17.21 kam und warum es sich durchgesetzt hat

Lodash wurde zu einem der am häufigsten heruntergeladenen JavaScript-Pakete aller Zeiten, weil es ein echtes Problem löste: Die Standardbibliothek von JavaScript war dürftig, in den verschiedenen Umgebungen uneinheitlich, und die Browserkompatibilität glich einem Minenfeld. Zu seiner Blütezeit wurde Lodash überall eingesetzt – von Nebenprojekten von Start-ups bis hin zu Unternehmensplattformen von Fortune-500-Unternehmen.

Dann reifte modernes JavaScript heran. Die nativen Array-Methoden wurden verbessert. ES6 und spätere Versionen übernahmen viele der von Lodash eingeführten Utility-Muster. Neuere Projekte kamen ohne Lodash aus. Aber bestehende Projekte – insbesondere große, über Jahre hinweg gewachsene Codebasen – konnten Lodash nicht einfach so entfernen. Dort hatten sich Tausende von Aufrufstellen angesammelt. Eine Umgestaltung dieser Stellen war ein gewaltiges Unterfangen mit ungewissem Erfolg.

Die im Februar 2021 veröffentlichte Version 4.17.21, die eine schwerwiegende Sicherheitslücke im Zusammenhang mit Befehlsinjektionen in _.template (CVE-2021-23337) sowie ein Denial-of-Service-Problem im Zusammenhang mit regulären Ausdrücken (CVE-2020-28500) behob, wurde für einen Großteil des Ökosystems zur festgelegten Referenzversion. Und dort blieb sie fast fünf Jahre lang, ohne dass weitere Versionen veröffentlicht wurden. Nicht, weil 4.17.21 dauerhaft sicher wäre: Ein neues Governance-Team hat inzwischen neue Schwachstellen offengelegt, die diese Version betreffen – Prototyp-Verunreinigungen in _.unset und _.omit (CVE-2025-13465 und CVE-2026-2950) sowie eine Umgehung der Code-Injektionssicherung in _.template (CVE-2026-4800). Die Korrekturen sind nun in der lodash 4.18.x-Reihe enthalten, doch ein Upgrade oder die vollständige Entfernung von lodash ist aufwendig, und die Kosten-Nutzen-Rechnung spricht selten dafür, dies sofort zu tun.

Das Problem der transitiven Abhängigkeit

Viele Teams, die Lodash 4.17.21 einsetzen, tun dies nicht einmal direkt. Die Sicherheitslücke befindet sich drei Ebenen tiefer, in einer Abhängigkeit einer Abhängigkeit eines Frameworks, das sie vor zwei Jahren installiert haben. Führen Sie folgenden Befehl aus: npm ls lodash in einem mittelgroßen Node.js-Projekt aus, und Sie werden oft einen verzweigten Baum indirekter Verweise vorfinden. Der Anwendungscode selbst importiert „lodash“ möglicherweise gar nicht.

Das macht die Frage nach der Zuständigkeit äußerst heikel. Wer ist dafür verantwortlich, eine transitive Abhängigkeit zu beheben, die kein Teammitglied absichtlich eingeführt hat? Die Sicherheitsabteilung meint, dies sei Aufgabe der Entwicklungsabteilung. Die Entwicklungsabteilung meint, dies sei Aufgabe des Teams, das für das vorgelagerte Paket verantwortlich ist. Dieses Team meint, die Schwachstelle sei im aktuellen Einsatzkontext technisch nicht ausnutzbar. Das Ticket bleibt offen.

Die Psychologie der bekannten Verwundbarkeit

In der Sicherheitsliteratur liegt der Schwerpunkt stark auf unbekannten Bedrohungen – dem Zero-Day, dem neuartigen Angriffsvektor, dem Angreifer, der schneller ist als die Verteidiger. In der Praxis lässt sich jedoch ein erheblicher Teil der tatsächlichen Vorfälle auf Schwachstellen zurückführen, die bekannt waren, als solche gekennzeichnet und bewusst zurückgestellt wurden.

In Nachbetrachtungen nach Vorfällen beschreiben Ingenieure immer wieder denselben Ablauf. Sie wussten von dem Problem, erhielten jedoch keine Genehmigung, einen Teil des Quellcodes zu ändern, der seit Jahren stabil lief, und niemand wollte derjenige sein, der ihn kaputtmacht.

Das ist keine Nachlässigkeit. Es handelt sich um eine rationale Reaktion auf organisatorische Anreize. Das Ausliefern neuer Funktionen schafft sichtbaren Mehrwert. Die Überarbeitung eines Abhängigkeitsgraphen zur Behebung einer Sicherheitslücke, die noch keinen Vorfall verursacht hat, schafft unsichtbaren Mehrwert und birgt konkrete Risiken in Form von Regressionen, Verzögerungen und Schuldzuweisungen, falls in der Produktion etwas schiefgeht.

Das Ergebnis ist das, was Risikofachleute manchmal als „Standard-Risikotoleranz“ bezeichnen: keine bewusste Entscheidung, das Risiko zu akzeptieren, sondern eine Anhäufung von Aufschüben, bis das Risiko zur Normalität wird. Die Teams nehmen es nicht mehr klar wahr, weil es schon immer da war. Der Scanner meldet es, das Ticket wird aktualisiert, der Sprint endet, und lodash 4.17.21 bleibt bestehen.

Kleine Bibliothek, große Angriffsfläche

Lodash wirkt überschaubar. Es handelt sich um eine Utility-Bibliothek. Sie befasst sich nicht mit Authentifizierung, Autorisierung oder Netzwerkkommunikation – also den Komponenten, die die meisten Menschen mit sicherheitskritischem Code in Verbindung bringen. Diese Wahrnehmung trägt zum Problem der Aufschiebung bei.

Bei der Angriffsfläche geht es jedoch nicht um Funktionen, sondern um die Gefährdung. Lodash-Funktionen werden in der gesamten Anwendungslogik aufgerufen, oft mit Daten, die Vertrauensgrenzen überschritten haben. Die Schwachstellen durch „Prototype Pollution“ – bei denen ein Angreifer die Objektvererbungskette von JavaScript durch die Bereitstellung manipulierter Eingaben beeinflussen kann – können das Verhalten der Anwendung auf nicht offensichtliche und kontextabhängige Weise beeinflussen.

A _.merge() -Aufruf tief im Inneren eines Dienstprogramms zur Konfigurationsverarbeitung, das vom Benutzer bereitgestellte JSON-Daten verarbeitet, erscheint auf den ersten Blick nicht offensichtlich gefährlich. Doch genau diese Art von Aufrufstelle kann – abhängig von der umgebenden Anwendungslogik – dazu beitragen, dass Zugriffskontrollen umgangen, der Anwendungsstatus manipuliert oder sogar Wege zur Codeausführung geschaffen werden. Die scheinbare Harmlosigkeit der Funktion ist Teil dessen, was sie gefährlich macht.

Die Ausnutzbarkeit hängt stark vom Kontext ab. Eine Anwendung, die niemals vom Benutzer gesteuerte Daten an die betroffenen Methoden übergibt, ist praktisch nicht gefährdet. Doch wie viele Teams haben wirklich jede Aufrufstelle in einer umfangreichen Codebasis erfasst und können diese Aussage mit Sicherheit treffen? In den meisten Unternehmen lautet die ehrliche Antwort: nicht viele.

Praktische Einschränkungen, die dies erschweren

Die naheliegende Lösung – Lodash zu aktualisieren oder zu entfernen – ist theoretisch richtig, in der Praxis jedoch schwierig umzusetzen. Konkret stoßt man dabei auf drei strukturelle Probleme, die in Unternehmen jeder Größe immer wieder auftreten.

Release-Zyklen und Stabilitätsanforderungen

Viele Produktionsumgebungen arbeiten mit Änderungskontrollprozessen, die umfangreiche Tests, die Freigabe durch mehrere Beteiligte und eine Mindest-Einlaufzeit vor der Bereitstellung erfordern. Eine Änderung an einer Abhängigkeit, die in einer Reihe von Integrationstests unerwartetes Verhalten auslöst, kann den Zeitplan für eine Veröffentlichung um Wochen aus der Bahn werfen. In regulierten Umgebungen – Finanzdienstleistungen, Gesundheitswesen, kritische Infrastruktur – sind die Hürden sogar noch höher. Sicherheitsverbesserungen durchlaufen denselben Prozess wie jede andere Änderung und konkurrieren um Aufmerksamkeit und Genehmigung mit Funktionen, die einen messbaren geschäftlichen Nutzen generieren.

Regressionsrisiko in bestehenden Codebasen

Obwohl die API von Lodash 4.x jahrelang stabil geblieben ist, erfordert das Entfernen von Lodash oder dessen Ersatz durch native Methoden eine Überprüfung aller Aufrufstellen, und selbst der Umstieg auf die neu veröffentlichte 4.18.x-Reihe kann zu subtilen Verhaltensänderungen führen. 

Bei einem Code, in dem sich über fünf oder mehr Jahre hinweg Lodash-Aufrufe angesammelt haben, ist dies keine Aufgabe, die man an einem Wochenende erledigen kann. Die Testabdeckung ist oft uneinheitlich – die ältesten und Lodash-intensivsten Teile des Codes sind häufig am wenigsten gut getestet, gerade weil sie aus einer Zeit stammen, als es die modernen Testverfahren des Unternehmens noch nicht gab.

Verantwortungs- und Organisationslücken

In Microservice-Architekturen und großen Entwicklungsorganisationen haben Codebasen Verantwortliche – doch bei Legacy-Diensten, die bereits vor den aktuellen Teamstrukturen entstanden sind, ist die Zuständigkeit manchmal unklar. Ein Dienst, der von einem Team entwickelt wurde, das inzwischen umstrukturiert wurde, hat möglicherweise keinen eindeutigen Verantwortlichen. Die Sicherheitsabteilung wird die Schwachstelle melden. Der Betrieb wird den Dienst im Bericht vermerken. Niemand wird jedoch über die Befugnis und den nötigen Kontext verfügen, um die Änderung vorzunehmen. Dies kommt häufiger vor, als die meisten Organisationen zugeben möchten.

STRUKTURELLE EINBLICKE

Die Sicherheitslücke selbst ist nicht das eigentliche Problem. Das eigentliche Problem ist organisatorischer Natur: Es gilt, die Verantwortlichen zu ermitteln, Argumente für die Priorisierung zu finden, Zeit im Sprint einzuplanen und das Regressionsrisiko abzufedern. Die technische Komplexität macht oft nur den geringsten Teil der Herausforderung aus.

Was Teams tatsächlich tun und was funktioniert

Angesichts dieser Einschränkungen ignorieren professionelle IT-Organisationen Lodash 4.17.21 nicht einfach und hoffen auf das Beste. Sie wenden eine Reihe von Strategien zur Risikominderung an, die der Tatsache Rechnung tragen, dass das Upgrade nicht sofort erfolgen kann, und gleichzeitig das Risiko in der Zwischenzeit verringern. Keine dieser Strategien ist perfekt. Aber alle sind besser als gar nichts.

Exposition isolieren und abbilden

Der erste Schritt ist eine ehrliche Bestandsaufnahme. Nicht jede Anwendung, die Lodash in ihrem Abhängigkeitsbaum enthält, ist gleichermaßen gefährdet. Teams, die Zeit in die Erfassung der tatsächlichen Aufrufstellen investieren – insbesondere der Methoden, die mit dem bekannten Risiko der Version 4.17.21 verbunden sind, wie beispielsweise _.template, _.unsetund _.omit — können eine realistische Risikoeinstufung liefern. Ein Dienst, der lodash ausschließlich für _.isEqual und _.cloneDeep bei internen Datenstrukturen verwendet, unterscheidet sich grundlegend von einem, der _.template aus benutzergesteuerten Eingaben kompiliert.

Diese Bestandsaufnahme ist auch dann wertvoll, wenn sie nicht unmittelbar zu einer Lösung führt. Sie wandelt die allgemeine, diffuse Unsicherheit bezüglich Lodash in eine nach Prioritäten geordnete Liste tatsächlicher Risiken um, wodurch die Planung von Abhilfemaßnahmen überschaubarer wird.

Eingabevalidierung und Absicherung an der Schnittstelle

Sicherheitslücken vom Typ „Prototype Pollution“ und „Command Injection“ erfordern in der Regel vom Angreifer kontrollierte Eingaben, um die anfällige Funktion zu erreichen. Eine strengere Eingabevalidierung an den Anwendungsgrenzen – durch die Durchsetzung einer Schemavalidierung für eingehende JSON-Daten und die Zurückweisung von Eingaben mit verdächtigen Schlüsselmustern wie __proto__ oder Konstruktor– sowie die Bereinigung von Zeichenketten vor deren Übergabe an Vorlagenfunktionen – verringert die Ausnutzbarkeit, ohne die zugrunde liegende Abhängigkeit zu verändern.

Dies ist eine Ausgleichsmaßnahme, keine endgültige Lösung. Die Sicherheitslücke bleibt bestehen. Die Einschränkung der Wege, über die Eingaben von Angreifern den anfälligen Code erreichen können, ist jedoch eine vertretbare Übergangslösung, und es handelt sich um eine Änderung, die oft vorgenommen werden kann, ohne einen vollständigen Release-Zyklus auszulösen.

Überwachung und Erkennung

RASP-Tools (Runtime Application Self-Protection) und Web-Anwendungs-Firewalls können so konfiguriert werden, dass sie Muster von Prototype-Pollution-Versuchen erkennen und blockieren. Durch die Protokollierung und Benachrichtigung bei verdächtigen Objekt-Schlüsselmustern in eingehenden Anfragen lässt sich feststellen, ob die Schwachstelle aktiv auslotet wird – selbst wenn sie noch nicht behoben werden kann.

Die Erkennung beseitigt das Risiko zwar nicht, verändert jedoch das Risikoprofil. Eine bekannte Schwachstelle, die aktiv überwacht wird, ist wesentlich weniger gefährlich als dieselbe Schwachstelle in einem System, das keine Warnmeldungen ausgibt. Zumindest ermöglicht die Erkennung eine schnellere Reaktion auf Vorfälle, falls die Schwachstelle ausgenutzt wird.

Gezielte Ausweitung der Unterstützung

Für Organisationen, die mehrere Anwendungen mit Abhängigkeiten zu Altsystemen verwalten, besteht ein zunehmend praktischer Ansatz darin, die Verlängerung des Supports als explizites Risikomanagement-Instrument zu betrachten. Anstatt ein risikobehaftetes Upgrade innerhalb eines Zeitplans zu erzwingen, der eigene Risiken mit sich bringt, können Teams Dienste wie TuxCares ELS for Libraries nutzen, um rückportierte Sicherheitskorrekturen für bestimmte Bibliotheksversionen zu erhalten. So bleibt die Stabilität der bewährten Konfiguration gewahrt, während gleichzeitig Patches für die wichtigsten Sicherheitslücken angewendet werden.

Dies ist keine dauerhafte Lösung und sollte auch nicht als solche dargestellt werden. Das Ziel besteht darin, Spielraum zu schaffen: Zeit, um eine ordnungsgemäße Migration zu planen und durchzuführen, ohne in der Zwischenzeit ungeschützt zu sein. Für Teams, die unter strenger Änderungskontrolle arbeiten oder Dienste mit schwer nachvollziehbaren Abhängigkeiten verwalten, bringt dieser Ansatz Sicherheitsverbesserungen mit der betrieblichen Realität in Einklang, anstatt ein Upgrade zu verlangen, für das die Organisation noch nicht bereit ist.

Schrittweise Migration statt kompletter Neuprogrammierung

Wenn das endgültige Ziel darin besteht, Lodash vollständig zu entfernen, verringern schrittweise Ansätze das Risiko der Migration selbst. Durch das Ersetzen der Lodash-Funktionen Methode für Methode – beginnend mit den Aufrufstellen mit dem höchsten Risiko und dann schrittweise weiter – lässt sich eine „Big-Bang“-Neuprogrammierung vermeiden, die häufig scheitert. Die Teams verfolgen den Fortschritt mithilfe von Abhängigkeitsprüfungen, stellen die Nutzung von Lodash Dienst für Dienst ein und betrachten jede entfernte Nutzung als messbare Risikominderung und nicht als Aufgabe in einem undifferenzierten Backlog.

Die ehrliche Buchführung

Die unangenehme Wahrheit über Lodash 4.17.21 ist nicht, dass es im Produktivbetrieb eingesetzt wird. Es ist vielmehr, dass es in den meisten Unternehmen noch lange Zeit im Produktivbetrieb verbleiben wird – unabhängig davon, was Sicherheitsscanner melden oder was in Sicherheitshinweisen steht. Die technischen Kapazitäten sind begrenzt. Risikotoleranz ist ein reales organisatorisches Phänomen. Bei der Abwägung zwischen „jetzt aktualisieren“ und „sorgfältig verwalten, während wir eine echte Migration planen“ wird in vielen Fällen weiterhin Letzteres den Vorzug erhalten.

Die Antwort auf diese Realität ist nicht Resignation. Es ist ein ehrliches Risikomanagement: zu wissen, welche Aufrufstellen gefährdet sind, die Grenzen zu sichern, auf Ausnutzung zu achten und – wenn der Zeitrahmen für das Upgrade tatsächlich lang ist – die verfügbaren Tools zu nutzen, um das Zeitfenster der Sicherheitslücke zu verkürzen, ohne so zu tun, als sei das zugrunde liegende Problem gelöst.

Bei der Sicherheitsreife geht es nicht darum, keine bekannten Schwachstellen zu haben. Es geht darum, einen Überblick über die Risiken zu haben, Aufschübe als bewusste Entscheidungen und nicht als unsichtbare Anhäufung zu betrachten und Lücken systematisch zu schließen. Lodash 4.17.21 ist ein geeigneter Testfall, um zu prüfen, ob eine Organisation dazu in der Lage ist.

Das Ticket ist seit neun Monaten offen. Es ist an der Zeit, zu entscheiden, was Sie nun tatsächlich damit machen wollen.

Zusammenfassung

Artikel Name

Sicherheitslücken in Lodash 4.17.21: Risikomanagement

Beschreibung

Die Teams sind sich der Risiken in Lodash 4.17.21 bewusst – doch Upgrades sind nicht immer einfach. Erfahren Sie, wie Sie das Risiko durch veraltete Abhängigkeiten bewältigen können.

Autor

Tim Walker

Name des Herausgebers

TuxCare

Logo des Herausgebers