„Ihre Konfiguration wird nach der ersten erfolgreichen Veröffentlichung validiert und vom Verfall ausgenommen", erklärte die zu Microsoft gehörende Tochter. „Eine Änderung der Repository- oder Projektidentität erfordert eine neue Vertrauensbeziehung mit einem frischen 48-Stunden-Validierungsfenster – gewöhnliche Bearbeitungen setzen die Frist nicht neu." In der aktualisierten Dokumentation hält GitHub fest, dass eine neu erstellte Trusted-Publisher-Konfiguration ihre erste erfolgreiche Veröffentlichung binnen zwei Tagen abschließen muss; damit wird sie validiert und an die „unveränderliche Identität des Repositorys" gebunden.
Nach Darstellung von GitHub begrenzt die Änderung das Risiko, das entsteht, wenn einem Repository- oder Projektnamen vertraut wird, der den Besitzer wechselt. Zusätzlich weist npm künftig Trusted-Publishing-Token ab, die aus GitHub-Actions-Ereignissen vom Typ issue_comment stammen – ergänzend zur bereits bestehenden Einschränkung für pull_request_target.
Trusted Publishing wurde im Juli 2025 bei npm als Authentifizierungsverfahren ohne Zugangsdaten eingeführt. Entwickler können damit npm-Pakete direkt aus einer CI/CD-Plattform wie GitHub Actions veröffentlichen, wobei OpenID-Connect-Token (OIDC) zum Einsatz kommen. Ist Trusted Publishing eingerichtet, erzeugt der CI/CD-Anbieter für einen bestimmten Workflow-Lauf ein kurzlebiges kryptografisches Token, das die npm-Registry gegen eine vorab autorisierte Konfiguration prüft. Das erspart das Speichern, Rotieren und manuelle Verwalten langlebiger npm-Geheimnisse und senkt so das Risiko, dass Zugangsdaten abfließen. Zudem werden automatisch Provenance-Attestierungen für npm-Pakete erzeugt, mit denen sich nachvollziehen lässt, wo ein Paket gebaut und von wem es veröffentlicht wurde.
Genau an der Frage, wie das Repository identifiziert wird, setzte die von Bloom Security gefundene Schwachstelle an. Maßgeblich war der sogenannte Slug – die Kombination aus Eigentümer beziehungsweise Organisation und Repository-Name in der Form „owner/repository". „Es wird die Adresse des Repositorys festgehalten […] statt der permanenten ID, die GitHub ihm zuweist – zumindest bis aus diesem Repository erstmals eine Version veröffentlicht wurde", erläuterte Sicherheitsforscher Golan Myers. „Das ist wie ein Schloss, das die Adresse an der Tür prüft statt den Eigentümer des Hauses: Wenn der Eigentümer auszieht, bekommt derjenige den Schlüssel, der einzieht."
Die numerischen IDs, die Umbenennungen und Übertragungen eines Repositorys überdauern, werden zwar in den OIDC-Token von GitHub mitgeführt, von npm aber bis zur ersten erfolgreichen Veröffentlichung vollständig ignoriert. Das Vertrauen hing damit an einem Namen statt an einer unveränderlichen Repository-ID – ein Schlupfloch, das sich durch das Beanspruchen aufgegebener Slugs ausnutzen ließ, um deren Vertrauensstellung zu erben. Voraussetzung für einen erfolgreichen Angriff war lediglich, dass der Trusted Publisher des Opfers auf einen GitHub-Slug zeigte, den ein Angreifer registrieren konnte, und dass aus diesem Repository noch nie eine Paketversion auf npm veröffentlicht worden war.
Wird ein solcher Slug frei, weil ein Maintainer sein Repository umbenennt, überträgt oder löscht, konnte ein Angreifer folgendermaßen vorgehen:
- Ein Repository unter dem freigewordenen Pfad „owner/repository" anlegen, woraufhin GitHub eine neue Repository-ID vergibt.
- Einen npm-Publish-Workflow anlegen und auslösen, der ein OIDC-Token mit dem zurückerlangten Slug und der neuen numerischen Repository-ID ausstellt.
- Das Token am npm-Exchange-Endpunkt einreichen. npm stellt fest, dass die Repository-Angabe zum gespeicherten Slug passt, und gibt ein Veröffentlichungs-Credential aus.
- Mit dem zeitlich begrenzten Publish-Token lassen sich schädliche Änderungen für ein fremdes Paket in die Registry hochladen.
Der auf den Namen SlugFest getaufte Angriff erlaubt es, eine neue, bösartige Version eines fremden Pakets unter dessen legitimem Namen zu veröffentlichen – samt der bestehenden Reputation, der Download-Zahlen und der Abhängigkeitsbeziehungen. Daraus können Lieferkettenangriffe in großem Maßstab entstehen; Bloom Security verweist dabei auf eine kaskadierende Supply-Chain-Attacke nach dem Muster von Shai-Hulud. Die Erkenntnisse wurden GitHub am 6. Juni 2026 gemeldet.
Verschärft wird die Lage durch KI-Agenten auf Entwicklerrechnern. „Agenten lösen Abhängigkeiten selbstständig auf, nehmen tendenziell die neueste Version und prüfen selten, woher ein Paket stammt", so Bloom Security. „Eine über einen zurückerlangten Slug veröffentlichte bösartige Version wird eingezogen und ausgeführt, ohne dass ein Mensch eingreift." Myers skizzierte das Szenario so: „Stellen Sie sich vor: Ein Angreifer kompromittiert ein einzelnes Paket. Ein KI-Agent auf dem Gerät eines Maintainers eines populären Pakets zieht es eigenständig für ein Projekt. Dieser eine Endpunkt wird genutzt, um Schadcode in das populäre Paket zu schieben. Alle Nutzer des Pakets sind exponiert. Und das nur, weil eine Person mit den richtigen Zugriffsrechten exponiert war."
Maintainern von npm-Paketen wird empfohlen:
- Die Trusted-Publisher-Bindungen prüfen und verifizieren, ob der eingetragene Repository-Slug noch auf ein Repository unter eigener Kontrolle verweist.
- Wurde das Repository umbenannt oder übertragen, die bestehende Vertrauensbindung löschen und neu auf den aktuellen Slug ausrichten.
- Auf unerwartete npm-Publish-Ereignisse achten.
- Vertrauensbindungen jedes Mal löschen, wenn ein Repository gelöscht, übertragen oder umbenannt wird.
„Der Angriff erfordert kein Insiderwissen, keinen Diebstahl von Zugangsdaten und keine Race Condition", sagte Myers. „Die einzige Vorbedingung ist die Verfügbarkeit des Slugs – bei einer Bindung, über die noch nie veröffentlicht wurde –, und die hängt vollständig von der Repository-Hygiene des Opfers ab." Die Untersuchung zeige etwas, das in Lieferkettenangriffen immer wieder zu beobachten sei: „Die Bindung zwischen einem menschenlesbaren Bezeichner und dem, was er bezeichnet, ist die wichtigste Invariante in jedem Vertrauenssystem. Wenn diese Bindung stillschweigend ersetzt werden kann – durch den gewöhnlichen Vorgang des Umbenennens eines Repositorys, nicht durch eine Handlung eines Angreifers –, bricht die Vertrauensgarantie zusammen."
Bloom Security hatte bereits zuvor einen ähnlich gelagerten Angriffsweg beschrieben: Im August fand das Unternehmen heraus, dass sowohl Open VSX als auch der VS Code Marketplace von Microsoft es zuließen, dass Extension Packs auf gar nicht existierende Erweiterungen verweisen. Die als Extension Resurrection bezeichnete Technik erlaubt es, in vertrauenswürdigen Bündeln referenzierte Erweiterungen zu kapern, indem ein nicht beanspruchter Namensraum registriert wird. Als anfällig eingestuft wurden damals 87 Packs in Open VSX und 677 Packs im VS Code Marketplace. „Angreifer könnten diese leeren Plätze beanspruchen, Schadcode darunter veröffentlichen und ihn automatisch zusammen mit dem vertrauenswürdigen Pack installieren lassen – und damit still und leise Updates an alle ausliefern, die das Pack zuvor installiert haben", sagte Myers seinerzeit. „Da Erweiterungen mit vollem Host-Zugriff laufen, läuft das effektiv auf Remote Code Execution im Gewand der Legitimität hinaus."