Wenn die Signatur gültig und der Code Malware ist: Der keyv-Lieferkettenangriff

Am 4. August 2026 pushte ein Angreifer, der den GitHub-Account des Maintainers hinter keyv — einer Key-Value-Storage-Bibliothek mit rund 127 Millionen wöchentlichen Downloads — kompromittiert hatte, einen Credential-Stealer direkt in den Main-Branch und veröffentlichte Releases über die gesamte Paketfamilie hinweg. Ein sich selbst verbreitender Wurm nutzte anschliessend gestohlene npm-Zugangsdaten, um automatisch jedes andere Paket zu kompromittieren, für das dieser Maintainer Publish-Rechte besass. Innerhalb weniger Stunden hatte die Kampagne über 1’300 Paketversionen mit zusammen zwei Milliarden monatlichen Downloads erreicht, darunter weit verbreitete Bibliotheken wie cacheable, flat-cache und file-entry-cache.

Jede kryptografische Prüfung bestand

Was Sicherheitsteams am meisten beunruhigen sollte, ist nicht das Ausmass. Die vergifteten Pakete trugen eine gültige npm-Provenance, signiert von GitHub Actions. Sie wurden tatsächlich in jenem Repository, in jenem Workflow, bei jenem Commit gebaut. Die Attestierung war korrekt. Der Code war Malware. Dies war die zweite npm-Kompromittierung innerhalb von drei Monaten, bei der Malware mit legitimen Attestierungen ausgeliefert wurde.

Die Software-Lieferkettensicherheit hat sich in den letzten Jahren zunehmend auf Signierung und Provenance als Antwort auf Paketmanipulation konzentriert. Diese Arbeit bleibt wertvoll, doch dieser Vorfall zeigt ihre Grenze deutlich auf. Provenance belegt, dass ein Paket von dort stammt, wo es vorgibt herzukommen. Sie sagt nichts darüber aus, ob der Account hinter diesem Ursprung zum Zeitpunkt des Builds unter der Kontrolle seines rechtmässigen Inhabers stand. Geschieht die Kompromittierung vor dem Build, bestätigt die Signatur die Malware.

Die Payload fügte einen Preinstall-Hook hinzu, der eine Laufzeitumgebung herunterlud und einen verschleierten Stealer ausführte, der auf npm-Tokens, GitHub-CLI-Tokens, AWS-Zugangsdaten, Vault-Tokens, Kubernetes-Konfigurationen und Krypto-Wallets abzielte. Diese gestohlenen Zugangsdaten wurden dann genutzt, um weitere kompromittierte Pakete zu veröffentlichen — genau das machte aus einer einzelnen Account-Übernahme eine sich selbst verbreitende Kampagne.

Warum das auch Unternehmen betrifft, die selbst keinen Code schreiben

Der Instinkt der meisten KMU und Asset-Management-Unternehmen ist, dies als Entwicklerproblem abzutun. Das ist es aus zwei Gründen nicht.

Erstens sind Abhängigkeiten transitiv. Installiert ein Entwickler ein Paket, werden die Pakete, von denen dieses Paket abhängt, automatisch mitinstalliert. Komponenten, die niemand ausgewählt hat, landen im Build — genau deshalb verbreitete sich die Kompromittierung einer einzelnen Caching-Bibliothek in die Software-Lieferketten zahlreicher Unternehmen, die noch nie von ihr gehört hatten.

Zweitens, und relevanter, wenn Sie eher einkaufen als selbst entwickeln: Ihre Lieferanten tragen dieses Risiko. Das Kundenportal, das Buchungssystem, das interne Tool, das vor zwei Jahren von einer Agentur gebaut wurde — all das hängt wahrscheinlich von npm-Paketen ab. Ein Credential-Stealer, der in der CI-Umgebung eines Lieferanten läuft, erreicht die Cloud-Zugangsdaten und Deployment-Tokens für Systeme, die Ihre Daten enthalten. Ihr Drittanbieter-Risikofragebogen fragt mit grosser Wahrscheinlichkeit nicht danach.

Was zu tun ist

Wenn Sie Software entwickeln, besteht die unmittelbare Massnahme darin, festzustellen, ob eine betroffene Version gezogen wurde und — entscheidend — ob sie ausgeführt worden sein könnte. Die bösartigen Versionen wurden in einem begrenzten Zeitfenster am 4. August veröffentlicht; eine Version vor diesem Fenster ist nicht Teil der Kampagne — prüfen Sie daher die konkrete Version, nicht nur den Paketnamen. Sind Lifecycle-Skripte standardmässig deaktiviert, stellt ein gezogenes, aber nie ausgeführtes Paket ein deutlich geringeres Risiko dar. Bei jeder bestätigten Ausführung: npm-Tokens, Cloud-Zugangsdaten und jedes aus dieser Umgebung erreichbare Secret rotieren und die jüngste Publish-Aktivität der eigenen Pakete überprüfen.

Strukturell lautet die Lehre, dass Vertrauensentscheidungen nicht allein auf Signaturen beruhen dürfen. Abhängigkeiten auf exakte Versionen statt auf Bereiche festlegen, Install-Skripte in Entwickler- und CI-Umgebungen standardmässig deaktivieren und neue Paketversionen vor Aufnahme in Builds eine Staging-Periode durchlaufen lassen. Der Grossteil des Schadens bei Kampagnen dieser Art entsteht in den ersten Stunden nach der Veröffentlichung — schon eine kurze Verzögerung eliminiert den Grossteil der Exposition.

Für Unternehmen, die eher einkaufen als selbst entwickeln, gehört dies jetzt in den Lieferanten-Assurance-Prozess: fragen Sie, ob sie von der npm-Kampagne vom 4. August betroffen waren, wie sie feststellen, welche Open-Source-Komponenten in ihren Produkten stecken, und welchen Prozess sie für die Rotation von Zugangsdaten nach einer vermuteten Build-System-Kompromittierung haben. Vage Beruhigung ist keine Antwort.

Kernaussage: Ein kompromittierter Maintainer-Account verwandelte Hunderte vertrauenswürdiger npm-Pakete in Credential-Stealer, und die bösartigen Releases trugen kryptografisch gültige Provenance. Signierung belegt Herkunft, nicht die Integrität der Absicht, und kann nicht die alleinige Grundlage für das Vertrauen in eine Abhängigkeit sein. Prüfen Sie konkrete Versionen statt Paketnamen, deaktivieren Sie Install-Skripte, verzögern Sie die Übernahme neuer Releases, und erweitern Sie die Frage auf die Lieferanten, die Software in Ihrem Auftrag entwickeln.