Ausbreitung von npm-Würmern über Entwicklungsrechner und Veröffentlichungskonten eindämmen

Worum es geht

Stand: 25. Oktober 2026. Dieses Vorgehen zur Eindämmung stützt sich auf Microsofts ChainDrop-Bericht vom 4. August 2026 und die am 8. Oktober 2026 veröffentlichte Sicherheitsmeldung der Tensorlake-Maintainer in den für diese Prüfung abgerufenen Fassungen. Beide Quellen erneut auf überarbeitete Paketlisten, Indikatoren für eine dauerhafte Verankerung und Wiederherstellungsanweisungen prüfen; die Paketanzahl ist eine Beobachtung aus dem Bericht und kein vollständiger aktueller Bestand.

Microsoft berichtet von mehr als 400 betroffenen npm-Paketen. Während der Installation ausgeführter Code stahl Zugangsdaten und nutzte Veröffentlichungsrechte, um sich auf weitere Pakete auszubreiten. Tensorlake bestätigt separat die unbefugte npm-Version 0.5.144 einschliesslich der in seiner Sicherheitsmeldung aufgeführten nativen Pakete. Als Ausgangspunkt für die Wiederherstellung dient 0.5.143; dies ist ein Rollback und keine neu gepatchte Version.

Warum es wichtig ist

Microsoft beschreibt eine Gefährdung, die von Entwicklungsrechnern über CI-Zugangsdaten und Repositories bis zu Artefakten aus betroffenen Builds reicht. Wer eine Abhängigkeit verwendet und zugleich Veröffentlichungsrechte hat, kann dadurch selbst zum Verbreiter werden. Der Umfang des Vorfalls umfasst alle Identitäten und Ressourcen, die von der Installationsumgebung aus erreichbar sind, und nicht nur die Anwendung, die die Abhängigkeit angefordert hat.

Ein erfolgreicher Build beantwortet nicht, ob ein Release autorisiert war. Für die Prüfung sind Nachweise erforderlich, die Paketartefakt, Quellcoderevision, Workflow und Release-Freigabe miteinander verknüpfen. Unerwartete Änderungen an einem dieser Elemente zum Anlass für eine Untersuchung nehmen.

So wird es angewendet

• Betroffene Installations- und Veröffentlichungsjobs aussetzen. Genaue Versionen in Lock-Dateien, Registry-Aufzeichnungen, Caches und Build-Logs erfassen, einschliesslich transitiver Abhängigkeiten. Festhalten, welche Arbeitsrechner, Runner und nachgelagerten Artefakte diese verwendet haben. Vor dem Austausch von Umgebungen Beweise sichern.
• Auf einem sauberen Runner mit einer geprüften Lock-Datei npm ci --ignore-scripts verwenden. Laut npm-Dokumentation führt ci eine Installation gemäss Lock-Datei aus, und ignore-scripts unterdrückt Paketskripte. Vor Übernahme dieser Richtlinie den resultierenden Build prüfen: Abhängigkeiten, die Installationsskripte benötigen, müssen gegebenenfalls einzeln geprüft und gesondert behandelt werden.
• Zugangsdaten für Veröffentlichungen aus Jobs zur Installation von Abhängigkeiten entfernen. Wenn private Pakete eine Authentifizierung erfordern, granulare Tokens mit reinem Lesezugriff verwenden. Geeignete Veröffentlichungsworkflows auf Trusted Publishing umstellen, den Wechsel testen, anschliessend veraltete Schreib-Tokens widerrufen und herkömmliche Veröffentlichungen per Token einschränken. npm unterstützt es, Zwei-Faktor-Authentifizierung vorzuschreiben und gleichzeitig solche Tokens zu untersagen; Veröffentlichungen über OIDC bleiben möglich.
• Registry-Releases mit freigegebenen Release-Aufzeichnungen abgleichen. Unerwartete Workflow-Dateien, Repository-Branches und Konfigurationsänderungen an Entwicklungswerkzeugen prüfen. Unerklärte Abweichungen untersuchen, auch wenn für das veröffentlichte Paket ein Herkunftsnachweis vorliegt oder kein entsprechender Quellcode-Commit existiert.
• Falls die schädliche Tensorlake-Version ausgeführt wurde, vor dem Widerruf von Zugangsdaten die Vorsichtsmassnahme gegen ihre dauerhafte Verankerung beachten: Die Komponente gh-token-monitor nach dem plattformspezifischen Verfahren aus der Sicherheitsmeldung deaktivieren. Sie kann Benutzerdaten zerstören, wenn das überwachte GitHub-Token widerrufen wird. Zugangsdaten von einem sauberen Rechner aus austauschen und betroffene Systeme neu aufbauen.

Stolpersteine

ignore-scripts macht schädlichen Laufzeitcode nicht unschädlich. Explizite Befehle wie npm run führen das angeforderte Skript weiterhin aus. Zwei-Faktor-Authentifizierung widerruft keine gestohlenen Tokens, und die Wiederherstellung einer sauberen Abhängigkeit macht unbefugte Releases nicht rückgängig. Vor der erneuten Freigabe von Veröffentlichungen Kontozugriffe, Repository-Zustand und die Ausgangsbestandteile der Ersatz-Builds überprüfen.