GhostAction revine: ~1.900 de conturi GitHub deturnate pentru a vâna secrete CI/CD

Campania de tip supply-chain GhostAction, care vizează GitHub, a revenit la o scară și mai mare. Într-un val din 8–9 octombrie 2026, atacatorii au folosit aproximativ 1.900 de conturi GitHub compromise pentru a împinge workflow-uri malițioase către peste 30.000 de repository-uri ale circa 3.000 de utilizatori și organizații. Potrivit cercetătorilor, atacatorii au încercat să extragă 3.174 de secrete din pipeline-urile CI ale unor repository-uri publice.

Ce s-a întâmplat

GhostAction a fost descoperită în septembrie 2025. Metoda este simplă și eficientă:

• Acces la un cont real de dezvoltator. Atacatorii folosesc Personal Access Tokens (PAT) furate sau credențiale provenite din loguri de infostealere și din baze de date scurse.
• Un workflow care pare inofensiv. Atacatorii adaugă în repository un fișier GitHub Actions cu nume care sună a securitate, de exemplu security-audit.yml sau github_actions_security.yml.
• Exfiltrarea a tot ce vede CI-ul. Când rulează, workflow-ul încearcă să fure secrete CI/CD, credențiale cloud, token-uri pentru registrele de pachete (npm, PyPI, Docker Hub) și chei API ale furnizorilor de AI.

Un nou val a început pe 31 august 2026 și a ajuns la sute de repository-uri. Potrivit GitGuardian, acest val pare mai manual și mai experimental: payload-ul a evoluat în timp și a primit o funcție pe care versiunea originală nu o avea, scanarea istoricului git pentru secrete. Analize anterioare ale Socket și StepSecurity au arătat că scanerul folosește expresii regulate pentru ID-uri de chei AWS, token-uri GitHub și GitLab, chei legate de AI și alte chei API cloud. Variantele ulterioare rețin și liniile din jurul fiecărui ID de cheie AWS găsit, ca să îl poată asocia cu cheia secretă corespunzătoare.

Valul din octombrie s-a desfășurat în etape. Mai întâi au fost vizate circa 160 de victime deja cunoscute, iar după aproximativ 20 de minute au urmat aproximativ 28.000 de repository-uri noi. Au urmat valuri pe 10 și 12 octombrie, cu același payload. Pentru că GitHub a început să blocheze rularea workflow-ului malițios din 9 octombrie, aceste ultime valuri nu ar fi reușit să extragă secrete.

Un detaliu important: o parte dintre noile victime fuseseră deja compromise în valurile din septembrie 2025 și august 2026. Atacatorii par să mizeze pe faptul că secretele expuse atunci nu au fost rotite.

De ce contează

• CI-ul este un seif de secrete cu ușa la vedere. Oricine are drept de scriere, inclusiv un atacator cu un token furat, poate adăuga un workflow care citește secretele repository-ului.
• Un secret șters nu a dispărut. Noua funcție de scanare a istoricului înseamnă că o cheie „ștearsă” din cod, dar încă prezentă în commit-urile vechi, poate fi găsită.
• Impactul se propagă mai departe. Cu token-uri npm, PyPI sau Docker Hub furate se pot publica pachete compromise, iar cheile cloud și AI furate înseamnă costuri directe și expunere de date.
• Credențialele nerotite atrag un nou atac. Dacă data trecută ați șters workflow-ul, dar nu ați rotit secretele, sunteți în continuare expuși.

Ce trebuie făcut

1. Căutați workflow-uri suspecte. Verificați în organizațiile voastre fișierele neașteptate din .github/workflows/, în special security-audit.yml, github_actions_security.yml sau orice fișier adăugat recent de un cont care nu lucrează de obicei cu CI-ul. Analizați rulările recente și conexiunile externe.
2. Rotiți secretele, nu doar le ștergeți. Rotiți toate secretele expuse în Actions ale repository-urilor afectate: chei cloud, token-uri de registre, chei API AI și chei de deploy. Faceți asta chiar dacă ați fost afectați doar într-un val anterior.
3. Renunțați la PAT-urile de lungă durată. Revocați PAT-urile clasice și treceți la token-uri fine-grained, cu durată scurtă. Unde se poate, folosiți federare OIDC pentru deploy-urile în cloud, ca să nu existe nicio cheie statică de furat.
4. Restricționați cine poate modifica CI-ul. Folosiți CODEOWNERS pentru .github/workflows/, cereți review pe ramurile protejate și limitați la nivel de organizație ce acțiuni și workflow-uri pot rula.
5. Scanați tot istoricul, nu doar ultima versiune. Rulați un scaner de secrete pe întregul istoric git și activați GitHub secret scanning și push protection.
6. Tratați infostealerele ca pe un risc pentru CI. Un laptop de dezvoltator infectat cu un infostealer este un incident de supply-chain. Impuneți MFA și SSO și monitorizați autentificările din locații noi.
7. Verificați-vă pachetele. Dacă token-urile de registru au fost expuse, verificați publicările recente pe npm, PyPI și Docker Hub, căutând versiuni pe care nu le-ați lansat voi.

Articol realizat pe baza informațiilor publicate de The Hacker News și a cercetării GitGuardian.