npm trusted publishing lässt ungeprüfte Setups jetzt ablaufen
npm trusted publishing wurde verschärft, nachdem Bloom Security eine Lücke gefunden hatte, durch die ein Angreifer eine neue Version des npm Package einer anderen Person veröffentlichen konnte, ohne die Zugangsdaten des Maintainers zu stehlen.
GitHub, dem npm gehört, hat geändert, wie ungeprüfte trusted publishing-Konfigurationen behandelt werden. Eine neu erstellte trusted publisher-Konfiguration hat nun 48 Stunden Zeit, ihre erste erfolgreiche Package-Veröffentlichung abzuschließen. Nach dieser ersten erfolgreichen Veröffentlichung ist die Konfiguration validiert und vom Ablauf ausgenommen. GitHub sagt, dass eine Änderung der Repository- oder Projektidentität eine neue Vertrauensbeziehung erzeugt und ein neues 48-Stunden-Validierungsfenster startet, während normale Bearbeitungen die Frist nicht neu starten.
Die Änderung zielt auf eine bestimmte Schwäche dabei ab, wie Vertrauen zunächst an einen GitHub-Repository-Namen gebunden wurde. Trusted publishing, im Juli 2025 für npm eingeführt, ist eine zugangsdatenfreie Methode, npm packages von einer Plattform für continuous integration und continuous delivery zu veröffentlichen, oft zu CI/CD abgekürzt, wie etwa GitHub Actions. CI/CD bedeutet automatisierte Systeme, die Software bauen, testen und veröffentlichen. Statt ein langlebiges npm Secret zu speichern, erstellt der CI/CD-Anbieter ein kurzlebiges OpenID Connect token, oft OIDC token genannt, für einen bestimmten workflow run. npm prüft dieses Token dann gegen eine vorab genehmigte Publishing-Konfiguration.
Dieses Design reduziert die Notwendigkeit für Maintainer, npm-Zugangsdaten zu speichern und zu rotieren, wodurch das Risiko sinkt, dass ein geleaktes Secret zur Veröffentlichung schädlicher Packages verwendet werden kann. Es erstellt außerdem provenance attestations für npm packages, also Aufzeichnungen, die zeigen helfen, wo ein Package gebaut wurde und wer es veröffentlicht hat. Die von Bloom Security gemeldete Schwäche lag nicht in der allgemeinen Idee von token-basiertem Publishing, sondern in der frühen Vertrauensbindung zwischen npm und dem GitHub-Repository.
Bloom Security meldete seine Erkenntnisse am 6. Juni 2026 an GitHub. Das Unternehmen sagte, npm habe zunächst die menschenlesbare Repository-Adresse, auch slug genannt, in der Form owner/repository erfasst. Laut der Untersuchung verließ sich npm bis zur ersten erfolgreichen Veröffentlichung aus diesem Repository nicht auf die permanente numerische Repository-ID von GitHub. GitHubs OIDC tokens enthalten numerische IDs, die Repository-Umbenennungen und -Übertragungen überdauern, aber Bloom Security stellte fest, dass npm diese IDs vor der ersten erfolgreichen Veröffentlichung ignorierte.
Das schuf eine Lücke, wenn eine trusted publisher-Konfiguration auf einen Repository-slug verwies, der später verfügbar wurde. Bloom Security nannte den Angriff SlugFest. Damit der Angriff funktioniert, musste der trusted publisher des Opfers auf einen GitHub-slug zeigen, den ein Angreifer beanspruchen konnte, und dieses Repository durfte noch nicht verwendet worden sein, um eine Version des Package auf npm zu veröffentlichen. Der slug konnte verfügbar werden, nachdem ein Maintainer ein Repository umbenannt, übertragen oder gelöscht hatte.
Der von Bloom Security beschriebene Angriffsweg ist direkt. Ein Angreifer erstellt ein Repository unter dem freigewordenen Pfad owner/repository. GitHub weist diesem neuen Repository eine eigene numerische ID zu. Der Angreifer erstellt und startet dann einen npm-Publishing-workflow, der ein OIDC token erzeugt, das den zurückgewonnenen slug und die neue Repository-ID enthält. Wenn dieses Token an den Exchange-Endpunkt von npm gesendet wird, sieht npm den Repository-Claim, der zum gespeicherten slug passt, und stellt eine zeitlich begrenzte Berechtigung zum Veröffentlichen aus. Der Angreifer kann dann eine neue Version eines Package veröffentlichen, das ihm nicht gehört.
Die Auswirkung ist gravierend, weil die schädliche Version unter dem legitimen Package-Namen erscheinen würde. Sie würde von der bestehenden Reputation des Package, seiner Download-Historie und seinen Beziehungen zu Projekten profitieren, die davon abhängen. Bloom Security sagte, es habe mehr als 1.500 verwundbare Packages gefunden, mit zusammen mehr als 10 Millionen Downloads. In supply chain security ist das relevant, weil ein kompromittiertes Package automatisch in viele nachgelagerte Projekte gezogen werden kann.
Bloom Security warnte außerdem, dass AI agents, die auf Entwicklerrechnern laufen, das Risiko erhöhen können. Das Unternehmen sagte, agents könnten dependencies selbst auflösen, oft die neueste Version wählen und möglicherweise nicht prüfen, woher ein Package stammt. In dieser Situation könnte eine schädliche Version, die über einen zurückgewonnenen Repository-slug veröffentlicht wurde, installiert und ausgeführt werden, ohne dass eine Person die Entscheidung vorher überprüft.
GitHubs Reaktion fügt eine Ablaufzeit für neue trusted publishing-Konfigurationen hinzu, die noch nicht durch eine erfolgreiche Veröffentlichung validiert wurden. GitHub sagt außerdem, dass npm jetzt trusted publishing tokens aus GitHub Actions issue_comment events ablehnt. Diese Einschränkung kommt zu einer bestehenden Einschränkung für pull_request_target events hinzu. Beide event-Typen sind wichtig, weil Publishing tokens nur aus workflows akzeptiert werden sollten, denen npm für Release-Aktivitäten vertrauen kann.
Für Maintainer lautet die praktische Botschaft, zu prüfen, ob ihre npm trusted publisher-Bindungen noch auf Repositories zeigen, die sie kontrollieren. Bloom Security rät Entwicklern, trusted publisher-Bindungen zu auditieren, zu bestätigen, dass der aufgeführte slug noch auf ihr eigenes Repository auflöst, die Bindung zu löschen und neu zu erstellen, wenn ein Repository umbenannt oder übertragen wurde, auf unerwartete npm publish events zu achten und Trust-Bindungen zu entfernen, wann immer ein Repository gelöscht, übertragen oder umbenannt wird.
Dies ist nicht das einzige supply chain-Problem, das Bloom Security rund um vertrauenswürdige Namen und nicht beanspruchte Bereiche gemeldet hat. Bereits im August sagte das Unternehmen, Open VSX und Microsofts VS Code Marketplace erlaubten extension packs, auf extensions zu verweisen, die in den Marketplaces nicht existierten. Bloom Security nannte diese Technik Extension Resurrection und sagte, 87 packs in Open VSX und 677 packs im VS Code Marketplace seien verwundbar. In diesem Szenario könnte ein Angreifer einen leeren extension-Slot beanspruchen und Code zusammen mit einem vertrauenswürdigen pack installieren lassen. Das Unternehmen merkte an, dass extensions mit vollem Host-Zugriff laufen, was daraus einen Weg zu remote code execution unter einem vertrauenswürdig aussehenden Installationspfad macht.
Für Website-Betreiber und Unternehmen ist das npm-Problem eine Erinnerung daran, dass moderne Websites oft von Software-Packages abhängen, die außerhalb der Organisation gepflegt werden. Eine kleine dependency, die in einer build pipeline verwendet wird, kann eine öffentliche Website, ein Admin-Panel oder ein internes Tool beeinträchtigen, wenn schädlicher Code in die Release-Kette gelangt. AEU-I bietet security-first IT, Infrastruktur und Beratung, was für Teams relevant ist, die überprüfen, wie ihre Software-, Hosting- und Betriebsprozesse mit Risiken durch Drittanbieter-dependencies umgehen.
Die zentrale Lehre ist eng gefasst, aber wichtig: Eine Vertrauenseinstellung, die auf einem veränderbaren Namen basiert, kann unsicher werden, wenn dieser Name später wiederverwendet wird. GitHubs neuer 48-Stunden-Ablauf für ungeprüfte npm trusted publishing-Konfigurationen verkleinert das Zeitfenster für genau diese Bedingung, aber Maintainer müssen alte Bindungen weiterhin bereinigen, wenn Repositories umbenannt, verschoben oder gelöscht werden.