npm Dependency Confusion: 14 Pakete spähen interne Build-Umgebungen aus

Ein einzelnes npm-Konto hat innerhalb von rund 41 Stunden 14 präparierte Pakete veröffentlicht, die gezielt auf npm Dependency Confusion setzen. Die Pakete tragen Namen, die wie interne Bibliotheken echter Unternehmen klingen, etwa @greenlake/auth oder @sxm-web/client-sdk-core. Wer sie versehentlich installiert, schickt Informationen über den eigenen Rechner oder Build-Server an eine fremde IP-Adresse. GitHub hat alle Pakete am 26. Oktober 2026 als Malware eingestuft.

Wir erklären, wie der Angriff funktioniert, woran du betroffene Pakete erkennst und welche Einstellungen in npm-Projekten und CI-Pipelines davor schützen.

Key Takeaways

• Das npm-Konto „wiseke“ veröffentlichte zwischen dem 23. Oktober (21:23 UTC) und dem 25. Oktober 2026 (14:28 UTC) 14 Pakete unter den Scopes @greenlake, @sxm-web, @drone-js-ext und @ppa-web-components.
• Jedes Paket führt beim Installieren per postinstall ein Skript aus und sendet Hostname, Installationspfad und Arbeitsverzeichnis unverschlüsselt per HTTP an einen Server.
• Ein unsichtbarer Proxy sorgt dafür, dass Builds trotzdem weiterlaufen. Der Angriff fällt also nicht durch Fehler auf.
• Die Pakete nutzen künstlich hohe Versionsnummern wie 13.3.7 oder 99.0.1, damit npm sie internen Paketen vorzieht.
• GitHub rät, betroffene Rechner als kompromittiert zu behandeln und alle Geheimnisse von einem anderen Gerät aus zu rotieren.

Was npm Dependency Confusion bedeutet

Viele Unternehmen veröffentlichen eigene JavaScript-Bibliotheken nicht im öffentlichen npm-Registry, sondern in einem privaten Registry, etwa Artifactory, Verdaccio oder GitHub Packages. Ist ein Build nicht sauber konfiguriert, fragt npm für einen Paketnamen aber auch das öffentliche Registry an. Liegt dort ein gleichnamiges Paket mit höherer Versionsnummer, kann es passieren, dass npm dieses installiert statt der internen Variante.

Genau diese Verwechslung heißt Dependency Confusion. Der Angreifer muss dafür nur den Namen eines internen Pakets kennen oder erraten und ihn öffentlich besetzen. Interne Namen tauchen erstaunlich oft in öffentlichen Quellen auf, etwa in versehentlich veröffentlichten package.json-Dateien, Source Maps oder Fehlermeldungen.

Was die 14 Pakete konkret tun

Das GitHub-Advisory GHSA-pmfr-35rg-27xm zu @greenlake/context-pane beschreibt das Verhalten, das für alle 14 Pakete gleich ist:

• Tarnung: Das Paket nennt sich „Compatibility shim“. Im README steht, es handle sich um einen „authorized dependency-confusion test“. Ob das stimmt, ist nicht belegt. Es ist eine Selbstauskunft des Kontos.
• Ausführung beim Installieren: Jede betroffene Version enthält ein postinstall-Skript, das node beacon.cjs startet. Zusätzlich ruft index.js denselben Code auf, sobald das Paket importiert wird.
• Datenabfluss: Das Skript sendet per POST Hostname, Installationspfad und aktuelles Arbeitsverzeichnis über unverschlüsseltes HTTP an 185.158.107.175 auf Port 8787. Laut einer Analyse von Amazon Inspector, die in der OSV-Datenbank (MAL-2026-18319) dokumentiert ist, kommen die Node.js-Version und der Paketname hinzu.
• Kein Absturz: index.js exportiert einen JavaScript-Proxy, der für jeden Zugriff eine leere Funktion zurückgibt. Code, der eigentlich das echte interne Paket erwartet, kompiliert weiter.
• Wiederverwendetes Werkzeug: Laut GitHub ist index.js byte-identisch mit dem Paket ph-common (MAL-2026-1809), das an denselben Endpunkt sendet.

Die Versionsnummern sind auffällig. @sxm-web/client-sdk-core erschien unter anderem als 13.3.7, @greenlake/session und @ppa-web-components/ppa-navigation als 99.0.1. Solche Sprünge sollen sicherstellen, dass das öffentliche Paket jede interne Version „überbietet“.

Wie gefährlich ist der Fund?

Auf den ersten Blick wirkt die Nutzlast harmlos. Es werden keine Passwörter oder Tokens gestohlen, sondern „nur“ Systeminformationen gesendet. Das ist aber zu kurz gedacht:

• Aufklärung: Ein Treffer verrät dem Angreifer, dass eine bestimmte Organisation anfällig für Dependency Confusion ist, auf welchem Host das passiert und wie die Verzeichnisstruktur aussieht. Das ist eine ideale Vorbereitung für einen zweiten, gefährlicheren Schritt.
• Austauschbare Nutzlast: Wer einmal Code per postinstall in eine Pipeline bringt, kann mit der nächsten Version beliebigen Code ausführen.
• Offizielle Einstufung: GitHub stuft die Pakete als Malware ein (CWE-506, eingebetteter Schadcode) und empfiehlt, betroffene Systeme als vollständig kompromittiert zu betrachten.

Unklar bleibt, ob die Pakete tatsächlich bei echten Unternehmen installiert wurden. Weder die Advisories noch das npm-Registry geben darüber Auskunft. Ebenso ist offen, wer hinter dem Konto und der IP-Adresse steht. Der Hinweis auf einen „autorisierten Test“ ist mit Vorsicht zu lesen. Ein echter Auftrag im Rahmen eines Penetrationstests würde seine Netzwerkaufrufe in der Regel nicht so verstecken.

So schützt du dich vor npm Dependency Confusion

Die gute Nachricht: Gegen diese Angriffsklasse helfen ein paar klare Konfigurationsregeln.

• Scope an das private Registry binden: Lege in der .npmrc fest, dass dein interner Scope nur aus deinem eigenen Registry kommt, zum Beispiel @firma:registry=https://npm.firma.intern/. Wie das funktioniert, beschreibt die npm-Dokumentation zu Scopes.
• Scope öffentlich reservieren: Lege auf npmjs.com eine Organisation mit dem Namen deines internen Scopes an. Dann kann niemand anderes dort Pakete veröffentlichen.
• Lockfile verwenden: Nutze in CI npm ci statt npm install. So werden nur die im Lockfile festgehaltenen Versionen und Quellen installiert.
• Install-Skripte einschränken: Die Option ignore-scripts verhindert, dass postinstall-Skripte automatisch laufen. Das erfordert Tests, weil manche legitime Pakete Skripte brauchen.
• Ausgehenden Verkehr begrenzen: Build-Server brauchen selten freien Internetzugang. Eine Egress-Regel, die nur das eigene Registry erlaubt, stoppt solche Beacons.
• Logs prüfen: Suche in Proxy- und Firewall-Logs nach Verbindungen zu 185.158.107.175:8787 und in Lockfiles nach den vier genannten Scopes.

Wer einen Treffer findet, sollte der Empfehlung von GitHub folgen: Paket entfernen, den Rechner als kompromittiert behandeln und Schlüssel, Tokens und Passwörter von einem sauberen Gerät aus erneuern.

Einordnung

Angriffe auf die Software-Lieferkette sind in diesem Herbst ein Dauerthema. Erst vor wenigen Tagen haben wir über den Supply-Chain-Angriff auf LiteLLM mit Backdoors in PyPI- und Docker-Paketen berichtet. Auch der Sicherheitsvorfall bei Railway zeigte, wie wichtig schnelle Rotation von Geheimnissen in Entwicklerumgebungen ist. Und mit der Brotli-Lücke in Node.js war gerade erst die Laufzeitumgebung selbst betroffen.

Der aktuelle Fall ist technisch simpel, aber lehrreich. Er zeigt, dass Angreifer gezielt nach Namen suchen, die nach internen Monorepos und Micro-Frontends klingen. Die Verteidigung liegt weniger in Virenscannern als in sauberer Registry-Konfiguration.

Fazit

Die 14 Pakete des Kontos „wiseke“ sind ein Lehrbuchbeispiel für npm Dependency Confusion: plausible Namen, aufgeblähte Versionsnummern und eine Nutzlast, die still Informationen sammelt, ohne den Build zu stören. Ob echte Opfer betroffen sind, ist offen. Wer interne npm-Pakete nutzt, sollte trotzdem heute prüfen, ob der eigene Scope fest an das private Registry gebunden ist und ob CI-Server frei ins Internet funken dürfen. Das kostet wenig Zeit und schließt eine ganze Klasse von Angriffen.