GitHub bringt eine 2FA-Schranke vor die Veröffentlichung jedes npm-Pakets. Selbst wer einen gültigen CI-Token erbeutet hat, kommt nicht mehr daran vorbei. Das könnte die Welle der TeamPCP-artigen Supply-Chain-Hacks ausbremsen.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügenWann haben Sie zuletzt geprüft, wer in Ihrer CI/CD-Pipeline tatsächlich auf den npm-Publish-Button drücken kann? Die neue npm Staged Publishing zwingt ab sofort jeden Veröffentlichungsschritt durch eine zweite Tür, die ein Mensch mit 2FA aufmachen muss.
Das Wichtigste in Kürze
- GitHub aktiviert npm Staged Publishing als allgemein verfügbares Feature ab 22. Mai 2026
- Jedes Paket landet zuerst in einer Stage-Queue und benötigt 2FA-Freigabe durch einen Maintainer
- Drei neue Install-Flags (–allow-file, –allow-remote, –allow-directory) regeln Drittquellen
- Voraussetzung: npm CLI 11.15.0 oder neuer und aktiviertes 2FA
Wie funktioniert die neue Stage-Queue?
Bisher reichte ein npm publish, um ein Paket sofort im Registry-Index sichtbar zu machen. Das hat Angreifer mit gestohlenen CI-Tokens jahrelang freigespielt, zuletzt sichtbar bei der TeamPCP-Welle und beim Mini-Shai-Hulud-Wurm. Mit npm stage publish wandert das vorgebaute Tarball ab sofort in eine Stage-Queue. Erst nach einer 2FA-Bestätigung durch einen menschlichen Maintainer rutscht das Paket in den öffentlichen Index. GitHub nennt das „Proof of Presence“.
Wer Trusted Publishing über OpenID Connect (OIDC) nutzt, kann die Stage-Pflicht erzwingen. Eine Konfiguration als „stage-only“ lehnt direkte npm publish-Aufrufe aus CI-Workflows komplett ab. Damit fällt der wichtigste Angriffsweg weg, den die jüngsten Lieferketten-Würmer ausgenutzt haben.
Drei Install-Flags gegen Drittquellen
Parallel führt GitHub neue Install-Flags ein, die das Allowlist-Prinzip auf alle Nicht-Registry-Quellen ausdehnen. --allow-file kontrolliert lokale Pfade und Tarballs, --allow-remote regelt URL-Installationen, --allow-directory erlaubt lokale Verzeichnisse. Bisher gab es nur --allow-git. Damit lässt sich pro Build präzise festlegen, welche Quellen überhaupt akzeptiert werden, statt alles standardmäßig zuzulassen.
Staged Publishing schließt das größte offene Tor in der npm-Lieferkette. Wer das nicht aktiviert, sollte sich nicht über den nächsten Vorfall in seinen Abhängigkeiten wundern.
— Michael Dobler, Herausgeber Dr. Web
Was DACH-Entwicklungsteams jetzt umstellen sollten
Die Umstellung betrifft jeden, der Pakete im eigenen Namen oder über einen CI-Workflow veröffentlicht. Auf der Voraussetzungsseite stehen npm CLI 11.15.0 und ein zweiter Faktor pro Maintainer. Praktisch heißt das: alle Publish-Workflows von npm publish auf npm stage publish umstellen, Trusted Publishing über OIDC einrichten und stage-only erzwingen. Wer das nicht tut, schließt die Tür für Angreifer nicht, sondern lässt sie weiter offenstehen.
Der Schritt fällt in eine Phase, in der Lieferketten-Angriffe Rekorde brechen. JFrog meldet im Jahresreport eine Steigerung um 451 Prozent, GitHub selbst verlor im Mai über 3.800 interne Repositories an die TeamPCP-Gruppe. Wer zusätzlich seine Plugin-Liste in Ordnung halten will, sollte parallel den WordPress-Plugin-CVE vom Mai patchen und sich beim WordPress Hosting Vergleich 2026 orientieren, wenn das eigene Hosting beim Patchmanagement nicht mitzieht.
Mehr Newshunger?
