Im März 2026 lieferte ein npm Paket mit Millionen Downloads einen Trojaner mit.
Zwei Versionen der Bibliothek axios, die nicht vom Projekt stammten, zogen im März 2026 eine bösartige Abhängigkeit nach, die in mehreren Stufen einen Trojaner für den Fernzugriff nachlud. Betroffen war nicht der Server, sondern der Rechner, auf dem installiert wurde. Wer versteht, warum genau dieser Rechner das Ziel ist, braucht keine neue Software, sondern drei Massnahmen, die zusammen wenige Tage kosten.
Im März 2026 erschienen auf npm, dem Verzeichnis, aus dem sich praktisch jedes JavaScript Projekt seine Bausteine holt, zwei Versionen der Bibliothek axios, die nicht vom Projekt stammten: und . Beide zogen eine zusätzliche, bösartige Abhängigkeit nach, die in mehreren Stufen weiteren Code nachlud, am Ende einen Trojaner für den Fernzugriff auf den Rechner. Die amerikanische Behörde CISA veröffentlichte dazu eine Warnung. axios ist eine weit verbreitete Bibliothek mit Millionen Downloads und steckt auch in Software von Unternehmen, die den Namen nie gehört haben. Dieser Beitrag erklärt, was passiert ist, warum das Ziel nicht der Server war, sondern der Rechner des Entwicklers und welche drei Massnahmen bei uns und bei unseren Kunden tatsächlich etwas bewirken.
Ein Paket, das niemand bewusst gewählt hat, läuft trotzdem auf jedem Rechner, der es braucht.
Eine Webanwendung besteht heute selten aus dem Code, den das eigene Team geschrieben hat. Nach unserer Erfahrung wählt ein Team 20 bis 40 Bausteine bewusst aus und diese Bausteine bringen ihre eigenen mit, bis am Ende 800 bis 1'500 Pakete installiert sind, von denen niemand im Unternehmen eine Liste hat. axios ist so ein Baustein: Es sorgt dafür, dass ein Programm mit einem anderen über das Internet sprechen kann und es steckt deshalb in Onlineshops, in Kundenportalen, in internen Werkzeugen und in Software, die ein Lieferant gebaut hat.
Wer ein solches Paket übernimmt, muss niemanden überzeugen, etwas zu installieren. Es reicht, eine neue Version zu veröffentlichen. Jeder Rechner, der das Projekt danach einrichtet oder aktualisiert und die Version nicht festgeschrieben hat, holt sie sich selber und der nachgeladene Code läuft dort, wo die Installation stattfindet: auf dem Laptop des Entwicklers, auf dem Rechner, der die Software baut, oder auf dem Server. Wer sein Werkzeug mit KI hat schreiben lassen und den Code nie gelesen hat, weiss meistens nicht einmal, dass axios drinsteckt und kann die Frage, ob er betroffen ist, nicht beantworten.
Der Rechner eines Entwicklers ist für einen Angreifer wertvoller als der Server.
Ein Server ist in der Regel abgeschottet, läuft mit wenigen Rechten und wird überwacht. Der Laptop eines Entwicklers ist das Gegenteil davon, weil er alles zusammenführt: den Zugang zum Code, die Schlüssel zur Cloud, das Passwort zur Datenbank, den Zugang zu den Systemen der Kunden, oft einen entsperrten Passwortmanager und Zugangstoken, die nie ablaufen. Nach unserer Erfahrung liegen auf einem solchen Rechner Zugänge zu 20 bis 50 Diensten und die wenigsten davon fragen ein zweites Mal nach, wenn die Anfrage vom richtigen Gerät kommt.
Ein Trojaner mit Fernzugriff auf diesem Rechner heisst, dass jemand anderes als der Entwickler arbeitet, mit denselben Rechten und ohne dass ein System einen Unterschied sieht. Das ist der Grund, warum solche Angriffe auf Pakete zielen, die Entwickler installieren und nicht auf die Software, die am Ende beim Kunden läuft. Der Weg zum Kunden führt über den Rechner, der den Kunden bedient. Wir haben beschrieben, warum ein Backup ein Versprechen ist und erst der Restore der Beweis. Gegen diesen Fall hilft auch ein geprüftes Backup nicht, weil nichts gelöscht wurde: Die Daten sind noch da, nur hat sie jetzt auch jemand anderes.
Drei Massnahmen wirken und keine davon ist ein neues Produkt.
Die erste Massnahme ist, Versionen festzuschreiben und neue Versionen warten zu lassen. Jedes Projekt bekommt eine Datei, die für jedes der 800 bis 1'500 Pakete die genaue Version festhält und jede Installation, auf dem Laptop wie auf dem Rechner, der die Software baut, verwendet genau diese Liste. Eine neue Version wird nicht am Tag ihres Erscheinens übernommen, sondern frühestens nach sieben Tagen, weil bösartige Versionen meist innert weniger Tage auffallen und entfernt werden. Das kostet einen halben Tag beim Einrichten und danach eine halbe Stunde pro Aktualisierungsrunde.
Die zweite Massnahme betrifft die Zugänge auf dem Entwicklerrechner. Kein Schlüssel liegt dauerhaft auf dem Laptop, Zugangstoken laufen nach Stunden ab und nicht nach Jahren, jede Anmeldung an Cloud, Code und Datenbank braucht einen zweiten Faktor und der Zugang zu den produktiven Systemen ist ein eigener Schritt, den man bewusst auslöst und der nach dem Einsatz wieder schliesst. Ein Trojaner findet dann einen Rechner, auf dem gerade nichts Wertvolles liegt. Das kostet ein bis zwei Tage pro Team, einmal.
Die dritte Massnahme ist, innert einer Stunde sagen zu können, ob man betroffen ist. Dafür braucht es eine Liste aller Projekte mit ihren Versionsdateien, damit man nach suchen kann, statt bei fünf Leuten nachzufragen und einen aufgeschriebenen Ablauf für den Fall, dass die Antwort ja lautet: welche Zugänge in welcher Reihenfolge ersetzt werden, wer das tut und wer die Kunden informiert. Dieser Ablauf wird einmal durchgespielt, an einem ruhigen Nachmittag. Wer einem Kunden oder Auditor die Datensicherheit erklären muss, hat mit dieser Liste und diesem Ablauf bereits den Teil der Antwort, der sonst zwei Wochen dauert.
Die Massnahmen sind günstig, entschieden werden müssen sie trotzdem.
Zusammen kosten die drei Massnahmen nach unserer Erfahrung drei bis fünf Arbeitstage und danach wenige Stunden pro Monat. Das ist weniger als ein einziger Tag, an dem ein Team jeden Zugang ersetzt, jeden Kunden anruft und nicht weiss, was der Angreifer in der Zwischenzeit gesehen hat. Trotzdem sind sie in den meisten KMU nicht umgesetzt und der Grund ist nicht das Geld. Jede der drei Massnahmen macht den Alltag der Entwickler einen Schritt langsamer und niemand im Unternehmen ist dafür zuständig, diesen Schritt zu verlangen und die Verantwortung dafür zu tragen.
Das ist die Aufgabe eines CTO: zu entscheiden, welches Risiko das Unternehmen trägt und welches nicht und die Regel durchzusetzen, auch wenn sie am Freitag um fünf unbequem ist. Wo diese Rolle fehlt, bleibt die Entscheidung liegen, bis eine Meldung wie die über axios kommt und dann wird sie unter Druck getroffen, statt an einem ruhigen Nachmittag. Der Fall axios war für Unternehmen, die die drei Massnahmen hatten, eine Suche von einer Stunde. Für alle anderen war er die Frage, ob sie überhaupt wissen, wo sie suchen müssten.
Warum nicht einfach die KI fragen
Frag sie
Wenn dir die KI in fünf Minuten erklärt, was ein Supply Chain Angriff ist und wie man Versionen festschreibt, ist das ein guter Anfang und wir sind die Ersten, die das sagen.
Was die KI nicht weiss
Welche der 1'500 Pakete in deiner Software gerade laufen, welche Zugänge auf dem Laptop deines Entwicklers liegen, ob dein Team innert einer Stunde sagen könnte, ob es betroffen ist und wer die Verantwortung trägt, wenn die Antwort falsch war. Dafür gibt es uns.
Weitere Beiträge zu #sicherheit.
-
rolleninfrastruktursicherheit
Ein System Engineer hält am Laufen, was alle anderen voraussetzen.
Betriebssysteme, Zugänge, Zertifikate und Sicherungen gehören zu der Schicht, die alle voraussetzen und die in vielen KMU niemandem gehört. Was die Rolle tut, worin sie sich von Cloud und Platform Engineer unterscheidet und mit wie viel Aufwand ein KMU rechnet.
-
sicherheitentwicklungrisiko
Im August 2026 verteilte ein Wurm über 1300 Paketversionen und stahl unterwegs Entwicklerzugänge.
Im August 2026 wurde über ein übernommenes Entwicklerkonto Schadcode in über 1300 Versionen der keyv Pakete verteilt, der Zugangsdaten stiehlt und sich damit selber weiterträgt. Der Beitrag zeigt, warum Angreifer auf Entwicklerzugänge zielen und was ein Betrieb jetzt kontrolliert.
-
risikosicherheitcto
Ein Risiko, das benannt ist, ist schon halb erledigt.
Die Risiken, die ein Unternehmen tatsächlich treffen, stehen selten auf einer Liste. Wo sie in einem KMU sitzen und wie eine Inventur an einem halben Tag daraus benannte Risiken macht.
-
sicherheitentwicklungrisiko
Am 17. Juni 2026 wurde aus einem gestohlenen Entwicklerkonto in neunzehn Minuten ein Verteilsystem für Schadsoftware.
Ein einziges übernommenes Konto reichte, um über 140 Pakete eines KI Frameworks in rund neunzehn Minuten mit Schadsoftware neu zu veröffentlichen. Wer solche Frameworks einsetzt, hat danach kein Softwareproblem, sondern ein Schlüsselproblem.