GitHub lässt ungeprüfte Bindungen nach 48 Stunden verfallen

GitHub hat das Trusted Publishing für die JavaScript-Paketregistry npm abgesichert. Neu angelegte Konfigurationen verfallen nun 48 Stunden nach ihrer Erstellung, wenn darüber bis dahin keine Paketversion veröffentlicht wurde. Hintergrund ist eine Schwachstelle, über die Angreifer neue Versionen fremder Pakete veröffentlichen konnten, ohne Zugangsdaten zu stehlen. Entdeckt hat sie das Sicherheitsunternehmen Bloom Security. Die Forscher nennen den Angriff SlugFest.

Vertrauen am Namen statt an der ID

Trusted Publishing gibt es bei npm seit Juli 2025. Entwickler können damit Pakete aus CI/CD-Plattformen wie GitHub Actions veröffentlichen, ohne dauerhafte Zugangsdaten zu hinterlegen. Die Plattform erzeugt für jeden Workflow-Lauf ein kurzlebiges Token nach dem Standard OpenID Connect (OIDC), das npm mit einer vorab hinterlegten Konfiguration abgleicht.

Laut Bloom Security speicherte npm dabei bis zur ersten Veröffentlichung nur den sogenannten Slug eines Repositorys, also die Kombination aus Besitzer und Repository-Name, nicht aber die dauerhafte numerische ID, die GitHub vergibt. Benannte ein Maintainer ein Repository um, übertrug oder löschte es, konnte ein Angreifer unter dem frei gewordenen Namen ein neues Repository anlegen. Mit einem Workflow aus diesem Repository erhielt er ein Token, das npm akzeptierte, und konnte eine schädliche Version unter dem echten Paketnamen veröffentlichen. Voraussetzung war, dass über die Konfiguration noch keine Version veröffentlicht worden war.

„Für den Angriff sind weder Insiderwissen noch der Diebstahl von Zugangsdaten noch eine Race Condition nötig.”
Golan Myers, Sicherheitsforscher von Bloom Security

Die Forscher fanden mehr als 1.500 verwundbare Pakete, die zusammen über 10 Millionen Mal heruntergeladen wurden. Ob die Lücke ausgenutzt wurde, ist nicht bekannt.

Risiko durch KI-Agenten

Bloom Security warnt besonders vor der Kombination mit KI-Agenten auf Entwicklerrechnern. Diese lösten Abhängigkeiten selbstständig auf, griffen meist zur neuesten Version und prüften selten die Herkunft eines Pakets. Eine schädliche Version könne so ohne menschliche Prüfung ausgeführt werden.

Bindung an die Repository-ID

Nach der Änderung wird eine Konfiguration mit der ersten erfolgreichen Veröffentlichung an die unveränderliche ID des Repositorys gebunden und verfällt dann nicht mehr. Wird das Repository oder die Projektidentität geändert, ist eine neue Vertrauensbeziehung mit einem neuen 48-Stunden-Fenster nötig. Zudem lehnt npm Tokens aus GitHub-Actions-Ereignissen vom Typ issue_comment ab.

Maintainer sollten prüfen, ob die in ihren Trusted-Publisher-Konfigurationen hinterlegten Repositorys noch unter ihrer Kontrolle stehen. Nach Umbenennungen, Übertragungen oder dem Löschen eines Repositorys sollten sie bestehende Bindungen löschen und neu anlegen sowie auf unerwartete Veröffentlichungen achten. Im August hatte Bloom Security bereits eine ähnliche Lücke in den Marktplätzen für Erweiterungen von VS Code und Open VSX gemeldet.

(red)