SlugFest traf 1.500 npm-Pakete – alte Bindungen müssen geprüft werden

Der SlugFest-Bericht von Bloom Security vom 13. Oktober 2026 identifiziert mehr als 1.500 potenziell angreifbare npm-Pakete mit insgesamt über zehn Millionen Downloads; Autor Golan Myers fasst den Fehler mit „A name is not an identity“ zusammen. Gemeint sind Pakete, deren noch unbestätigte Trusted-Publishing-Bindung unter bestimmten Bedingungen eine fremde Veröffentlichung zugelassen hätte. Die Zahl bezeichnet mögliche Angriffsziele, keine bestätigten Paketübernahmen.

Der CSO-Bericht nennt den 2. Oktober 2026 als Datum des npm-Fixes: Unbestätigte neue Bindungen laufen nach 48 Stunden ab. Außerhalb des kontrollierten Versuchs der Forscher war laut dem Bericht keine Ausnutzung beobachtet worden. Für Maintainer bleibt die Kontrolle bestehender Zuordnungen wichtig, besonders nach einer Umbenennung, Übertragung oder Löschung des verbundenen Repositories.

Wie ein freier GitHub-Pfad Veröffentlichungsrechte erhielt

Trusted Publishing verbindet ein npm-Paket mit einem festgelegten CI-Workflow. Bei GitHub Actions fordert dieser Workflow ein kurzlebiges OIDC-Token von GitHub an und tauscht es bei npm gegen eine Veröffentlichungsberechtigung. Die Konfiguration bezeichnet das GitHub-Konto oder die Organisation, das Repository und den Namen der Workflow-Datei; eine GitHub-Umgebung kann zusätzlich festgelegt werden. So kann ein Release ohne dauerhaft hinterlegtes npm-Veröffentlichungstoken erfolgen.

Der Fehler lag in der Zeit zwischen dem Anlegen dieser Verbindung und ihrer ersten erfolgreichen Veröffentlichung. npm kannte zunächst den lesbaren Repository-Pfad aus Eigentümer und Namen, hatte die Verbindung aber noch nicht an die dauerhafte numerische Identität des Repositories gebunden. Wurde das ursprünglich gemeinte Repository umbenannt, übertragen oder gelöscht, konnte sein alter Pfad frei werden. Ein anderes Repository unter diesem Pfad konnte mit einer passend benannten Workflow-Datei ein OIDC-Token vorlegen und die noch unbestätigte Bindung erfüllen.

Im kontrollierten Versuch veröffentlichten die Forscher eine neue Version eines eigenen npm-Pakets aus einem zweiten, ebenfalls von ihnen kontrollierten GitHub-Repository. Dessen numerische Identität unterschied sich von der des ursprünglichen Repositories; gemeinsam war beiden nur der nacheinander verwendete Pfad. Der Versuch erforderte weder Zugang zum npm-Konto noch GitHub-Zugangsdaten des ursprünglichen Maintainers. Nach einer erfolgreichen Veröffentlichung wird die Bindung dagegen mit der dauerhaften Repository-Identität bestätigt.

Was die ermittelte Reichweite über betroffene Pakete sagt

Die Untersuchung suchte nach Paketen mit Trusted-Publishing-Konfigurationen, deren eingetragene Repository-Pfade beansprucht werden konnten. Eine öffentliche Liste dieser Pakete wurde nicht veröffentlicht. Maintainer können daher allein aus dem Fehlen einer Warnung für ihren Paketnamen nicht schließen, dass ihre Zuordnung stimmt. Maßgeblich ist, ob der eingetragene Pfad heute tatsächlich zum vorgesehenen Repository führt und ob die Verbindung bereits durch eine Veröffentlichung bestätigt wurde.

Die Downloadzahl beschreibt die bisherige Nutzung der untersuchten Pakete, nicht die Verbreitung manipulierter Versionen. Das mögliche Schadensbild erklärt dennoch die Bedeutung des Fehlers: Wer eine Veröffentlichung unter einem bestehenden Paketnamen auslösen kann, erreicht Projekte, die diesen Namen bereits als Abhängigkeit verwenden. Auch eine Herkunftsbestätigung müsste dann auf das erwartete Repository geprüft werden; die bloße Existenz einer Bestätigung würde die Verwechslung des Repository-Pfads nicht auflösen.

Was der npm-Fix am Zeitfenster ändert

Die npm-Dokumentation zu Trusted Publishing verlangt für eine neu angelegte Bindung die erste erfolgreiche Veröffentlichung innerhalb von zwei Tagen. Diese Veröffentlichung bestätigt die Konfiguration und verknüpft sie mit der unveränderlichen Repository-Identität. Erfolgt sie nicht rechtzeitig, läuft die Bindung ab und kann keine Veröffentlichung mehr autorisieren; für einen späteren Release muss sie gelöscht und neu angelegt werden.

Die Frist verkürzt damit die Phase, in der ein noch unbestätigter Repository-Name über die Veröffentlichungsberechtigung entscheidet. Die dokumentierte Regel spricht ausdrücklich von neu angelegten Konfigurationen; aus ihr folgt keine pauschale Entwarnung für ältere Einträge. Bestehende Verbindungen lassen sich in den Paketeinstellungen entfernen, ihre festgelegten Angaben jedoch nicht nachträglich ändern. Bei einem Repository-Wechsel ist deshalb eine neue, zum aktuellen Pfad passende Bindung erforderlich.

Bestehende Bindungen und Release-Workflows kontrollieren

Die Prüfung sollte beim einzelnen Paket beginnen und der Berechtigung bis zum auslösenden Workflow folgen. Dabei sind die npm-Zuordnung und der Schutz des GitHub-Workflows getrennte Fragen: Ein korrektes Repository kann einen zu weit geöffneten Release-Ablauf haben, während ein gut geschützter Workflow keinen veralteten Repository-Pfad berichtigt.

1. Mit npm trust list die Trusted-Publishing-Bindungen des Pakets anzeigen. Den eingetragenen GitHub-Pfad mit dem heute kontrollierten Repository und den Workflow-Dateinamen mit dem tatsächlich verwendeten Release-Workflow abgleichen.
2. Nach einer Umbenennung, Übertragung oder Löschung prüfen, ob eine alte Bindung noch vorhanden ist. Wird sie nicht mehr gebraucht, entfernen; andernfalls eine Verbindung zum aktuellen Repository anlegen und durch eine erste reguläre Veröffentlichung bestätigen.
3. Für den Release-Job die GitHub-Umgebung und ihre Freigaben prüfen. Erlaubte Branches oder Tags, der Schutz des Release-Branches und Änderungsrechte an der Workflow-Datei bestimmen mit, wer eine Veröffentlichung auslösen kann.
4. Die Rechte der npm-Bindung kontrollieren: Darf der Workflow direkt mit npm publish veröffentlichen oder nur mit npm stage publish eine gestufte Veröffentlichung vorbereiten? Bei der gestuften Variante wird die Version erst nach gesonderter Freigabe durch einen Maintainer mit Zwei-Faktor-Authentifizierung öffentlich.

Gerade bei länger bestehenden Konfigurationen lohnt der Blick auf die tatsächlich erlaubten Aktionen. Eine Bindung kann weiterhin direkte Veröffentlichungen gestatten, obwohl für den heutigen Ablauf eine Freigabe vor der Veröffentlichung vorgesehen ist. Umgekehrt würde eine Umstellung auf gestufte Veröffentlichung den Repository-Pfad nicht korrigieren: Vor dem nächsten Release muss klar sein, welchem Repository npm vertraut und welcher Workflow diese Berechtigung ausüben darf.

Lesen Sie auch:

• HelmGuard erhält 7,3 Millionen Dollar – Compliance soll laufend geprüft werden
• Qualcomm kauft PickNik – MoveIt soll trotz engerer Bindung offen bleiben
• Microsoft schließt 974 Lücken – zwei Zero-Days werden bereits ausgenutzt