Een aanvaller heeft toegang tot meer dan 60.000 GitHub-repositories getest en in duizenden projecten code geplaatst die gericht is op het stelen van credentials. Meerdere securitybedrijven beschrijven hoe de operatie via bestaande GitHub-onderdelen werkt, zonder een specifieke kwetsbaarheid in GitHub zelf te misbruiken.
Het resultaat: organisaties moeten uitgaan van het scenario dat toegankelijke tokens en andere geheimen zijn gecompromitteerd, zeker wanneer malware daadwerkelijk kon draaien in CI- of workflow-context. Hieronder lees je wat er is waargenomen en welke acties je prioriteit geven.
Wat er volgens beveiligingsbedrijven is gebeurd
De campagne kreeg de naam wfx-loot. Volgens Aikido Security startte de operatie op 10 november. Het bedrijf stelde vast dat er ongeveer 4.800 gecompromitteerde accounts achter “probe pull requests” zaten, gericht op 61.764 repositories.
StepSecurity legt uit dat zo’n pull request op zichzelf niet alles doet. De aanval wordt volgens hen pas relevant zodra malware vervolgens wordt ingezet in repositories waar de permissies en configuratie het toestaan.
Er zijn daarnaast aanwijzingen dat de stealer in meer dan 1.800 repositories draaide, terwijl SafeDep apart telde dat 8.093 publieke repositories updates ontvingen met kwaadaardige commits. Dat laatste betekent niet automatisch dat de code ook succesvol is uitgevoerd.
Geen GitHub Actions-bug: de aanpak leunt op geldige tokens
Een belangrijk detail: de aanvaller zou geen bug in GitHub Actions exploiteren. In plaats daarvan werkt hij met legitieme tokens die al aanwezig zijn bij developer- of botaccounts. Daarmee kan de operatie zich voordoen als “normale” CI/CD-activiteit, waardoor de aanval minder opvalt dan een klassieke exploit.
Securitybedrijven merken ook op dat de aanvaller wijzigingen vaak weer terugdraait en workflow-runs verwijdert. Dat maakt het lastiger om achteraf de volledige impact goed in kaart te brengen.
Waar de malware terechtkomt: workflows, shell scripts en npm-hooks
De malware werd geplaatst in bestaande of nieuw aangemaakte GitHub Actions workflows. Daarnaast kan de code belanden in shell scripts die door CI-systemen worden uitgevoerd, en in npm-install hooks.
Die npm-route is extra relevant voor ontwikkelaars: als kwaadaardige wijzigingen al aanwezig zijn in de dependency, kunnen slachtoffers die dependencies installeren de aanval onbedoeld faciliteren.
Concreet beschrijft de bron dat de scriptfunctie onder meer zoekt naar:
- GitHub-tokens
- repository secrets
- cloud credentials
- sleutels voor AI-diensten
Verder wordt genoemd dat de aanvaller process memory van GitHub Actions runners probeert te lezen. Er zit ook functionaliteit in die bedoeld is om de toegang uit te breiden en persistente controle op te zetten in AWS en Azure.
Hoe bewijs kan lijken op succes, maar het kan toch missen
Omdat pull requests en commits op zichzelf niet altijd leiden tot uitvoering, kan de aanwezigheid van “malicious changes” niet hetzelfde betekenen als “daadwerkelijke compromise”.
De bron maakt dat onderscheid expliciet: SafeDep telde publieke repositories die kwaadaardige commits ontvingen, maar dat hoeft niet te betekenen dat de code overal ook echt heeft kunnen draaien. Toegang, permissies en configuraties bepalen uiteindelijk of de reverse shells via GitHub-concepten en credential theft daadwerkelijk effect hebben gehad.
Getraceerde probe pull requests en onbeantwoorde herkomst
StepSecurity traceerde 173 probe pull requests naar tokens die waren uitgegeven aan de Fly.io GitHub app. Het bedrijf kon volgens de bron niet vaststellen hoe die tokens precies zijn verkregen en ziet geen aanwijzingen dat de infrastructuur van Fly.io zelf is geraakt.
Dat maakt de kern van het probleem groter: zelfs zonder directe compromis van een platform als GitHub, kunnen aanvallers via gestolen tokens toch workflow- en supply-chain paden bewandelen.
Welke software-impact er werd genoemd
Volgens de bron gaat het ook om getroffen releases. Er worden namelijk een Packagist-pakket en versies van twee Go-modules genoemd als onderdeel van de verspreiding.
Dat wijst op een breder supply chain risico: naast repository-specifieke workflows kan de aanval ook via pakketecosystemen slachtoffers raken die afhankelijk zijn van externe dependencies.
Wat je nu kunt doen (praktische checklist)
Securitybedrijven adviseren organisaties om te handelen alsof alle beschikbare geheimen (tokens, secrets, credentials) gecompromitteerd zijn wanneer de malware daadwerkelijk heeft kunnen uitvoeren.
Concreet kun je de volgende stappen prioriteren:
- Revokeren: trek verdachte tokens direct in.
- Roteren: roteer alle secrets die mogelijk zijn blootgesteld (repository secrets, cloud keys, AI-service sleutels).
- Controleren: kijk naar ongeautoriseerde wijzigingen in cloud-omgevingen (AWS/Azure) en naar afwijkende activiteiten in CI/CD.
- Reviseren: beoordeel workflows, shell scripts en dependency hooks op onverwachte code-inserts.
Wil je breder begrijpen hoe “token misbruik” en supply chain aanvalspaden werken? Lees dan ook het artikel over GitHub CI secret stealer via gehackte accounts, dat aansluit op het thema van credential diefstal via CI processen.
Vergelijkbare campagnes en waarom context telt
De bron meldt dat er overeenkomsten zijn met de GhostAction-campagne uit oktober, maar dat beveiligers waarschijnlijk verschillende actoren inschatten. Dat betekent dat je niet op één “vermoedelijke dader” kunt rekenen—het belangrijkste is dat de technische patronen (workflow-inserts, token-gebaseerde toegang, verwijderen van sporen) terugkerend kunnen zijn.
Ook bij andere AI- en cloudincidenten blijkt dat een compromis vaak niet direct zichtbaar is als je alleen naar code kijkt. Daarom is het relevant om incidenten in samenhang te bekijken, zoals in de Notion-zaak na de Fireworks AI hack.
Conclusie
De beschreven operatie laat zien hoe reverse shells via GitHub en credential theft vooral effectief kunnen zijn zonder exploits in het platform zelf: gestolen tokens en slimme plaatsing in workflows, scripts en npm-hooks vormen de kern.
Neem daarom snel maatregelen: revokeren, secrets roteren en controleren op ongeautoriseerde cloudwijzigingen en afwijkende CI/CD-activiteiten. Alleen zo verklein je de kans dat aanvallers met geldige toegang verder kunnen opschalen.
