Een nieuwe supply chain-aanval laat zien hoe hardnekkig credential-stealing via GitHub Actions kan zijn. Onderzoekers beschrijven een campagne waarbij aanvallers via gecompromitteerde maintainer-accounts misbruik maken van CI/CD-automatisering om gevoelige data te verzamelen. Vervolgens exfiltreren ze die secrets naar een aanvaller-gestuurde bestemming.
Het gaat niet om een theoretisch scenario: de onderzoekers noemen een workflow die in honderden tot duizenden repositories is geplaatst, en die is ontworpen om credentials te oogsten uit zowel GitHub secrets als uit de git-historie. Met andere woorden: zelfs wanneer ontwikkelaars iets later verwijderen, kan de aanval het alsnog terugvinden.
Wat er is ontdekt over de campagne
Volgens de onderzoekers is de aanval uitgevoerd door een actor die zich toegang verschaft tot maintainer-accounts. Met die identiteit kon de aanvaller een kwaadaardige workflow pushen naar meerdere repositories. In de beschrijving staan twee opvallende gevallen: één account werd gebruikt om het script naar een eerste reeks repositories te sturen, waarna acht uur later een tweede account dezelfde aanpak toepaste op een veel grotere set.
Per 9 oktober 2026 rapporteerden onderzoekers dat er inmiddels meer dan 500 GitHub-accounts zijn geïdentificeerd die de malafide workflow hebben toegevoegd aan (tienduizenden) repositories sinds 7 oktober 2026. De activiteit werd toegeschreven aan GhostAction, een campagne die eerder in 2025 werd gesignaleerd.
De ‘security audit’-workflow als vermomming
De kern van de aanval draait om een workflowfile die zich voordoet als iets onschuldigs, zoals een security audit. In de berichtgeving komen twee namen terug: een workflow die “Security Audit” lijkt te heten (met een bestand zoals security-audit.yml) en een variant zoals “GitHub Actions Security” (met onder andere github_actions_security.yml).
De workflow is bedoeld om gevoelige data te verzamelen en vervolgens te versturen. Daarbij wordt de exfiltratie gekoppeld aan een hard-coded IP-adres dat via plain HTTP wordt benaderd. Dat is extra problematisch: het verkeer is niet versleuteld, waardoor het eenvoudiger te analyseren is voor de aanvaller en lastiger te ontkennen is achteraf.
Welke data wordt gestolen?
De workflow verzamelt niet één soort credential, maar richt zich op meerdere bronnen. Eerst gebruikt de aanval de reeds aanwezige GitHub Actions secrets. Daarnaast kijkt de workflow naar de werkruimte (de bestanden die op dat moment beschikbaar zijn), en vervolgens naar de volledige git-geschiedenis.
Onderzoekers beschrijven dat de workflow een checklist van 13 credential-patronen hanteert. Die patronen dekken categorieën zoals:
- AWS-access key IDs en bijbehorende secret access keys
- credentials voor AI-diensten (inclusief API-sleutels voor aanbieders)
- tokens voor broncode- en CI/dienstverleners
- SaaS- en cloud-API sleutels
Een belangrijk detail is dat de workflow niet alleen controleert wat er “nu” staat, maar ook wat ooit in commits is terechtgekomen. Dat gebeurt door Git met een fetch-depth: 0 te check-outen, zodat de volledige geschiedenis beschikbaar komt voor scanning.
Hoe verloopt de aanval stap voor stap?
De onderzoekers geven een duidelijke keten van wat de aanvaller doet. Kort samengevat:
- Accounttoegang: de aanvaller bemachtigt de GitHub-credentials van een maintainer. Dat kan vermoedelijk via een gelekte persoonlijke access token (PAT) of cred dumps/infostealers.
- Reconnaissance: de workflow controleert repositoriestructuur en zoekt naar relevante secrets.
- Injectie: de aanvaller plaatst de kwaadaardige workflow in de default branch onder de identiteit van het slachtoffer.
- Extractie en verzending: de workflow leest secrets, scant de werkruimte en historie, en verstuurt de gevonden gegevens naar de aanvaller via een endpoint (bijvoorbeeld met curl).
Daarnaast noemt de analyse twee triggers: de workflow start op workflow_dispatch én op een push die niet wordt beperkt (dus “any branch” en “any tag”). Daardoor kan het misbruik zich herhalen bij nieuwe commits of tags.
Waarom het ook forks en downstream raakt
Veel teams denken bij GitHub-repositories nog steeds vooral aan de upstream project owner. Maar bij Actions is de context complexer: forks en downstream varianten kunnen meeliften. In de berichtgeving worden forks expliciet genoemd als route naar extra impact.
Als de workflow eenmaal in een upstream repository staat, kunnen forks met Actions ingeschakeld de malafide workflow overnemen. Bovendien is er een extra risico bij private forks en downstream mirrors: daar kunnen juist de meest waardevolle credentials in commits of werkruimte aanwezig zijn.
Verder rapporteerden onderzoekers dat runs een repository-identificatie opleveren, ook wanneer er geen credentials worden gevonden. Daarmee kan de actor een kaart maken van bereikbare execution contexts, los van het slagen van het credential-theft deel.
Welke impact is er eerder en later gezien?
Naast de recente golf rapporteren onderzoekers dat GitGuardian eerder een vergelijkbare uitrol beschreef in een eerdere periode. In die rapportage werd melding gemaakt van inzet op honderden public repositories en honderden GitHub gebruikers/organisaties, met een aanzienlijk aantal gestolen secrets als resultaat.
De huidige analyse noemt daarnaast dat er miljoenen aan potentiële schade niet alleen met tokens te maken heeft, maar ook met bredere categorieën zoals SSH private keys, Azure credentials, container registry-verificaties (zoals DockerHub en GHCR), database credentials, FTP-gegevens en diverse service- of provider-sleutels.
Ook cryptomining als neveneffect
In één waargenomen geval (rond eind augustus 2026) zouden aanvallers een repository hebben aangepast zodat er een cryptocurrency miner (XMRig) werd ingebed in een Docker image. Daarbij benadrukken onderzoekers dat er op het moment van schrijven geen aanwijzingen waren dat er kwaadaardige package releases verschenen via gecompromitteerde publishing credentials.
Dit onderstreept vooral dat één gecompromitteerde pipeline meerdere doelen kan dienen: van datadiefstal tot runtime misbruik in build-artifacts.
Wat moeten ontwikkelaars en teams nu doen?
De onderzoekers adviseren teams om hun repositories actief te controleren op de genoemde workflownamen en bestandspaden. Daarbij is “assume compromise” een belangrijke insteek: als de malafide workflow aanwezig is, moet je ervan uitgaan dat de omgeving is misbruikt.
Concreet worden de volgende acties aangeraden:
- Revokeren: trek de gecompromitteerde GitHub credential(s) direct in.
- Rotaten: vervang en rote alle betrokken credentials en secrets.
- Opschonen: verwijder de kwaadaardige workflow van alle branches.
- Scope check: controleer ook forks en downstream repositories die de workflow kunnen hebben overgenomen.
Omdat de workflow ook git-historie scant, is het verstandig om niet alleen te kijken naar wat er in de huidige stand van de repo staat. Juist het verwijderen van strings is niet per definitie voldoende als ze eerder in commits zijn beland.
Praktische tips om dit soort aanvallen te bemoeilijken
Naast de incidentrespons is preventie minstens zo belangrijk. Hoewel de exacte implementatie per team verschilt, kun je met een paar basisprincipes de kans op credential-stealing via GitHub Actions verkleinen:
- Beperk wie workflows kan aanpassen en controleer wijzigingen in default branches intensiever.
- Minimaliseer secrets: gebruik waar mogelijk minder brede tokens en reduceer de hoeveelheid credentials die beschikbaar zijn tijdens CI.
- Stuur op snelle detectie: let op ongebruikelijke workflow triggers, onverwachte endpoints en scripts die naar externe IP’s sturen.
- Volg supply chain hygiene: beperk afhankelijkheid van acties of scripts die je niet expliciet vertrouwt.
Wil je meer achtergrond over het waarom achter supply chain-aanvallen en het tempo waarmee aanvallers automatisering inzetten? Dan kan ook dit artikel helpen: AI velocity paradox: waarom security achterloopt.
Extra aandacht voor tokens en ‘audit’ automation
Veel teams vertrouwen op “audit”-automatisering omdat het lijkt op het controleren van compliance. Deze campagne laat zien dat dezelfde mechanismen ook als exfiltratiekanaal kunnen fungeren. Het is dus zinvol om niet alleen de content van workflow-bestanden te reviewen, maar ook te letten op:
- bestandsnamen en workflow-id’s die passen bij security scans, maar ongebruikelijk exfiltratiegedrag vertonen
- HTTP-verkeer naar vaste IP’s of endpoints
- scans die verder gaan dan de werkruimte (zoals het volledig ophalen van git-historie)
Werk je met open source en maintainer-accounts? Dan is het extra verstandig om ook de beheerpraktijken rondom toegang en tokenbeheer te verscherpen. Een bredere kijk op aanvallen op supply chain en credentie-infrastructuur lees je mogelijk ook in ARTEX AI pentesting bij datadiefstal: FBI-waarschuwing, al gaat dat artikel over een ander invalshoek.
Conclusie
De beschreven campagne toont dat credential-stealing via GitHub Actions niet draait om één kwetsbaarheid, maar om misbruik van bestaande automatisering. Door een “Security Audit”-workflow te injecteren onder het account van een maintainer, konden aanvallers in korte tijd data verzamelen uit secrets, werkruimte en zelfs volledige git-historie.
Als je team GitHub Actions gebruikt, neem deze signalen serieus: controleer op de specifieke workflowbestanden, behandel een vondst als een incident en voer rotatie uit van alle mogelijk getroffen credentials. Daarmee beperk je niet alleen directe diefstal, maar ook de kans dat forks en downstream kopieën de aanval opnieuw activeren.
Bron: https://thehackernews.com/2026/10/credential-stealing-github-actions.html
