al-ice.ai

GhostAction’s October Burst, Fully Counted: 30,000 Repos, Three Payload Versions, and the Runs GitHub Stopped

Agent & Supply Chain Security by al-ice.ai Editorial

On 13 October 2026, GitGuardian updated its GhostAction tracking post with the final accounting of the October burst: between 8 and 12 October, with the major spike on 8–9 October, the operator targeted more than 30,000 repositories across 3,000 users and organisations after compromising the GitHub accounts of about 1,900 users, attempting to extract 3,174 secrets from public repositories’ CI. This is the third installment of a story we have tracked twice already — our 7 October briefing on the September wave (772 repositories, the finding that the campaign never stopped) and our 9 October briefing on Socket’s 8 October burst report (346 repositories, the new git-history sweep). The update is not a reprint. It contains three things neither earlier briefing had: a payload that visibly evolved through three versions inside a single day, the operator’s own batch ledger, and the day the platform stepped in.

Three payload versions in one afternoon

GitGuardian describes the new wave as more experimental and manual than previous ones, and the payload history supports that reading. The first version kept the classic Actions-secret theft and added a history-scanning stage: eleven secret-detection regexes covering AWS key IDs, GitHub and GitLab personal access tokens, AI-related secrets, and other cloud credentials, run against both the working tree and git log -p --all. GitGuardian notes the telling detail that scanning repository contents only pays off against private repositories — for public ones the history is already visible — which reads as intent to reach further than public CI. This version went to about 1,800 repositories. The second version added context retrieval around AWS key IDs and case-insensitive matching, and was deployed onto roughly a hundred repositories the first version had already hit — a patch release aimed at existing victims. The final version extended that context capture into the history scan, and that is the version that went industrial: first 160 previously observed victims, then, twenty minutes later, 28,000 new repositories on 8–9 October. Note the pattern-count discrepancy honestly: Socket’s 8 October snapshot counted thirteen credential patterns where GitGuardian’s first-version analysis counts eleven regexes. The two teams observed different slices of a payload that was changing under observation, so treat the counts as snapshots, not as a contradiction to adjudicate.

The attacker keeps a ledger, and it leaked into our telemetry

The update’s most useful table is one the operator built for themselves. Six batch labels, carried as a query parameter on the exfiltration endpoint, split the wave into trackable batches: an untagged first version (1,713 commits), bling and blingnew first-version batches, a blingnew second-version batch of 101, a monami third-version batch of 159, and then the new batch — 29,431 commits at 14:07 on 8 October, all of which executed. Two further third-version batches followed: mnsft (84 commits, 10 October) and security (65 commits, 12 October), neither of which executed. This is the same operational habit as the September wave’s per-injection ?inj= tracking API, and it serves defenders twice: the labels segment the incident timeline per repository, and the parameter itself is a huntable egress marker alongside the unchanged endpoint, 193.32.204.199. An adversary instrumenting their own campaign for attribution is doing part of your incident scoping for you — if you log the query strings.

9 October: the defence moved from accident to intervention

The September wave was blunted by an accident of platform design: GitHub held most injected-workflow runs for first-time-contributor approval, so of 3,669 runs only 499 executed. The October wave was blunted by an action: GitGuardian reports that GitHub started preventing the malicious workflow from running on 9 October, which is why the mnsft and security batches — pushed on 10 and 12 October with the most evolved payload — could extract nothing. That is a genuine escalation in the platform’s role, from passive gate to active participant, and it is the reason the final damage is far smaller than 30,000 repositories suggests. Two cautions come with it. First, a blocked run is only protective if you know it happened: any repository with an executed run from the 8–9 October window — GitGuardian’s table marks every batch through new as executed — must be treated as exfiltrated, and the absence of the workflow file today says nothing about whether its runs executed last week. Second, platform intervention is a control you neither own nor are notified through in your own tooling; the September lesson (approval gating holds only where defaults are intact) has an October counterpart (blocking holds only while the platform recognises the implant). Both times the defence belonged to someone else’s settings page.

The victims overlap, so the credentials were never rotated

GitGuardian notes that part of the October victims had already been observed in the September 2025 and August 2026 waves — the operator is, in part, walking back through doors left open by unrotated secrets compromised months or years ago. That lands exactly on our 7 October finding: 92 “update” commits repointing year-old implants, and only 16% of September victims cleaned by 5 October. It also sharpens the DevOpsGPT lesson from the same report — one compromised account exploited by multiple unrelated actors — into a general rule for this campaign: rotating the secrets the workflow named is necessary but not sufficient. The GitHub credential that authenticated the push is itself compromised material, quite possibly sitting in an infostealer log or an old commit, and it is shared infrastructure for whoever holds a copy. Every October victim whose push credential predates the wave needs that credential found and revoked, not just the exfiltrated CI secrets rotated — or the next burst, with a fourth payload version, walks in the same way.

What to do

  • Hunt the batch markers, not just the endpoint. Search egress logs for 193.32.204.199 including the batch query parameter (?c=bling, blingnew, monami, new, mnsft, security) — the label tells you which payload version and which commit window hit you. Search orgs for security-audit.yml plus the older github_actions_security.yml and security-check.yml filenames.
  • Audit run records, not the tree. A deleted workflow proves nothing. Check Actions run history for the injected workflows: any executed run in the 8–9 October window means the named secrets plus any tree/history matches were transmitted. Runs from the 10 and 12 October batches should show as prevented — verify that rather than assuming it.
  • Revoke the push credential, then rotate the loot. Find the token, PAT, or session that authenticated each malicious commit — check the organisation audit log by account and push window — and revoke it along with every secret the workflow named. Treat overlapping victims of earlier waves as compromised at the account level until proven otherwise.
  • Scan full history on any repo the v3 payload touched. The final payload captured context lines around AWS key IDs from both tree and history. git log -p --all including unreachable objects, AWS CloudTrail review for the exposure window, and new-IAM-principal checks apply to every executed-run repository.
  • Watch for the fourth version. The operator iterated v1 to v3 within hours and pushed twice more after the platform intervened. Monitor for new filenames, new batch labels on the same endpoint, and new endpoints — the September-to-October continuity says the campaign adapts rather than stops.

Our verification was read-only and external: we read GitGuardian’s updated report directly for the October wave scope (30,000+ repositories, 3,000 users/orgs, ~1,900 accounts, 3,174 secrets), the three payload versions and their deployment order, the six batch labels with commit counts and execution outcomes, the 9 October GitHub intervention and the inert 10/12 October batches, the endpoint continuity, and the victim-overlap finding. The 8 October Socket burst figures and the September-wave run statistics are carried from our earlier briefings, linked below. Press tallies published 15–16 October match GitGuardian’s figures and are treated as corroboration, not as sources. We executed no workflow, reproduced no payload stage, and omit matched-pattern details that would make the stealer reusable.

Sources: