Bösartige node-ipc-Versionen nach mutmaßlicher Kompromittierung eines Maintainer-Kontos auf npm veröffentlicht

Am 14. Mai 2026 wurden mehrere bösartige Versionen des beliebten npm-Pakets node-ipc in der npm-Registry veröffentlicht. Aktuelle öffentliche Berichte nennen node-ipc@9.1.6, node-ipc@9.2.3 und node-ipc@12.0.1 als kompromittierte Versionen, die eine verschleierte Payload zum Diebstahl von Zugangsdaten enthalten. Der Schadcode wurde dem CommonJS-Bundle node-ipc.cjs hinzugefügt und wird ausgeführt, wenn das Paket über require("node-ipc") geladen wird. Erste Analysen deuten darauf hin, dass der Angriff möglicherweise durch den Missbrauch eines legitimen npm-Maintainer-Kontos und nicht durch eine Kompromittierung der Projekt-CI/CD-Pipeline erfolgte. Unternehmen, die die betroffenen Versionen installiert oder daraus Builds erstellt haben, sollten davon ausgehen, dass Entwickler-, CI/CD-, Cloud-, SSH-, GitHub-, Kubernetes- und weitere Geheimnisse, die in diesen Umgebungen zugänglich waren, potenziell kompromittiert wurden. Snyk hat einen Sicherheitshinweis zu diesem Vorfall unter SNYK-JS-NODEIPC-16697063 veröffentlicht. Teams sollten ihn nutzen, um anfällige Abhängigkeitspfade zu identifizieren und die Behebung zu priorisieren.

Betroffene Komponente

node-ipc ist ein Node.js-Paket für die Interprozesskommunikation. Es wurde im npm-Ökosystem historisch häufig direkt und indirekt verwendet.

Dies ist nicht das erste Mal, dass node-ipc mit einem Supply-Chain-Vorfall in Verbindung gebracht wird. 2022 analysierte Snyk den Vorfall um node-ipc und peacenotwar, bei dem Protestware-ähnliches Verhalten nachgelagerte Nutzer betraf. Die Aktivitäten im Mai 2026 scheinen davon unabhängig zu sein. Die aktuelle Analyse deutet nicht auf Protestware hin, sondern auf bösartige Versionen mit einer verschleierten Payload zum Diebstahl von Zugangsdaten.

Der Vorfall von 2026 scheint unabhängig von jenem aus dem Jahr 2022 zu sein. Die aktuell gemeldete Payload von 2026 zielt auf den Diebstahl von Zugangsdaten und deren heimliche Exfiltration ab, nicht auf das 2022 beobachtete Protestware-Verhalten. Öffentlichen Analysen zufolge wurde die Payload in den CommonJS-Einstiegspunkt eingeschleust und war nicht auf npm-Lifecycle-Skripte wie postinstall angewiesen.

Bekanntermaßen betroffene Versionen

Aktuelle öffentliche Berichte nennen diese drei bösartigen Versionen und geben an, dass sie alle am 14. Mai 2026 veröffentlicht wurden. Berichten zufolge war die kompromittierte Datei node-ipc.cjs in allen betroffenen Releases identisch.

Zeitleiste

Wie es vermutlich zur Kompromittierung kam

Die plausibelste öffentlich bekannte Hypothese ist, dass die bösartigen Versionen über ein npm-Maintainer-Konto mit legitimen Veröffentlichungsrechten bereitgestellt wurden. StepSecurity berichtete, dass die Releases vom Konto atiertant veröffentlicht wurden. Dieses Konto war in der Liste der Maintainer aufgeführt, hatte node-ipc zuvor jedoch nie veröffentlicht.

Upwind und andere öffentliche Berichte beschrieben einen möglichen Weg über die Übernahme einer abgelaufenen Domain: Der Angreifer könnte eine mit der E-Mail-Adresse des Maintainer-Kontos verknüpfte Domain neu registriert, den E-Mail-Empfang eingerichtet und dann die npm-Kontowiederherstellung genutzt haben, um die Kontrolle über das npm-Konto zu erlangen.

Die aktuellen Hinweise sprechen für den Missbrauch einer Maintainer-Identität mit npm-Veröffentlichungsrechten. Öffentliche Analysen legen nahe, dass eine abgelaufene E-Mail-Domain des Maintainers die Kontowiederherstellung ermöglicht haben könnte. Die Untersuchung dauert jedoch noch an. Diese Unterscheidung ist wichtig, denn sie deutet darauf hin, dass die npm-Registry selbst nicht kompromittiert werden musste und das Quellcode-Repository oder die CI/CD-Pipeline des Projekts möglicherweise nicht der ursprüngliche Angriffsweg war.

Angriffsvektor und bösartiges Verhalten

Die Payload wurde offenbar in node-ipc.cjs eingeschleust, das CommonJS-Bundle, das von Nutzern geladen wird, die das Paket mit require("node-ipc") einbinden. Öffentlichen Analysen zufolge wurde der ESM-Einstiegspunkt nicht auf dieselbe Weise verändert.

Anders als bei vielen npm-Malware-Vorfällen beruhte diese Kompromittierung Berichten zufolge nicht auf Installationsskripten wie preinstall, install oder postinstall. Stattdessen wurde die bösartige Logik als sofort aufgerufener Funktionsausdruck angehängt. Der Code konnte also beim Import des Pakets zur Laufzeit ausgeführt werden und nicht nur während der Installation der Abhängigkeit.

• Fingerprinting der Umgebung und des Hosts

• Suche nach lokalen Zugangsdaten und vertraulichen Entwicklerdateien

• Abgreifen von Cloud-Zugangsdaten, SSH-Schlüsseln, Kubernetes-Tokens, GitHub-CLI-Konfigurationen, Terraform-Statusdateien, Datenbank-Zugangsdaten, Shell-Verläufen sowie Konfigurationen von KI- und Entwickler-Tools

• Komprimierung der gesammelten Daten

• Exfiltration von Daten an eine vom Angreifer kontrollierte Infrastruktur

StepSecurity zufolge zielte die Payload auf mehr als 90 Kategorien von Zugangsdaten ab und exfiltrierte die gesammelten Daten an eine Infrastruktur mit der Domain azurestaticprovider[.]net.

Wer betroffen sein könnte

1. Ihr Projekt hängt direkt von node-ipc ab und verwendet Version 9.1.6, 9.2.3 oder 12.0.1.

2. Ihr Projekt hängt von einer Abhängigkeit ab, die eine der betroffenen Versionen transitiv eingebunden hat.

3. Ihre CI/CD-Pipeline, Ihr Container-Build, Ihre Entwickler-Workstation oder Ihr Paket-Cache hat eine der bösartigen Versionen installiert.

4. Sie verwenden Semver-Bereiche, durch die automatisch eine der betroffenen Versionen ausgewählt werden konnte, etwa ^9, ~9.1, ~9.2, ^12 oder nicht festgelegte Versionen.

5. Sie haben Codepfade ausgeführt, die node-ipc über CommonJS-Auflösung geladen haben.

Ein Treffer in einem Lockfile allein beweist nicht, dass der bösartige Code ausgeführt wurde. Er reicht jedoch aus, um eine Untersuchung einzuleiten. Wenn das Paket in einer Entwickler- oder CI/CD-Umgebung installiert wurde, in der Geheimnisse zugänglich waren, sollten Sie von potenziell offengelegten Zugangsdaten ausgehen.

Hinweise zur Erkennung

Prüfen Sie Ihre Anwendung mit der Snyk CLI, indem Sie diese im Stammverzeichnis Ihres Projekts ausführen.

snyk test

Wenn Sie Ihre Anwendung in der Snyk-Weboberfläche überwachen, werden Sie automatisch gewarnt.

Prüfen Sie andernfalls Abhängigkeitsbäume und Lockfiles auf die betroffenen Versionen:

npm ls node-ipc

npm ls node-ipc --all 2>/dev/null | grep -E '9\.1\.6|9\.2\.3|12\.0\.1'

grep -E '"node-ipc".*"(9\.1\.6|9\.2\.3|12\.0\.1)"' package-lock.json

grep -E 'node-ipc@(9\.1\.6|9\.2\.3|12\.0\.1)' yarn.lock

grep -E 'node-ipc.*9\.1\.6|9\.2\.3|12\.0\.1' pnpm-lock.yaml

find . -path '*/node_modules/node-ipc/node-ipc.cjs' -exec ls -lh {} \;

Zu den gemeldeten Netzwerk- und Host-Indikatoren gehören ausgehende Verbindungen zu sh.azurestaticprovider[.]net, ausgehender Datenverkehr zu 37.16.75[.]69,, unerwarteter UDP/53-Datenverkehr von Anwendungs- oder Build-Prozessen, temporäre Verzeichnisse mit dem Muster $TMPDIR/nt-* sowie Prozesse oder Kindprozesse, die das Umgebungsflag __ntw=1 verwenden. Diese Indikatoren können sich ändern, wenn die Infrastruktur des Angreifers abgeschaltet oder ausgetauscht wird. Das Fehlen dieser Signale ist daher kein Beweis dafür, dass Ihre Systeme sicher sind.

Eindämmung und Reaktion

Bösartige Versionen entfernen

• Fixieren Sie node-ipc auf eine nachweislich sichere Version.

• Aktualisieren Sie Ihre Lockfiles.

• Leeren Sie lokale Paket-Caches und CI-Paket-Caches, in denen die bösartigen Tarballs möglicherweise noch vorhanden sind.

• Erstellen Sie Artefakte aus sauberen Abhängigkeitsbäumen neu.

Alle Umgebungen ermitteln, in denen das Paket installiert wurde

• Entwickler-Laptops

• CI-Runner

• Build-Container

• Interne Artefakt-Registries

• Kurzlebige Build-Worker

• Produktionssysteme, falls das Paket zur Laufzeit importiert wurde

Offengelegte Geheimnisse rotieren

• npm-Tokens

• GitHub-Tokens

• Cloud-Anbieter-Zugangsdaten

• SSH-Schlüssel

• CI/CD-Geheimnisse

• Kubernetes-Tokens und kubeconfigs

• Datenbank-Zugangsdaten

• Zugangsdaten für den Zugriff auf Terraform-Statusdateien

• Zugangsdaten für KI- und Entwickler-Tools

Sitzungen ungültig machen und Zugriffsprotokolle prüfen

• Prüfen Sie Cloud-Audit-Logs.

• Prüfen Sie die Audit-Logs Ihrer GitHub-Organisation.

• Prüfen Sie die Aktivitäten des npm-Kontos und den Verlauf der Paketveröffentlichungen.

• Achten Sie auf ungewöhnliches Verhalten bei CI/CD-Jobs, neue Geheimnisse, neue Deployment-Schlüssel oder unerwartete Paketveröffentlichungen.

Paketnutzung absichern

• Verwenden Sie Lockfiles und reproduzierbare Builds.

• Vermeiden Sie, neu veröffentlichte Paketversionen automatisch in Produktions-Build-Systemen zu verwenden.

• Erwägen Sie Verzögerungen bei Abhängigkeitsaktualisierungen oder Richtlinien für interne Paket-Proxys.

• Erzwingen Sie MFA für npm-Veröffentlichende.

• Entfernen Sie inaktuelle Maintainer und abgelaufene E-Mail-Domains aus Open-Source-Projekten.

• Überwachen Sie Änderungen an Maintainer-Konten und neue Releases nach langen Phasen der Inaktivität.

• Scannen und überwachen Sie Ihre Anwendungen kontinuierlich mit Snyk, um Sicherheitslücken zu erkennen

Warum dieser Vorfall wichtig ist

Dieser Vorfall ist ein weiteres Beispiel dafür, dass Angreifer die Vertrauensbeziehungen ins Visier nehmen, auf denen Open-Source-Ökosysteme beruhen. Das bösartige Paket musste das Anwendungsverhalten nicht beeinträchtigen, um wirksam zu sein. Indem der Angreifer die erwartete Funktionalität beibehielt und gleichzeitig unbemerkt Zugangsdaten abgriff, erhöhte er die Wahrscheinlichkeit, dass kompromittierte Builds und Entwicklerumgebungen normal weiterliefen.

Der Vorfall zeigt auch eine wiederkehrende Schwachstelle in der Supply Chain: Inaktive oder nur sporadisch gepflegte Pakete können auch nach langen Phasen der Inaktivität eine große Reichweite im Ökosystem haben. Wenn eine frühere Maintainer-Identität wiederhergestellt, gekapert oder missbraucht werden kann, erhalten Angreifer möglicherweise einen Weg, bösartige Versionen in Abhängigkeitsgraphen einzuschleusen, ohne Versionskontroll- oder CI/CD-Systeme anzutasten.

Aktuelle Einschätzung

Den verfügbaren Informationen zufolge sollte dieser Vorfall als kritische npm-Supply-Chain-Kompromittierung eingestuft werden, bei der vor allem der Diebstahl von Zugangsdaten aus Entwickler- und CI/CD-Umgebungen droht. Als bestätigte betroffene Versionen gelten derzeit node-ipc@9.1.6, node-ipc@9.2.3 und node-ipc@12.0.1. Wahrscheinlich erfolgte der Angriff über den Missbrauch eines Maintainer-Kontos mit Veröffentlichungsrechten, möglicherweise durch die Wiederherstellung einer abgelaufenen E-Mail-Domain des Maintainers. Die Untersuchung der Ursachen dauert jedoch noch an.

Teams sollten umgehend feststellen, ob eine betroffene Version installiert wurde, Geheimnisse aus exponierten Umgebungen rotieren und auf Folgeangriffe mit gestohlenen Zugangsdaten achten.