GitHub heeft een belangrijke wijziging aangekondigd voor npm trusted publishing. Aanleiding is onderzoek waaruit bleek dat een aanvaller bepaalde trusted publishing configuraties kon misbruiken zonder iemands inloggegevens te hoeven stelen. In de praktijk draait het om een zwakke plek in de koppeling tussen een menselijk leesbare pakketreferentie (de slug) en de onderliggende repository.
Met de update probeert GitHub die trust slimmer te “verankeren”: de trusted publishing binding krijgt een korte validatietijd, waarna de configuratie pas definitief wordt nadat deze één keer succesvol is gebruikt.
Wat GitHub verandert aan trusted publishing
GitHub expireert de niet-gevalideerde npm trusted publishing configuraties. Dat gebeurt 48 uur nadat de configuratie is aangemaakt. De kern: GitHub wil voorkomen dat een nieuw aangemaakt vertrouwen lange tijd openstaat voor misbruik.
Het systeem wordt wel weer normaal zodra de configuratie zijn eerste succesvolle publish heeft doorlopen. Na die eerste keer wordt de instelling gevalideerd en vervalt de expiratietimer. Daarnaast benadrukt GitHub dat gewone aanpassingen niet automatisch zorgen dat de deadline opnieuw start.
Waarom de koppeling op een “slug” riskant kan zijn
Trusted publishing is bedoeld om credentialvrij te publiceren vanuit een CI/CD-platform. Daarbij gebruikt de CI/CD aanbieder korte, cryptografisch ondertekende tokens die via OpenID Connect (OIDC) worden gevalideerd door de npm-registry. Hierdoor hoef je minder met langdurige geheimen (secrets) te werken, wat het risico op lekken verlaagt.
Maar het onderzoek van Bloom Security liet zien dat npm vertrouwen koppelt aan de repository-identificatie op basis van de slug, de combinatie van eigenaar en repositorynaam in het formaat owner/repository. GitHub legt uit dat er tot een eerste succesvolle publish wordt uitgegaan van die slug-waarde, terwijl de permanente (numerieke) repository-identiteit pas later echt de basis kan worden.
Vergelijk het met een slot dat controleert op een adres/deurnaam, in plaats van op “wie” blijvend eigenaar is van het huis. Als een repositorynaam later vrijvalt of van eigenaar verandert, kan die vertrouwde koppeling theoretisch opnieuw terechtkomen bij een andere entiteit.
Hoe het misbruik volgens Bloom Security kan werken
Het aanvalsidee achter de campagne (door Bloom Security “SlugFest” genoemd) is niet afhankelijk van gestolen credentials of bijzondere insiderkennis. Het is vooral afhankelijk van het feit dat een slug beschikbaar kan komen te staan op een moment dat de trusted publisher nog niet is gebruikt.
Concreet beschrijft het onderzoek een reeks stappen:
- Een aanvaller claimt een repository op het “vrijgekomen” pad owner/repository, waardoor GitHub een nieuwe repository-ID uitvaardigt.
- Daarna zet de aanvaller een npm publish workflow op en triggert die, zodat een OIDC-token wordt gemint met zowel de gereclaimde slug als de nieuwe repository-ID.
- De token wordt ingediend bij het npm-uitwisselpunt; npm checkt daarbij of de repositoryclaim overeenkomt met wat eerder in de trusted publishing binding is opgeslagen.
- Als dat klopt, krijgt de aanvaller een tijdsgebonden publicatie-credentie en kan die kwaadaardige wijzigingen publiceren onder de officiële pakketnaam.
Het resultaat: de aanvaller kan een “malafide” versie publiceren die dezelfde reputatie, downloadstatistieken en afhankelijkheden gebruikt als het echte pakket. Dat kan op schaal doorwerken naar andere projecten in de software supply chain.
Waarom AI-agents het risico verder kunnen vergroten
Naast de technische aanval speelt ook het gedrag van moderne ontwikkelprocessen mee. Bloom Security wijst erop dat AI-agents op developer machines dependencies vaak autonoom oplossen en standaard geneigd zijn de nieuwste versie te pakken, zonder dat iemand expliciet checkt waar de package oorspronkelijk vandaan komt.
Als een gemanipuleerde versie via de misbruikte trusted publishing route wordt uitgerold, kan die daardoor sneller “mens-in-de-loop” passeren en automatisch worden opgehaald en uitgevoerd.
Hoe npm trusted publishing nu wordt afgedwongen
GitHub introduceert dus een beschermingsmechanisme rond die trusted publishing binding. Volgens de documentatie moet een nieuw aangemaakte trusted publisher configuratie binnen twee dagen voor het eerst succesvol publiceren. Alleen dan wordt de configuratie gevalideerd en wordt deze gebonden aan de immutable identity van de repository.
Verder staan er in de update ook aanvullende beperkingen rondom tokens en triggers. GitHub geeft aan dat npm voortaan trusted publishing tokens vanuit GitHub Actions issue_comment events weigert. Ook blijft de bestaande restrictie rondom pull_request_target van kracht.
Dat betekent: GitHub probeert niet alleen misbruik door timing te beperken, maar ook door minder “gevaarlijke” of minder voorspelbare eventbronnen uit te sluiten.
Wat developers en beheerders nu moeten doen
GitHub en Bloom Security benadrukken dat pakketbeheerders actief moeten controleren of de trusted publishing koppelingen nog kloppen met de huidige repository onder hun beheer.
Concreet worden de volgende acties aangeraden:
- Audit trusted publisher bindings en controleer of de opgeslagen repository slug nog verwijst naar jouw eigen repository.
- Als de repository is hernoemd of overgedragen: verwijder de bestaande trust binding en maak een nieuwe aan die wijst naar de actuele slug.
- Monitor onverwachte npm publish events, vooral wanneer er releases komen die niet door het team zijn gepland.
- Verwijder de trusted binding telkens wanneer een repository wordt verwijderd, overgedragen of hernoemd.
Bloom Security onderstreept bovendien dat de aanval geen raceconditie vereist en niet steunt op een credentiallek. Het draait om “slug availability” en hoe netjes je repositorybeheer is ingericht.
Praktische context: supply chain risico blijft een systeemvraag
Deze ontdekking past in een bredere trend: veel supply chain aanvallen draaien niet om één enkele kwetsbaarheid in code, maar om een zwakke invariant in vertrouwensmodellen. Als een systeem vertrouwen kan laten “verschuiven” door een relatief normale handeling (zoals hernoemen of overdragen), dan stort de garantie in zodra die koppeling stil kan worden vervangen.
Als je dit onderwerp verder wilt plaatsen in andere misbruikvormen rond pakket- of extensiebundels, is er op onze site ook aandacht voor vergelijkbare supply chain routes, zoals bij AI-worm en zelfreplicerende botnets: risico’s. Hoewel dat een ander type dreiging is, helpt het om te zien hoe snel schaal en automatisering de impact vergroten.
Conclusie: maak trusted publishing minder “permanent” en beter beheersbaar
GitHub zet met de expiratietimer en de eis van een eerste succesvolle publish een belangrijke stap om de trusted publishing binding in npm minder misbruikbaar te maken. De boodschap is helder: vertrouwen moet niet oneindig blijven hangen aan een verwijzing die kan veranderen, maar moet worden gevalideerd zodra het echt wordt gebruikt.
Voor teams betekent dit vooral werk in beheer: bindings controleren, hernoemingen en transfers opvolgen en verdachte publicaties serieus nemen. Daarmee verlaag je de kans dat een pakketnaam met “legitieme reputatie” in de verkeerde handen terechtkomt.
Wil je weten waar je op moet letten bij andere publicatie- of patchmomenten, dan zijn ook onze updates over incidenten en patching relevant, zoals GitHub tightening npm publishing after flaw left vulnerable packages. Zo houd je niet alleen de supply chain in de gaten, maar ook de bredere kwetsbaarheden die releases kunnen beïnvloeden.
Bron: https://thehackernews.com/2026/10/github-tightens-npm-publishing-after.html
1 reactie