Jede Kompromittierung in der Lieferkette hat einen Moment, in dem Vertrauen leise den Besitzer wechselt. Unserer passierte in einem System, das kaum ein Team je anschaut: der Verbindung zwischen einem GitHub-Repository und einem npm-Paket.
Die Sicherheitsforscher von Bloom Security nannten die Schwachstelle SlugFest, und das Bild ihres leitenden Forschers Golan Myers ist geblieben: Es ist wie ein Schloss, das die Adresse an der Tür prüft statt die Person, der das Haus gehört. Wenn der Eigentümer auszieht, bekommt der neue Mieter den Schlüssel.
Das Unangenehme daran: Niemand musste eine Zugangsberechtigung stehlen. Die einzige Voraussetzung war eine Umbenennung des Repositories.
Was npm Trusted Publishing lösen sollte
Im Juli 2025 führte npm Trusted Publishing ein, und die Idee war wirklich gut. Statt langlebige npm-Token auf einem Build-Server zu speichern (und sie über Logs, Caches und kompromittierte CI-Runner zu leaken), fordert ein GitHub-Actions-Workflow ein kurzlebiges OpenID-Connect-Token an, legt es npm vor und erhält dafür eine Veröffentlichungsberechtigung. Releases kommen mit Provenance-Attestierungen, sodass jeder nachvollziehen kann, wo ein Paket gebaut wurde.
Das Design entfernt eine ganze Klasse von Secret-Leak-Vorfällen. Es brachte aber auch einen subtilen Fehlermodus mit, wegen eines einzigen Feldes.
npm band die Vertrauensbeziehung an die für Menschen lesbare Adresse des Repositories: owner/repository. GitHubs OIDC-Token enthalten zusätzlich die permanente numerische ID des Repositories, die Umbenennungen und Transfers übersteht. npm ignorierte diese Nummer bis zur ersten erfolgreichen Veröffentlichung eines Pakets vollständig und verglich nur den Namen.
Namen wandern. Sie werden frei, wenn ein Maintainer ein Repository umbenennt, überträgt oder löscht, und sobald ein Name frei ist, kann ihn jeder beanspruchen.
Wie SlugFest tatsächlich funktioniert
- Ein Maintainer konfiguriert Trusted Publishing für ein Paket, hat aber noch keine Version aus diesem Repository veröffentlicht. Die Bindung basiert also noch auf dem Namen.
- Der Maintainer benennt das Repository um, überträgt es oder löscht es. Der alte Slug
owner/repositorywird verfügbar. - Ein Angreifer legt ein neues Repository genau unter diesem frei gewordenen Slug an und startet einen Publish-Workflow. GitHub stellt ein OIDC-Token aus, das den zurückeroberten Namen mit einer brandneuen Repository-ID trägt.
- npm prüft den Namen, findet die Übereinstimmung mit der gespeicherten Konfiguration und übergibt ein Veröffentlichungstoken für ein Paket, das dem Angreifer nicht gehört.
Von dort veröffentlicht der Angreifer eine bösartige Version unter dem legitimen Paketnamen. Downloadzahlen, Reputation und jedes abhängige Projekt kommen mit. Blooms registryweiter Scan fand mehr als 1.500 verwundbare Pakete mit über 10 Millionen kumulierten Downloads und mehr als einer Million Downloads pro Monat.
Bloom meldete die Lücke am 6. Juni 2026 an GitHub. Am 9. Juni wurde sie triagiert. Danach wurde es im Juli still, und der Fix kam erst, als die Forscher die Veröffentlichung vorbereiteten, mehr als 120 Tage später. GitHub und npm haben die Behebung inzwischen bestätigt und sich für die zögerliche Kommunikation entschuldigt.
Der Fix hat genau die richtige Form: Neu erstellte Trusted-Publisher-Konfigurationen laufen jetzt nach 48 Stunden ab, wenn sie nicht eine erste erfolgreiche Veröffentlichung abschließen, die die Bindung an die unveränderliche Identität des Repositories validiert. Eine Änderung der Repository- oder Projektidentität erfordert eine neue Vertrauensbeziehung und ein neues 48-Stunden-Fenster. npm akzeptiert außerdem keine Trusted-Publishing-Token mehr aus issue_comment-Events, zusätzlich zur bestehenden Einschränkung für pull_request_target.
Dann kamen die Agenten
Wäre SlugFest nur ein Thema für menschliche Entwickler mit npm install, wäre es schon ernst genug. Es ist die zweite Hälfte von Blooms Forschung, die verändern sollte, wie du über deine Build-Pipeline denkst.
Bloom untersuchte Millionen KI-Agenten in Dutzenden von Organisationen. Ein durchschnittlicher Endpoint erhält monatlich rund 70 Pakete, die von KI-Agenten installiert wurden. Auf Entwicklermaschinen sind es fast 350. Einzelne Agenten installieren 0,3 bis 1,2 Pakete pro Tag; auf Entwicklermaschinen laufen täglich zwei bis drei direkte Installationen, zusätzlich zu allem, was diese Pakete mitbringen. Ein typischer Endpoint betreibt drei Agenten über Kommandozeilen, IDEs, Erweiterungen und Assistenten. Entwicklermaschinen betreiben fünf oder mehr.
Nun verbinde das mit dem Verhalten eines Agenten. Er löst Abhängigkeiten selbst auf, bevorzugt die neueste Version und fragt selten, woher ein Paket stammt. Eine bösartige Version, die über einen zurückeroberten Slug veröffentlicht wurde, wird installiert, und ihr postinstall-Hook führt Code aus, ohne dass ein Mensch eingreift.
Bloom erwischte das im Produktivbetrieb und blockierte den KI-Agenten eines Kunden beim Versuch, eines der betroffenen Pakete zu installieren.
Der Nutzen für den Angreifer ist eine Kaskade. Ein Paket wird kompromittiert. Ein KI-Agent auf der Maschine eines populären Maintainers zieht es hinein. Dieser Endpoint wird zur Startrampe für eine bösartige Version des Maintainer-Pakets selbst, und jeder Konsument ist exponiert. Das ist das Shai-Hulud-Muster mit Brandbeschleuniger.
Provenance ist kein Häkchen
Es gibt einen zweiten blinden Fleck, der Aufmerksamkeit verdient, weil er ein Compliance-Audit übersteht.
Eine bösartige Version kann eine Provenance-Attestierung tragen, die vom Repository des Angreifers selbst erzeugt wurde. Manche Verifikationssysteme prüfen nur, ob eine Attestierung existiert, nicht, ob ihre Quelle dem Maintainer entspricht, von dem das Paket kommen sollte. Die Signatur ist echt. Der Unterzeichner ist falsch. Genau hier muss Lieferkettenkontrolle von "war es signiert?" zu "wurde es von der Identität signiert, der ich vertraue, und ist diese Identität noch dasselbe Objekt wie letzten Monat?" wechseln.
Erwähnenswert: PyPIs Warehouse speichert bereits unveränderliche Identifikatoren, genau das, was Bloom für npm empfahl. Auch der GitLab-Pfad von npm Trusted Publishing hatte dieselbe Schwäche.
Was das für aratech-Kunden bedeutet
Die meisten Organisationen können keine Registry reparieren und werden npm nicht aufgeben. Sie können aber aufhören, die Ankunft von Paketen als unsichtbares Ereignis zu behandeln.
- Prüfe heute die Trusted-Publisher-Bindungen. Maintainer mit Veröffentlichungsrechten sollten
npm trust listausführen und bestätigen, dass jeder konfigurierte Slug noch auf ein Repository unter ihrer Kontrolle zeigt. Jede Bindung, die auf ein umbenanntes, übertragenes oder gelöschtes Repository zeigt, muss gelöscht und neu erstellt werden. - Behandle Repository-Hygiene als Sicherheitsarbeit. Eine Vertrauensbindung zu löschen, wenn ein Repository umbenannt, übertragen oder gelöscht wird, gehört als schriftlicher Schritt ins Runbook, nicht als gute Absicht.
- Setze ein Tor vor den Installationspfad. Eine Supply-Chain-Firewall, die entscheidet, was in die Umgebung gelangt, ist die Kontrolle, die wirklich skaliert, weil sie nicht davon abhängt, dass abends um sechs jemand einen Lockfile-Diff liest.
- Erweitere das Inventar über Pakete hinaus. Prüfe Erweiterungen, Plugins, MCP-Server, Skills und Anwendungen. Bloom fand dasselbe Muster im August in Open VSX und im VS Code Marketplace: 87 Extension-Packs im einen und 677 im anderen referenzierten Erweiterungen, die nicht existierten und frei beanspruchbar waren.
- Schreibe die Agenten-Richtlinie. Welche Agenten Software installieren dürfen, aus welchen Registries, mit welcher Freigabe und wie du es danach erfahren würdest.
Das Muster, das man sich merken sollte
Zwei Jahre KI-bezogener Sicherheitsmeldungen kreisen immer wieder um dieselbe Lektion, und SlugFest formuliert sie sauber: Die Bindung zwischen einem für Menschen lesbaren Namen und der Sache, die er identifiziert, ist die wichtigste Invariante jedes Vertrauenssystems. Brich sie mit einer routinemäßigen Umbenennung, und die Garantie kollabiert, lautlos, ohne Alarm und ohne einen einzigen fehlgeschlagenen Login.
Deine Agenten sind jetzt Infrastruktur. Sie installieren Code in Maschinengeschwindigkeit in Umgebungen, für die du verantwortlich bist. Der Name an der Tür ist kein Beweis mehr dafür, wer drinnen ist. Prüfe Identität, nicht Schreibweise, und tu es automatisch.