Typosquatting: Die stille Bedrohung bei „npm install“

Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags

Du hast Folgendes eingegeben npm install eingetippt. Wahrscheinlich hast du auch schon mindestens einmal einen Paketnamen falsch geschrieben und dabei Glück gehabt. Das geht aber nicht jedem so. Angreifer setzen auf diesen einen Ausrutscher – das Vertrauen in das motorische Gedächtnis, das schnelle Drücken der Eingabetaste – und genau dasselbe Paket-Ökosystem, das die JavaScript-Entwicklung so schnell macht, ist es auch, das Typosquatting so effektiv macht.

In diesem Beitrag wird erläutert, was Typosquatting ist, wie man es erkennt und was Sie konkret tun können, um Ihre Projekte zu schützen.

Was ist Typosquatting?

Als „Typosquatting“ bezeichnet man die Praxis, ein bösartiges Paket unter einem Namen zu veröffentlichen, der stark einem beliebten, legitimen Paket sehr ähnlich ist, in der Hoffnung, dass Entwickler den Namen falsch eingeben, falsch lesen, aus einer nicht vertrauenswürdigen Quelle kopieren oder vor der Installation nicht noch einmal überprüfen.

Zu den gängigen Mustern gehören unter anderem:

Zeichenvertauschungen oder Auslassungen/Rechtschreibfehler: lodash wird zu lodahs oder loadsh
Tricks mit Bindestrichen: babel-core vs babelcore
Pluralbildung: Farben vs Farbe
Tricks zu Gültigkeitsbereich und Namensraum: @types/react (ein echtes, in einem Geltungsbereich definiertes Paket) im Vergleich zu einem unechten, nicht in einem Geltungsbereich definierten types-react
Homoglyphen: Ersetzen eines Kleinbuchstabens l durch ein großes Ioder die Verwendung anderer, ähnlich aussehender Zeichen

Nach der Installation können diese Pakete alles, was ein echtes npm-Paket auch kann: Umgebungsvariablen auslesen, Daten exfiltrieren .env -Dateien oder SSH-Schlüssel exfiltrieren, Hintertüren installieren oder unbemerkt bösartigen Code in Ihre Build-Ergebnisse einschleusen. Da npm-Lifecycle-Skripte während der Installation ausgeführt werden können, kann der Schaden bereits entstehen, bevor Sie den Code überhaupt angesehen haben.

Typosquatting beschränkt sich nicht nur auf Pakete. Es taucht auch in URLs auf. Nehmen wir zum Beispiel guthub.com. Wenn Sie schon einmal „github.com“ eingeben wollten und stattdessen bei „guthub.com“ gelandet sind, hatten Sie Glück: Diese Domain leitet auf die echte Website weiter. Diese Weiterleitung ist jedoch eine Höflichkeit, die jemand eingerichtet hat – keine Garantie. Wer auch immer eine häufige Falschschreibung registriert, bestimmt, wohin sie führt – und wenn sie einem böswilligen Akteur gehört, kann ein einziger Tippfehler Sie auf eine Klon-Seite leiten, die darauf abzielt, Ihre Zugangsdaten abzugreifen. Im Paket-Ökosystem ist die Gefahr sogar noch unmittelbarer, da ein solcher Fehler ausführbaren Code direkt in Ihr Projekt schleusen kann.

Warum gerade JavaScript?

Das ist zwar kein Phänomen, das ausschließlich bei JavaScript auftritt, doch das npm-Ökosystem ist ein besonders attraktives Ziel. Die Registry ist riesig, viele Pakete werden von kleinen Teams oder Einzelpersonen gepflegt, und moderne Abhängigkeitsbäume können aufgrund verschachtelter transitiver Abhängigkeiten Hunderte oder Tausende von Paketen umfassen. In Verbindung mit den niedrigen Hürden für die Veröffentlichung und der beiläufigen Art der Abhängigkeitsinstallation – man wirft nur einen kurzen Blick darauf und macht weiter – bietet dies dem Typosquatting reichlich Raum für Erfolg.

Dieses Risiko besteht bei allen Paketmanagern. Nur der Befehl ändert sich:

yarn add package_name
pnpm add Paketname
bun add Paketname

Egal, ob Sie Garn, pnpmoder bun– die Syntax unterscheidet sich von der von npm: Alle drei verwenden add anstelle von install. Da sie jedoch aus derselben Quelle – der npm-Registry – beziehen, ändert sich zwar der Befehl, das Vertrauensproblem bleibt jedoch bestehen. Ein falsch eingegebenes oder böswillig eingeschleustes Paket kann in Ihr Projekt gelangen, ganz gleich, welchen Manager Sie verwenden – selbst wenn Sie selbst nie „npm install“ eingeben.

npm entzieht einem Betreuer auch nicht einfach so die Veröffentlichungsrechte, nur weil ein Konto inaktiv wird – und der Mastra-Angriff im Juni 2026 hat gezeigt, welche Möglichkeiten sich daraus ergeben. Angreifer übernahmen das Konto eines ehemaligen Mastra-Mitwirkenden, dessen Zugriff auf den @mastra-Bereich nie entzogen worden war, und schleusten anschließend „easy-day-js“ – selbst ein Typosquat der beliebten „dayjs“-Bibliothek – in mehr als 140 Mastra-Pakete ein. Ein vertrauenswürdiger Bereich wurde so zum Übertragungsweg für eine bösartige, ähnlich aussehende Abhängigkeit.

So erkennen Sie ein durch Typosquatting missbrauchtes Paket

Warnsignale sind nicht immer offensichtlich, aber mit ein paar Überprüfungen können Sie ein verdächtiges Paket erkennen, bevor es in Ihr Projekt gelangt:

Schauen Sie sich die Downloadzahlen und den Veröffentlichungsverlauf an. Ein Paket, das behauptet, eine „beliebte“ Bibliothek zu sein, aber nur wenige hundert Downloads und ein Veröffentlichungsdatum von letzter Woche aufweist, ist ein Warnsignal. Vergleichen Sie es mit den Statistiken des echten Pakets auf npmjs.com.

Überprüfen Sie den Betreuer. Stimmt das Veröffentlichungskonto mit den bekannten Betreuern des eigentlichen Projekts überein? Ein brandneues Konto, ein unbekannter Betreuer oder ein Paket ohne aussagekräftige Veröffentlichungshistorie sollte genauer unter die Lupe genommen werden.

Lesen Sie die Datei „package.json“ sorgfältig durch. Achten Sie auf die Repository-URL, die Lizenz und die Beschreibung. Typosquats kopieren diese Felder oft direkt aus dem legitimen Paket, aber manchmal führt der Repo-Link an einen unerwarteten Ort oder fehlt ganz.

Überprüfen Sie Installationsskripte, bevor sie ausgeführt werden. Überprüfen Sie Installationsskripte, bevor sie ausgeführt werden. vor der Installation, installund postinstall Hooks in package.json verdienen besondere Aufmerksamkeit, da sie während der Installation Code ausführen können. Wenn eine einfache Utility-Bibliothek ein verschleiertes Postinstall-Skript enthält, das eine Verbindung zu einer Remote-URL herstellt, sollten Sie dies als ernstzunehmendes Warnzeichen betrachten – genau so funktionierte die „easy-day-js“-Abhängigkeit beim Mastra-Angriff, bei dem eine Payload der zweiten Stufe abgerufen und ausgeführt wurde.

Nutzen Sie die offizielle Registrierungssuche und verlassen Sie sich nicht auf Vermutungen. Suche npmjs.com, kopieren Sie den Installationsbefehl aus der offiziellen Dokumentation des Projekts oder verlassen Sie sich auf die Autovervollständigung Ihrer IDE, anstatt unbekannte Paketnamen aus dem Gedächtnis einzugeben. Muskelgedächtnis ist nützlich – bis es dazu führt, dass das falsche Paket installiert wird.

Achten Sie auf kurzfristige Änderungen bei den Abhängigkeiten. Wenn eine „package-lock.json“ oder yarn.lock , oder pnpm-lock.yaml Wenn der Diff eine unerwartete Änderung des Abhängigkeitsnamens anzeigt, sollten Sie vor dem Zusammenführen innehalten und der Sache nachgehen. Das Gleiche gilt für jedes neu hinzugefügte Paket, das niemand im Team absichtlich eingeführt hat.

Praktische Schutzmaßnahmen für Ihr Projekt

Manuelle Überprüfungen sind zwar hilfreich, lassen sich aber allein nicht in großem Maßstab umsetzen. Ein wirksamerer Ansatz besteht darin, strukturelle Sicherheitsvorkehrungen in die Abläufe Ihres Teams bei der Installation, Überprüfung und Freigabe von Abhängigkeiten zu integrieren:

Fixieren Sie Ihre Abhängigkeiten. Fügen Sie Ihre package-lock.json bzw. yarn.lock Datei und verwende npm ci in CI/CD-Pipelines anstelle von npm installverwenden. Dadurch wird sichergestellt, dass Builds genau die von Ihnen geprüften Versionen verwenden und nicht einfach das, was zum Zeitpunkt der Installation verfügbar ist.

Verwenden Sie automatisierte Scan-Tools. npm audit, Snyk, Socket und GitHub Dependabot – zusammenfassend als Software-Composition-Analysis-Tools (SCA) bezeichnet – können bekannte Schwachstellen, bösartige Pakete und unerwartete Installationsskripte aufdecken. Insbesondere Socket wurde speziell entwickelt, um Risiken in der Lieferkette wie Typosquatting und bösartige Post-Install-Hooks zu erkennen. Keines dieser Tools erfasst alles, aber zusammen bieten sie Ihrem Team eine deutlich bessere Chance, Risiken zu erkennen, bevor sie die Produktion erreichen.

Legen Sie für kritische Abhängigkeiten genaue Versionen fest. Vermeiden Sie zu weit gefasste Semver-Bereiche (^ oder ~) für Pakete, die sensible Vorgänge betreffen, damit bei einer automatischen Aktualisierung nicht unbemerkt eine kompromittierte Version eingeführt wird. Durch das Festlegen der Versionen bleibt das Verhalten der Pakete über Teams, Umgebungen und CI/CD-Pipelines hinweg konsistent.

Deaktivieren Sie Skripte standardmäßig, wenn dies sinnvoll ist.

Deaktivieren Sie Skripte standardmäßig, wo dies sinnvoll ist. Führen Sie Installationen mit –ignore-scripts in der CI auszuführen und anschließend die Pakete, die tatsächlich Build-Schritte benötigen, explizit auf eine Whitelist zu setzen, verringert den Schadenumfang eines bösartigen Postinstall-Hooks. Auch pnpm ist hier eine Überlegung wert: Seit Version 10 blockiert es standardmäßig Skripte im Lebenszyklus von Abhängigkeiten und erfordert, dass man diese über eine Whitelist genehmigt.

Ausführen npm install –ignore-scripts in der CI auszuführen und anschließend Pakete, die Installationsskripte tatsächlich benötigen, explizit auf die Whitelist zu setzen, verringert den Schadensumfang eines bösartigen Postinstall-Hooks. Dies ist ein hervorragender Anwendungsfall für pnpm. Seit Version 10 ignoriert pnpm Installationsskripte standardmäßig. Sie können die Option –ignore-scripts Flag auf der Befehlszeilenebene oder die Datei .npmrc -Ebene sowie auf globaler Ebene verwenden.

Nutzen Sie eine private Registry oder einen Proxy. Tools wie Verdaccio, Sonatype Nexus, JFrog Artifactory oder die eigenen privaten Registry-Funktionen von npm ermöglichen es Teams, Pakete zu spiegeln, zu genehmigen und zu kontrollieren, bevor sie den Entwicklern zur Verfügung stehen. Dadurch erhalten Sie eine Kontrollinstanz, an der verdächtige Nachahmer blockiert werden können, bevor sie überhaupt den Rechner eines Entwicklers erreichen.

Überprüfen Sie neue Abhängigkeiten im Rahmen der Code-Review. Behandeln Sie das Hinzufügen eines neuen Pakets so, als würden Sie einen neuen Mitwirkenden mit Zugriff auf Ihre Codebasis hinzufügen, denn funktional gesehen kommt dies dem, was Sie tun, sehr nahe. Erstellen Sie eine Sicherheitsrichtlinie, die festlegt, wie neue Pakete genehmigt werden, was Prüfer überprüfen sollten und aus welchen Quellen Ihr Team installieren darf. Tools wie SecureChain können dies unterstützen, indem sie Teams eine kuratierte Quelle mit geprüften Open-Source-Paketen zur Verfügung stellen.

Schulen Sie Ihr Team. Ein fünfminütiges Gespräch über Typosquatting-Muster kann einen kostspieligen Vorfall verhindern. Machen Sie dies zu einem festen Bestandteil der Einarbeitung für jede Position, die mit „package.json“. Erstellen Sie eine Teamrichtlinie, stellen Sie sicher, dass Sicherheitsüberprüfungen oberste Priorität haben, und setzen Sie diese konsequent durch.

Eine kurze mentale Checkliste

Bevor Sie etwas hinzufügen IRGENDEINE neue Abhängigkeit hinzuzufügen, fragen Sie sich:

Ist das der Name, den ich eigentlich eingeben wollte?
Sehen die Download-Zahlen und der Veröffentlichungsverlauf plausibel aus?
Stimmt das Quell-Repository mit einem Projekt überein, das ich kenne oder überprüfen kann?
Gibt es Installationsskripte, und verstehe ich, was sie bewirken, warum es sie gibt und ob sie notwendig sind?
Hat mein Scan-Tool irgendetwas angezeigt?

Abschließende Überlegungen

Typosquatting ist so effektiv, weil es Vertrauen und Gewohnheiten ausnutzt – zwei Dinge, auf die sich Entwickler ständig verlassen. Die gute Nachricht ist, dass Sie zur Risikominderung nicht Ihren gesamten Arbeitsablauf umkrempeln müssen.

Der Übergang von Muskelgedächtnis zu verifizierten Paketnamen, festgelegten Abhängigkeitsbäumen, automatisierten Scans, zugelassenen Registern und einem Moment gesunder Skepsis vor jeder neuen Installation wird den Großteil dieser Angriffsfläche schließen.

Zusammenfassung