GitHub neemt een belangrijke stap om de beveiliging van npm trusted publishing te verbeteren. Naar aanleiding van onderzoek is GitHub begonnen met het verstrengen van regels rond nieuwe trusted publishing configuraties, zodat misbruik via hergebruik van repository-identiteiten minder kans krijgt.
Concreet gaat het om een aanvalsvector waarbij een aanvaller een “vrijgevallen” repository-slug kan claimen en vervolgens—zonder geloofsgegevens te stelen—publishing-rechten kan afdwingen. Dit past in een bredere trend: supply chain aanvallen draaien vaak om de zwakke schakel tussen een menselijk label en het technische object dat het label representeert.
Wat is er precies aangepast aan npm trusted publishing?
GitHub expireert onbevestigde, niet-gevalideerde trusted publishing configuraties 48 uur na aanmaak. Het doel is om de periode te verkleinen waarin een configuratie “klaarstaat”, maar nog niet is vastgezet op een definitieve, gevalideerde identiteit.
Pas na de eerste succesvolle publish wordt de configuratie gevalideerd en krijgt die een uitzondering op de expiratie. Daarna geldt er een sleutelregel: het wijzigen van repository of project-identiteit vereist een nieuw vertrouwensrelatie met een nieuwe validatietermijn van twee dagen. Gewone aanpassingen binnen hetzelfde kader herstarten die deadline niet.
Validatie bindt trusted publisher aan een immutable identiteit
In de documentatie licht GitHub toe dat een nieuwe trusted publisher configuration binnen twee dagen zijn eerste succesvolle publish moet afronden. Daarmee valideert GitHub de configuratie en koppelt die aan de immutable identity van de repository—met andere woorden: de veilige verankering verschuift naar iets dat niet zomaar “meeverandert” door naamwijzigingen.
Waarom was dit nodig? De kern van de kwetsbaarheid
Onderzoekers van Bloom Security vonden een loophole in npm trusted publishing die te maken heeft met hoe een repository wordt geïdentificeerd. In plaats van te vertrouwen op een permanent en onveranderlijk ID, kijkt npm (totdat de eerste versie is gepubliceerd) sterk naar een repository-slug—de combinatie van owner/organization en repositorynaam in de vorm “owner/repository”.
Het probleem is dat die slug wel verandert of kan “vrijkomen” wanneer een repository wordt hernoemd, overgedragen of verwijderd. Vergelijk het met een slot dat controleert of een adres op de deur klopt, en niet wie er werkelijk eigenaar is van het huis. Wanneer het eigendom verandert, kan de juiste sleutel in verkeerde handen belanden.
Hoe werkt de aanval in grote lijnen (SlugFest)?
De aanval die Bloom Security beschrijft heet SlugFest. Het scenario draait om het herclaimen van een slug die nog niet eerder is gebruikt om een package-versie te publiceren in npm onder die trust binding.
In hoofdlijnen verloopt het misbruik volgens dit idee:
- De aanvaller creëert een repository op een “vrijgevallen” slug in het pad “owner/repository”, waardoor GitHub een nieuwe repository-ID uitreikt.
- Vervolgens start de aanvaller een npm publish workflow, waarmee een OIDC-token wordt gemunt dat de herveroverde slug en de nieuwe numerieke repository-ID bevat.
- Met dat token probeert de aanvaller de token-uitwisseling bij npm te doen. npm ziet dat de repository-claim overeenkomt met wat eerder in de trusted publishing binding is vastgelegd en verstrekt een publish-credential.
- Daarna kan de aanvaller een kwaadaardige packageversie pushen onder een legitieme pakketnaam—terwijl reputatie, downloadgeschiedenis en afhankelijkheden gewoon doorlopen.
Waarom is dit extra gevaarlijk met AI-agents?
De risico’s blijven niet beperkt tot een klassieke handmatige workflow. Bloom Security wijst erop dat AI-agents die op ontwikkelaarsmachines draaien dependencies vaak automatisch afhandelen. Daarbij kiezen ze doorgaans de nieuwste versie en verifiëren ze zelden expliciet herkomst en herleidbaarheid.
Als er via SlugFest een schadelijke versie in npm terechtkomt, kan zo’n release daardoor sneller en breder worden opgepakt—zonder menselijke controle in de lus.
Wat bleek er in de praktijk? Aantal getroffen packages
Bloom Security rapporteerde dat zij meer dan 1.500 kwetsbare packages hebben gevonden. Die packages zijn gezamenlijk meer dan 10 miljoen keer gedownload. Dat onderstreept hoe schaalbaar dit type supply chain misbruik kan zijn: één foute verankering kan een groot ecosysteem raken.
Advies voor npm maintainer: zo verklein je het risico
GitHub en de onderzoekers leggen de nadruk op onderhoudshygiëne. Als maintainer kun je meerdere stappen nemen om te voorkomen dat een trusted publishing binding naar een slug verwijst die niet (meer) onder jouw controle valt.
Concreet wordt aangeraden om:
- Trusted publisher bindings te auditen en te controleren of de vermelde repository-slug nog steeds naar jouw repository verwijst.
- Als een repository is hernoemd of overgedragen: de bestaande trust binding te verwijderen en opnieuw op te zetten met de huidige slug.
- Te monitoren op onverwachte npm publish-events.
- Trusted bindings te verwijderen wanneer een repository wordt verwijderd, overgedragen of hernoemd.
De onderzoekers benadrukken daarbij dat deze aanval niet per se afhankelijk is van insiders of credential theft. Het draait vooral om beschikbaarheid van de slug en de manier waarop de binding is ingericht.
Relatie met bredere supply chain security lessen
Dit incident past in een bekend patroon binnen supply chain attacks: de “binding” tussen wat mensen zien (een naam, pad of label) en wat systemen technisch gebruiken (een onderliggend ID of bron) is vaak het punt waar het misgaat. Zodra die koppeling stil en voorspelbaar kan verschuiven, valt de veronderstelling achter vertrouwen in het systeem weg.
Als je meer wilt lezen over hoe moderne aanvallen afhankelijk zijn van het misbruik van vertrouwen en integraties, dan is dit mogelijk ook relevant: AI-orkestratie bij CyberXero en WordPress. Niet hetzelfde onderwerp, wel dezelfde mechaniek van ketenrisico en automatisering.
Praktisch: wat betekent dit voor jouw CI/CD en releases?
Voor teams die npm packages publiceren via CI/CD—bijvoorbeeld met GitHub Actions—betekent dit update vooral dat “new trusted publisher” configuraties strakker binnen een kort tijdvenster hun eerste publish moeten afronden. Wacht je langer, dan neemt de kans af dat de configuratie blijft werken zoals voorheen.
Daarnaast is het verstandig om je releaseproces te koppelen aan een periodieke controle van repository-identiteit. Denk daarbij aan:
- Review van naming en ownership wijzigingen in GitHub.
- Inventaris van trusted publisher bindings per package.
- Logging en alerting rond publish-events.
Zo beperk je de kans dat een toekomstige verandering in je repositories onbedoeld een slug beschikbaar maakt die misbruikt kan worden.
Conclusie
GitHub scherpt npm trusted publishing aan om een kwetsbaarheid te mitigeren die draait om repository-slugs en het tijdstip waarop een trusted configuration wordt gevalideerd. Door onbevestigde configuraties na 48 uur te laten verlopen en trusted publishers te binden aan een “immutable identity”, verkleint GitHub de aanvalsradius van SlugFest-achtige scenario’s.
Voor maintainer- en releaseteams ligt de sleutel vervolgens bij onderhoud: auditen van bindings, tijdig opnieuw instellen na hernoemen of overdragen, en alert zijn op onverwachte publish-events. Daarmee maak je de supply chain net iets weerbaarder tegen aanvallen die leunen op kleine maar cruciale identiteitsverschillen.
Bron: https://thehackernews.com/2026/10/github-tightens-npm-publishing-after.html
