De GhostAction GitHub aanval is de afgelopen periode flink opgevoerd. Onderzoekers melden een scherpe piek waarin aanvallers zich richten op developer-omgevingen: ze nemen legitieme GitHub-accounts over en gebruiken die toegang om kwaadaardige automatisering in software-repositories te injecteren.
In hun analyse beschrijven onderzoekers dat de activiteit tussen 8 en 9 oktober 2026 is waargenomen. Daarbij ging het om compromissen van ongeveer 1.900 gebruikers en een aanvalsscope van meer dan 30.000 repositories. Het doel is niet “even malware draaien”, maar juist het stelen van geheimen die continu worden gebruikt voor bouwen, testen en deployen.
Wat is GhostAction precies?
GhostAction is een supply chain attack die inspeelt op de manier waarop teams hun software ontwikkelen en publiceren. Het gaat om een campagne die zich richt op developer infrastructure op GitHub: aanvallers compromitteren eerst accounts van maintainers en injecteren daarna malafide GitHub Actions-workflows in repositories.
De campagne werd oorspronkelijk ontdekt in september 2025. In grote lijnen werkt het als volgt:
- aanvallers krijgen toegang tot legitieme GitHub-accounts;
- met die rechten pushen ze een workflowbestand, vaak vermomd met misleidende namen;
- de workflow is ontworpen om in de CI/CD-omgeving geheimen op te halen en vervolgens te misbruiken.
Hoe krijgen aanvallers toegang tot GitHub?
Volgens de onderzoeksinformatie worden de GitHub-rechten verkregen via gestolen tokens of via credentials die zijn buitgemaakt uit logs/dumps van infostealers. Concreet worden Personal Access Tokens (PAT’s) genoemd waarmee aanvallers write-toegang tot repositories kunnen afdwingen.
Daarna nemen ze de rol van “beheerder/maintainer” praktisch over: ze kunnen immers direct wijzigingen doorvoeren, waaronder het toevoegen van nieuwe of aangepaste workflowbestanden. Door die vertrouwde positie kunnen de aanvallen in eerste instantie ongemerkt blijven.
Welke geheimen proberen ze te stelen?
De einddoelen draaien om het vergroten van de impact van CI/CD misbruik. Met de kwaadaardige workflows wordt geprobeerd op grote schaal geheimen te verzamelen, waaronder:
- CI/CD-secrets (zoals omgevingsvariabelen en deploymentparameters);
- cloudcredentials en tokens voor cloudtoegang;
- pakketregister-tokens, zoals voor npm, PyPI en DockerHub;
- API-sleutels voor AI-aanbieders.
Het concept is simpel maar effectief: wie de sleutels in de softwareleveringsketen bemachtigt, kan later productie-omgevingen beïnvloeden, afhankelijkheden manipuleren of data exfiltreren.
Misleidende workflows en het geheime “history”-scannen
In de beschreven campagne duiken workflowbestanden op met namen die lijken op veiligheidswerk of compliance. Voorbeelden die genoemd worden zijn namen als Security Audit (bijbehorend bestand: security-audit.yml) en GitHub Actions Security (bijbehorend bestand: github_actions_security.yml).
Wat de aanval extra interessant maakt, is dat onderzoekers ook varianten zien met secret-detectie door Git-geschiedenis te scannen. In eerdere varianten werden regex-patronen gebruikt die passen bij het herkennen van:
- AWS key IDs;
- GitHub en GitLab tokens;
- AI-gerelateerde geheimen;
- cloud API keys.
Bij een volgende versie wordt bovendien context meebediend: ongeveer twee regels rondom een gedetecteerde AWS key ID, zodat het geheim beter gekoppeld kan worden aan het bijbehorende secret access key. Een derde variant voegt nog extra ondersteuning toe om die context op te halen tijdens het scanproces.
Een golfaanval: fases, uitbreiding en vervolgens blokkades
De nieuwe golf binnen GhostAction lijkt in meerdere fases te zijn uitgerold. Onderzoekers beschrijven dat de payload eerst werd ingezet bij een beperkte groep van 160 eerder waargenomen slachtoffers. Kort daarna volgde een veel grotere uitrol: 20 minuten later werden 28.000 nieuwe repositories toegevoegd in de periode 8–9 oktober 2026.
Er werden ook nieuwe waves gemeld op 10 en 12 oktober. Tegelijk geeft de analyse aan dat GitHub vanaf 9 oktober is begonnen met het tegenhouden van het uitvoeren van de kwaadaardige workflow. Daardoor konden die latere waves in die fase naar verluidt geen extra secrets meer extraheren.
Waarom dit soort aanvallen “blijft plakken”
Een belangrijk detail uit de onderzoeksbevindingen: een subset van de slachtoffers uit de nieuwe piek was eerder al geraakt in september 2025 en augustus 2026. Dat wijst erop dat aanvallers rekenen op geheimen die niet zijn geroteerd na eerdere incidenten.
Met andere woorden: als teams eenmaal vermoeden dat er iets mis is geweest, is het niet genoeg om alleen de workflow te verwijderen. Geheimen moeten doorgaans actief worden vervangen en tooling/rollen moeten worden gecontroleerd op misbruik.
Wat kunt u nu doen tegen de GhostAction GitHub aanval?
Als u GitHub gebruikt voor ontwikkeling en CI/CD, is het verstandig om uw controles te verscherpen. Hieronder staan praktische stappen die aansluiten op het type aanval dat in de rapportage centraal staat.
1) Controleer workflowwijzigingen en verdachte namen
Let vooral op nieuwe of gewijzigde workflowbestanden in repositories. Vermommingen zoals “Security Audit” kunnen misleidend zijn. Zet daarom een proces op dat workflowwijzigingen snel beoordeelt, inclusief wie de wijzigingen heeft doorgevoerd.
2) Roteren van tokens en CI/CD-secrets
Omdat de campagne sterk leunt op het hergebruiken van niet-gewijzigde geheimen, is rotatie essentieel. Wanneer accounts of tokens in gevaar zijn geweest, vervang dan:
- PAT’s en andere persoonlijke tokens;
- CI/CD-secrets en omgevingsvariabelen;
- cloudcredentials en package registry tokens;
- API-sleutels voor externe diensten.
3) Beperk impact met least privilege
Probeer te voorkomen dat workflows brede rechten hebben. Werk met rollen en rechten die specifiek zijn voor het doel van een pipeline. Daarmee beperkt u de schade wanneer een workflow alsnog misbruikt wordt.
4) Gebruik gerichte detectie op CI/CD
Het “history scanning”-aspect laat zien dat aanvallen verder gaan dan alleen runtime. Breng daarom logging en detectie op orde rondom:
- workflow triggers;
- toegang tot secretbronnen;
- pogingen tot het uitlezen van relevante configuratiebestanden;
- afwijkingen in build- en deploypaden.
Wie dit koppelt aan incidentrespons (tijdig opschalen en bewijs verzamelen), staat sterker zodra er een verdachte golf wordt gedetecteerd.
Relatie met bredere beveiligingslessen
GhostAction past in een groter patroon: aanvallen die niet alleen software, maar ook de omgeving eromheen raken. Eerder zagen we bijvoorbeeld hoe organisaties mitigaties inzetten rondom platformkwetsbaarheden en supply chain-risico’s. Als u wilt verdiepen in het aanpakken van kwetsbaarheden in delivery en beveiliging van identiteiten, kan ook dit artikel relevant zijn: Bron: https://thehackernews.com/2026/10/ghostaction-compromises-about-1900.html
