npm härtet Trusted Publishing gegen SlugFest

Bloom Security hat am 13. Oktober 2026 einen Übernahmepfad für npm-Pakete offengelegt, deren Trusted-Publishing-Verknüpfung noch nie für eine Veröffentlichung genutzt wurde. Die als SlugFest bezeichnete Forschung erklärt, warum ein wiederverwendbarer Repositoryname keine dauerhaft sichere Identität ist. GitHub hatte die zugehörige Härtung bereits am 2. Oktober angekündigt: Unvalidierte Vertrauenskonfigurationen laufen jetzt nach 48 Stunden ab.

Package-Maintainer sollten heute ihre Trusted Publisher mit den aktuell kontrollierten Repositories abgleichen. Besonders wichtig ist das nach Umbenennungen, Übertragungen oder Löschungen. Reine Paketkonsumenten müssen nicht selbst Publisher-Konfigurationen reparieren, sollten aber unerwartete neue Versionen und deren Herkunft prüfen. Eine massenhafte Ausnutzung oder eine Liste tatsächlich kompromittierter Pakete belegen die vorliegenden Quellen nicht.

Was zeigt die neue Forschung?

Trusted Publishing ersetzt langlebige npm-Geheimnisse in CI-Pipelines durch kurzlebige OpenID-Connect-Tokens. Die Registry prüft eine zuvor konfigurierte Beziehung zu einem Workflow und stellt danach ein Veröffentlichungsrecht aus. Im untersuchten Ablauf wurde zunächst der lesbare Pfad aus Eigentümer und Repositoryname gespeichert. Die unveränderliche Repository-ID wurde erst nach der ersten erfolgreichen Veröffentlichung gebunden.

Wurde dieser Pfad vorher frei, konnte ein anderer Betreiber dort ein neues Repository anlegen. Dessen OIDC-Token enthielt zwar eine andere numerische ID, aber den gleichen erwarteten Namen. Laut Bloom reichte diese Übereinstimmung zusammen mit dem passenden Workflow-Dateinamen aus, um ein Veröffentlichungsrecht für das fremde Paket zu erhalten. Der Versuch gelang mit eigenen npm-Paketen und kontrollierten GitHub-Repositories verschiedener Organisationen.

Welche Konfigurationen sind relevant?

Die Voraussetzung war eine noch nicht durch einen Publish validierte Bindung an einen beanspruchbaren Repositorypfad. Ein bereits erfolgreich genutzter Publisher ist nach der dokumentierten Logik an die unveränderliche Identität gebunden. Die Forschung beschreibt damit keinen allgemeinen Bruch von OIDC und keinen notwendigen Diebstahl von npm-Passwörtern. Auch eine GitHub-Kontoübernahme war für den demonstrierten Pfad nicht erforderlich.

1. Besonders prüfen müssen Maintainer mit vorbereiteten, aber noch nie verwendeten Trusted-Publishing-Verknüpfungen.
2. Repository-Umbenennungen, Eigentümerwechsel und Löschungen sollten einen erneuten Abgleich der Paket-Vertrauensbeziehungen auslösen.
3. Auch ein verschwundener oder umbenannter Eigentümeraccount kann die Zuordnung eines lesbaren Pfades verändern.
4. Bloom nennt mehr als 1.500 exponierte Pakete und insgesamt mehr als zehn Millionen Downloads; diese Zahlen sind Angaben der Forscher, keine von GitHub bestätigte Opferstatistik.

Was hat npm geändert?

Nach dem offiziellen GitHub-Changelog verliert eine unvalidierte Konfiguration 48 Stunden nach ihrer Erstellung die Berechtigung zum Veröffentlichen. Die erste erfolgreiche Veröffentlichung validiert sie und nimmt sie von diesem Ablauf aus. Eine Änderung der Repository- oder Projektidentität erfordert eine neue Vertrauensbeziehung mit neuer Frist. Gewöhnliche Bearbeitungen setzen die laufende Frist dagegen nicht zurück.

Abgelaufene Einträge bleiben in den Einstellungen sichtbar, zählen aber nicht zu den Limits je Paket. Andere gültige Konfigurationen sind nicht betroffen. Für eine abgelaufene Bindung ist eine Neuerstellung vorgesehen. Zusätzlich lehnt npm Trusted-Publishing-Tokens aus GitHub-Actions-Ereignissen des Typs issue_comment ab, neben der bestehenden Einschränkung für pull_request_target. GitHub nennt push, release und workflow_dispatch als mögliche zulässige Alternativen.

Die Änderung begrenzt das Zeitfenster vor der ersten Validierung, statt die unveränderliche Identität bereits beim Anlegen zu speichern. Bloom bevorzugt diese frühere Bindung als technische Lösung. Im Artikel ist deshalb zwischen dem tatsächlich eingeführten Ablauf und dem weitergehenden Vorschlag der Forscher zu unterscheiden. Die Härtung ist kein neues Update vom 13. Oktober; neu ist die datierte technische Offenlegung.

Was sollten Release-Verantwortliche heute tun?

1. Zuerst pro npm-Paket die Trusted-Publisher-Einstellungen erfassen und den hinterlegten Eigentümer, Repositorynamen und Workflow mit der tatsächlich freigegebenen Release-Pipeline vergleichen.
2. Unbenutzte oder auf alte Pfade zeigende Bindungen entfernen, bevor ein Repository gelöscht, übertragen oder umbenannt wird.
3. Nach einer Identitätsänderung die Vertrauensbeziehung kontrolliert neu anlegen; bloßes Bearbeiten eines alten Eintrags nicht als Fristverlängerung behandeln.
4. Den ersten vorgesehenen Publish innerhalb von 48 Stunden durchführen und die erfolgreiche Validierung anschließend in den Einstellungen kontrollieren.
5. Workflows auf issue_comment und pull_request_target prüfen und Veröffentlichungen auf geeignete erlaubte Ereignisse umstellen.
6. Unerwartete npm-Veröffentlichungen anhand von Version, Zeitpunkt, Workflow und Provenance untersuchen; bei Abweichungen betroffene Versionen vor weiterer Verteilung sperren.

Eine gültige Herkunftsbescheinigung allein beantwortet noch nicht, ob das erwartete Repository veröffentlicht hat. Teams sollten deshalb die bescheinigte Quelle mit ihrem freigegebenen Build-Ursprung vergleichen. Für kleine Unternehmen bleibt Trusted Publishing sinnvoll, weil es langlebige CI-Geheimnisse reduziert. Voraussetzung ist ein geregelter Prozess für Repositorywechsel und die Verantwortung für jedes veröffentlichte Paket.

Passende Anleitungen und Quellen

Passende Anleitungen auf S-EDV

1. Renovate für kontrollierte Dependency-Updates: unterstützt überprüfbare Änderungsvorschläge, ersetzt aber keine Prüfung der Publisher-Identität.
2. Git-Repositories mit Gitleaks kontrollieren: ergänzt die Absicherung bestehender Geheimnisse; gegen den hier beschriebenen Angriff ohne Credential-Diebstahl reicht Secret-Scanning allein nicht.

Quellen

1. Bloom Security: SlugFest, veröffentlicht am 13. Oktober: Reproduktion, Voraussetzungen, Reichweitenangaben und Abgrenzung des Fixes.
2. GitHub-Changelog vom 2. Oktober: verbindliche 48-Stunden-Frist und Einschränkung von Workflow-Ereignissen.
3. The Hacker News vom 13. Oktober: ergänzender Bericht zur Forschung und den Maßnahmen für Maintainer.