GhostAction revine: conturi de mentenanți compromise distribuie workflow-uri GitHub Actions care fură credențiale

O campanie de tip supply chain care folosește GitHub Actions pentru a fura secrete a reapărut și se răspândește mai repede decât înainte. Cercetătorii arată că atacatorii au preluat conturile GitHub ale unor mentenanți open-source de încredere și le-au folosit pentru a adăuga un workflow fals de „securitate” în sute de repository-uri, în doar câteva ore. Până pe 9 octombrie 2026, workflow-ul apăruse în zeci de mii de repository-uri.

Ce s-a întâmplat

Potrivit StepSecurity, atacatorii au folosit mai întâi contul autorului pyxel, un game engine popular cu aproximativ 18.400 de stele, pentru a introduce un workflow malițios în 27 de repository-uri. Aproximativ opt ore mai târziu, contul autorului original al athenadriver (Uber) a publicat același fișier în 318 repository-uri, în doar 16 minute. Socket a identificat de atunci peste 500 de conturi GitHub care au adăugat workflow-ul în zeci de mii de repository-uri, începând cu 7 octombrie.

Cercetătorii leagă activitatea de GhostAction, o campanie expusă prima dată în 2025. Separat, GitGuardian a urmărit un val care a ajuns la 772 de repository-uri publice ale 373 de utilizatori și organizații, între 31 august și 30 septembrie 2026.

Cercetătorii descriu următoarea secvență:

1. Preluarea contului. Atacatorul obține credențialele GitHub ale unui mentenant, cel mai probabil un personal access token (PAT) scurs prin loguri de infostealer sau baze de date cu credențiale.
2. Recunoaștere. Atacatorul citește workflow-urile repository-ului ca să afle ce secrete denumite există.
3. Injectare. Un workflow numit Security Audit (security-audit.yml) sau GitHub Actions Security (github_actions_security.yml) este adăugat pe branch-ul implicit, sub identitatea victimei.
4. Exfiltrare. Workflow-ul pornește la workflow_dispatch și la orice push, pe orice branch sau tag. Face checkout cu tot istoricul, colectează secretele denumite și caută în fișierele curente și în tot istoricul git 13 tipare de credențiale (AWS, furnizori AI, source control, chei SaaS și cloud). Asociază ID-urile cheilor AWS cu cheile secrete corespunzătoare și trimite totul cu curl, prin HTTP necriptat, către o adresă IP fixă (193.32.204[.]199).

Datele vizate includ secrete CI/CD, chei AWS, chei API Anthropic, OpenAI și OpenRouter și tokenuri GitHub și GitLab. În valurile anterioare au fost vizate și chei SSH, credențiale Azure și Google Cloud, credențiale pentru registry-uri de containere, baze de date, npm, PyPI și Cloudflare, precum și tokenuri de boți de chat. În cel puțin un caz, atacatorii au modificat și imaginea Docker a unui proiect pentru a include cryptominerul XMRig. Conform cercetătorilor, la momentul rapoartelor nu fuseseră publicate pachete malițioase cu credențialele furate.

De ce contează

• Commit-ul pare legitim. Fișierul malițios este publicat de un mentenant real, de încredere, așa că semnalele obișnuite de alarmă („contribuitor necunoscut”) lipsesc.
• Secretele șterse rămân expuse. Workflow-ul citește tot istoricul git, deci și credențialele adăugate și apoi „șterse” pot fi furate.
• Fork-urile răspândesc infecția. Socket arată că 279 de fork-uri dintr-un singur namespace compromis conțin deja workflow-ul. Fork-urile care se sincronizează cu un upstream infectat îl pot moșteni, iar fork-urile private și mirror-ele sunt cele mai expuse, pentru că acolo ajung de obicei credențialele reale.
• Atacatorul obține o hartă chiar și fără secrete. Fiecare rulare trimite înapoi identificatorul repository-ului, deci atacatorul știe unde poate executa cod.

Ce aveți de făcut

1. Căutați fișierele. Verificați toate repository-urile, branch-urile și fork-urile (publice și private) pentru security-audit.yml și github_actions_security.yml, precum și pentru orice workflow neașteptat adăugat după 31 august 2026. Verificați logurile Actions pentru rulări suspecte.
2. Dacă le găsiți, considerați repository-ul compromis. Revocați credențialul GitHub folosit pentru push, apoi rotiți toate secretele la care repository-ul avea acces: secrete Actions, chei cloud, tokenuri de registry și de publicare a pachetelor, chei API AI și tot ce a ajuns vreodată în istoric.
3. Eliminați-l peste tot. Ștergeți workflow-ul de pe toate branch-urile și verificați fork-urile și mirror-ele. Dezactivați Actions pe fork-urile care nu au nevoie.
4. Blocați indicatorul. Blocați și monitorizați traficul de ieșire către 193.32.204[.]199 de pe runnerele CI și verificați conexiunile din trecut.
5. Securizați identitatea mentenanților. Înlocuiți PAT-urile clasice cu tokenuri fine-grained, de scurtă durată, impuneți MFA/passkeys și tratați orice infectare cu infostealer a unei stații de dezvoltare ca pe un incident de credențiale.
6. Restricționați workflow-urile. Cereți pull request-uri revizuite și CODEOWNERS pentru .github/workflows/, activați branch protection pe branch-urile implicite, setați implicit permisiuni read-only pentru GITHUB_TOKEN și preferați OIDC în locul secretelor cloud cu durată lungă.
7. Scanați istoricul. Rulați secret scanning pe tot istoricul git, nu doar pe ultimul commit, și rotiți tot ce găsiți.

Surse: articol The Hacker News (9 octombrie 2026), pe baza cercetărilor StepSecurity, Socket și GitGuardian.