How it unfolded

1. 1

   Available GitHub tokens are validated and scoped

   After the worm reached a host — typically via a compromised npm package — its payload validated whatever GitHub tokens were reachable there and checked exactly what each one could do.

2. 2

   Repos are enumerated by privilege, not just ownership

   It queried /user/repos?affiliation=owner,collaborator,organization_member to find every repository where the compromised account held enough privilege to act — far beyond repos it directly owned.

3. 3

   A malicious workflow is planted and secrets exfiltrated

   It planted shai-hulud-workflow.yml in each reachable repo and exfiltrated the full secrets context (${{ toJSON(secrets) }}) to an external webhook.

4. 4

   Repositories are flipped public to maximize spread

   It made repositories public, including ones the compromised account merely held a token for rather than owned outright, maximizing both exposure and further propagation surface.

5. 5

   2.0: the infected host registers itself as a runner

   The follow-up variant registered the infected machine as a self-hosted Actions runner named SHA1HULUD, turning a single compromised developer machine into infrastructure the attacker could keep using.

6. 6

   2.0: opening a GitHub Discussion becomes remote code execution

   It planted an injection-prone workflow at .github/workflows/discussion.yaml, so simply opening a GitHub Discussion on an affected repo triggered arbitrary command execution on that self-hosted runner — ultimately compromising 796 npm packages, with credential exfiltration confirmed across 500+ GitHub users spanning 150+ organizations.