Er duiken opnieuw signalen op rond gecompromitteerde GitHub Actions. Twee Actions die eerder waren getroffen in een campagne (Mini Shai-Hulud, mei 2026) lagen opnieuw stil, maar kwamen op 16 september 2026 weer toegankelijk. Het gevolg: workflows die die Actions aanroepen via een versie-tag konden opnieuw kwaadaardige code binnenhalen en uitvoeren.
Wat dit extra zorgwekkend maakt, is dat de dreiging niet per se vereiste dat aanvallers later nog nieuwe infrastructuur of exploits inzetten. De kwetsbaarheid zat in de “mutable” verwijzing: als je workflow op een tag leunt die later weer naar gecompromitteerde content wijst, werkt het kwaad weer door.
Wat er precies gebeurde met de GitHub Actions
De betrokken Actions waren eerder gecompromitteerd en vervolgens opnieuw uitgeschakeld door GitHub. Toen ontwikkelaars later naar de repositories keken, zagen ze de melding dat toegang is geblokkeerd wegens schending van GitHub’s voorwaarden. Op 16 september 2026 werden beide repositories weer bereikbaar.
Onderzoekers gaven aan dat de release tags niet waren “schoongemaakt”. Die tags verwezen nog altijd naar de kwaadaardige content die op 18 mei 2026 was ingebracht. Daardoor konden workflows die die Actions via een versie-tag aanroepen bij een volgende run weer payloads downloaden en uitvoeren.
Hoe misbruik werd gemaakt in CI/CD
De oorspronkelijke aanval was gericht op de CI/CD-keten. De aangetaste GitHub Actions voerden kwaadaardige code uit die gevoelige credentials uit CI/CD-pijplijnen oogstte. Vervolgens werden die gegevens geëxfiltreerd naar een server die door de aanvaller werd beheerd.
Daarnaast werd de activiteit gekoppeld aan dezelfde Mini Shai-Hulud-cluster. Daarbij wees men op overlap in onderdelen zoals het exfiltratie-domein dat in de Actions-workflows werd gebruikt en verbanden met npm-pakketten uit het @antv-ecosysteem. De kern blijft echter: niet alleen de aanvaller, maar vooral de manier van verwijzen naar upstream content bepaalde het uiteindelijke risico.
Waarom dit anders is dan een “nieuw” incident
Veel supply chain-incidenten ontstaan doordat er iets nieuws wordt gepubliceerd: een nieuwe malafide versie, een opnieuw gekaapte account of een workflowwijziging die pas later wordt doorgevoerd. In dit geval lag het anders.
De kwaadwillende code bleef in de betreffende codebases aanwezig. Nadat de repositories weer downloadbaar werden, was het voldoende dat bestaande workflows opnieuw de acties via hun tags aanhaalden. Er was dus geen grote nieuwe operatie van de aanvaller nodig—reactivering volstond.
Er zijn bovendien aanwijzingen dat getroffen repositories in de praktijk binnen korte tijd opnieuw gevaar konden lopen, omdat de workflows vaak dagelijks draaien of bij events zoals het openen van een issue of pull request.
Welke workflows lopen risico?
De risico’s zitten vooral bij situaties waarin je workflow de Actions aanroept met een versie-tag, zoals “actions-cool/issues-helper@v2.2.1” (volgens de analyse van Socket). Als zo’n tag bij opnieuw toegankelijk worden nog steeds naar gecompromitteerde content verwijst, wordt de payload opnieuw opgehaald.
Daarentegen geldt er een belangrijk nuancepunt: het incident heeft geen impact op workflows die de Actions vastpinnen naar een full commit SHA van vóór 18 mei 2026. SHA-pinning vermindert afhankelijkheid van wat er upstream “nu” staat.
Actieplan: zo beperk je blootstelling
Als je GitHub Actions gebruikt die mogelijk uit dezelfde bron komen, is het verstandig om snel en gestructureerd te handelen. Onderzoekers adviseren in elk geval de volgende stappen.
- Vind alle verwijzingen naar de getroffen Actions en behandel “actions-cool/issues-helper@v2.2.1” als verdacht als je die tegenkomt.
- Verwijder de acties of vervang ze door een variant die je vastpint op een bekende schone commit SHA die dateert van vóór 18 mei 2026.
- Rotating secrets: vervang alle credentials die mogelijk zijn blootgesteld.
- Check workflow run history op langdurige job failures en kijk naar nieuwe successen na die periode.
- Audit repositorygeschiedenis op onverwachte commits na 16 september 2026.
Het doel is om twee dingen te herstellen: (1) voorkomen dat je CI/CD opnieuw malafide content binnenhaalt, en (2) uitsluiten dat gestolen gegevens later nog misbruikt worden.
Praktische lessen voor software supply chain security
Deze casus onderstreept een patroon dat je vaak terugziet bij supply chain-aanvallen: de beveiliging van je pipeline hangt niet alleen af van je eigen code, maar ook van de manier waarop je upstream componenten integreert.
Mutable tags zijn een risicofactor
Tags kunnen veranderen nadat ze zijn aangemaakt, zeker als upstream repositories opnieuw worden geactiveerd of gecorrigeerd zonder tags netjes te herschrijven. Door afhankelijk te zijn van tags geef je upstream feitelijk controle over welke code je vandaag draait, ook al heeft jouw workflowbestand inhoudelijk geen wijziging gekregen.
Pin naar commit SHA om voorspelbaarheid te herstellen
SHA-pin is geen “magische” oplossing, maar het maakt je builds aanzienlijk consistenter. Je workflow verwijst dan naar exact één commit, waardoor een reactivering van een upstream repository niet zomaar doorwerkt.
Bekijk niet alleen code, maar ook gedrag
Tot slot is het waardevol om je aandacht te verbreden van “is er code toegevoegd?” naar “wat is er gedraaid?”. Als je bijvoorbeeld ziet dat er plots weer succesvolle workflow-runs zijn na een lange periode van problemen, kan dat een signaal zijn dat een upstream component weer geactiveerd is.
Vergelijkbare aandachtspunten in recente security cases
Als je dit bredere thema interessant vindt, kun je ook kijken naar signalen rond ketenrisico’s en incidentreactie. Zo schreef IT Waarschuwing eerder over hoe aanvallen of compromissen in de softwareketen doorwerken naar resultaten in CI/CD en productieprocessen, bijvoorbeeld in analyses rond gecompromitteerde issue-mail en de impact op CI-actie. Ook relevant is de bredere blik op hoe aanvallers in het algemeen interne mechanismen misbruiken, zoals bij stateful SOC en AI in incidentafhandeling—handig om beter te leren van patronen die zich herhalen.
Conclusie
De terugkeer van gecompromitteerde GitHub Actions laat zien hoe snel supply chain-risico’s kunnen opleven, zelfs wanneer jouw workflow-bestand ongewijzigd blijft. Zodra versie-tags opnieuw naar kwaadaardige content wijzen, kan je CI/CD automatisch opnieuw in de fout gaan.
Pak daarom de kern aan: inventariseer je Action-verwijzingen, pin kritieke dependencies op een bekende schone commit SHA, roteer alle mogelijke secrets en controleer je workflow-historie. Zo voorkom je dat een tijdelijke blokkade slechts een korte pauze was in plaats van een echte oplossing.
Bron: https://thehackernews.com/2026/09/compromised-github-actions-came-back.html
