Im August 2026 verteilte ein Wurm über 1300 Paketversionen und stahl unterwegs Entwicklerzugänge.

Im August 2026 wurde das GitHub Konto des Entwicklers übernommen, der die Paketfamilie keyv betreut. keyv ist ein kleiner Baustein, der Daten zwischenspeichert und wird rund 127 Millionen Mal pro Woche heruntergeladen. Über das übernommene Konto gelangte Schadcode in die ganze Familie: über 1300 Paketversionen, zusammen rund 2 Milliarden Downloads pro Monat. Der Code stiehlt Zugangsdaten und verbreitet sich mit ihnen selber weiter, weshalb er als Wurm bezeichnet wird. In der Berichterstattung trägt er den Namen Shai-Hulud. Für ein Schweizer KMU ist die interessante Frage nicht, ob keyv im Einsatz ist. Sie lautet, warum Angreifer inzwischen Entwicklerzugänge einsammeln statt Kundendaten.

Ein Wurm sucht sich das nächste Opfer selber, ein Trojaner wartet auf einen Menschen.

Der Unterschied zu den beiden Fällen davor liegt nicht in der Menge, sondern im Mechanismus. Bei den manipulierten Versionen der Bibliothek axios im März lud der Schadcode weiteren Code nach, der auf dem befallenen Rechner blieb. Bei Mastra AI im Juni veröffentlichte ein Angreifer mit einem gestohlenen Konto mehr als 140 Pakete neu, in neunzehn Minuten, aber eben von Hand. Beide Male musste jemand den nächsten Schritt auslösen.

Dieser Code braucht niemanden mehr. Er durchsucht den Rechner, auf dem er landet, nach Zugangsdaten: Token für das Paketverzeichnis, Schlüssel für die Cloud, Anmeldungen an Code Plattformen. Findet er darunter einen Zugang, der selber Pakete veröffentlichen darf, veröffentlicht er damit die nächste Runde manipulierter Versionen. Jeder befallene Entwicklerrechner wird zum Ausgangspunkt für den nächsten. So werden aus einem übernommenen Konto über 1300 Paketversionen, ohne dass der Angreifer weiterarbeitet.

Das verändert die Zeitrechnung. Ein Trojaner wird gefährlich, wenn ihn jemand benutzt. Ein Wurm ist in den Stunden am gefährlichsten, in denen noch niemand von ihm weiss, weil er in dieser Zeit mit jeder Runde mehr Wege in mehr Unternehmen öffnet. Wer erst reagiert, wenn die Meldung durch die Fachpresse geht, reagiert auf einen Stand von gestern.

Ein gestohlener Entwicklerzugang ist mehr wert als ein gestohlener Kundendatensatz.

Ein Kundendatensatz ist ein abgeschlossenes Gut. Er enthält, was er enthält: Name, Adresse, Bestellungen, vielleicht eine Zahlungsverbindung. Wer ihn stiehlt, muss ihn verkaufen oder selber benutzen und ab dem Moment, in dem der Vorfall gemeldet ist, verliert er an Wert, weil Karten gesperrt und Passwörter geändert werden.

Ein Entwicklerzugang ist das Gegenteil davon, weil er neue Ziele erzeugt. Er gibt Zugriff auf den Code, auf die Systeme, in denen die Software gebaut wird und im Fall von keyv auf eine Verteilung, die jede Woche 127 Millionen Mal abgerufen wird. Ein Angreifer, der ihn hat, muss niemanden mehr dazu bringen, etwas zu installieren oder auf etwas zu klicken. Er veröffentlicht eine Version und der Rest läuft von alleine, auf den Rechnern von Firmen, die den Namen des Pakets nie gehört haben.

Dazu kommt die Frage, auf welcher Seite ein Unternehmen steht. Fliessen Kundendaten ab, ist der Betrieb das Opfer, meldet den Vorfall und informiert die Betroffenen. Wird über einen Zugang aus dem eigenen Haus manipulierte Software an Kunden ausgeliefert, ist der Betrieb die Quelle. Nach unserer Erfahrung ist das der teurere der beiden Fälle: Der eine kostet eine Meldung und einige unangenehme Wochen, der andere kostet die Kundenbeziehungen, über die ausgeliefert wurde. Deshalb gehören die Zugänge der Entwickler in dieselbe Risikoklasse wie die Zahlungsberechtigungen in der Buchhaltung und nicht in die Kategorie Werkzeug, um die sich das Team selber kümmert. Wie ein Risiko überhaupt auf den Tisch kommt, das niemand benannt hat, steht in Die gefährlichsten Risiken sind die unbekannten.

Betroffen ist auch, wer den Namen keyv noch nie gehört hat.

keyv wird selten bewusst ausgewählt. Es kommt als Abhängigkeit einer Abhängigkeit mit, über ein Werkzeug, das ein Team ausgesucht hat, oder über Software, die ein Dienstleister gebaut hat. Genau darum ist die Frage, ob ein Unternehmen betroffen ist, keine Frage an das Gedächtnis, sondern eine Suche in Dateien. Wer eine Liste seiner Projekte mit ihren Versionsdateien hat, sucht nach den betroffenen Versionen und weiss es innert einer Stunde. Wer keine hat, fragt bei mehreren Leuten nach und bekommt Antworten, auf die sich niemand verlassen mag. Wie diese Liste entsteht, steht im Beitrag zu axios.

Zwei Punkte kommen bei einem Wurm hinzu. Erstens genügt das Installieren: Solche Pakete führen beim Einrichten selbständig Code aus, es muss niemand die Software je gestartet haben. Zweitens ist der Entwicklerrechner nicht der einzige Ort, an dem installiert wird. Der Rechner, der die Software automatisch baut, tut dasselbe, meist mehrmals täglich und mit Zugängen, die dort dauerhaft hinterlegt sind. In den Protokollen dieses Systems steht auf den Tag genau, was wann geholt wurde.

Nach so einem Fall gilt jeder Zugang als bekannt, der im Zeitfenster erreichbar war.

Die Reihenfolge ist bei einem Wurm eine andere als bei einem Trojaner, weil sein Produkt die Zugänge sind. Zuerst werden die Token ersetzt, die auf betroffenen Rechnern und im Bausystem lagen und zwar alle, nicht nur die auffälligen. Ein Schlüssel, der in diesem Zeitfenster lesbar war, ist verbrannt, auch wenn nichts Ungewöhnliches passiert ist. Danach folgt die Frage, ob das Unternehmen selber Pakete veröffentlicht und wenn ja, ob im fraglichen Zeitraum Versionen erschienen sind, die niemand ausgelöst hat. Erst zum Schluss kommt der Rechner, auf dem alles begann.

Vorbeugend wirken dieselben drei Massnahmen wie im März, ergänzt um eine vierte, die genau auf diesen Mechanismus zielt: Ein Zugang, der Pakete veröffentlichen darf, liegt nicht auf einem Laptop und nicht in einer Datei, sondern ist an ein Gerät gebunden, das eine Person in der Hand hält. Das kostet nach unserer Erfahrung einen halben Tag pro Team und nimmt dem Wurm den Weg, auf dem er sich verbreitet.

Der Entscheid dahinter ist keine technische Frage. Es ist die Frage, wer im Unternehmen bestimmt, welcher Zugang wie geschützt wird und wer die Antwort schuldet, wenn ein Kunde fragt, ob die ausgelieferte Software sauber war. In grösseren Betrieben liegt das bei einer Person, die diese Arbeit hauptberuflich macht, wie wir sie in Was macht ein Cyber Security Engineer beschrieben haben. In einem KMU liegt es meistens bei niemandem und dann entscheidet der Zufall darüber, wie lange das Zeitfenster offensteht.