Skip to content
HACKTECH
Supply chainReported Published 5 sources

GhostAction plants secret-stealing workflows in tens of thousands of GitHub repos

GitGuardian reported on 7 October 2026 that between 31 August and 30 September a malicious workflow, github_actions_security.yml, was pushed to 772 public repositories belonging to 373 GitHub users and organisations, and its 13 October update said a second wave on 8 to 12 October targeted more than 30,000 repositories after the GitHub accounts of about 1,900 users were compromised. The Hacker News, citing OpenSourceMalware, reported a phishing kit on my-github[.]com, a domain resolving to the campaign's exfiltration IP, that sent a maintainer a fake GitHub security alert, captured the password and 2FA code through a reverse proxy and silently authorised an OAuth device flow with repo, workflow and read:org scopes. Six days after GitHub began blocking the workflow on 9 October, a second stage appeared that commits a VS Code task set to run when a folder is opened, and GitGuardian later counted 72,026 commits to 22,964 public repositories between 13 and 21 October.

  • GhostAction
  • GitHub Actions
  • phishing
  • OAuth device flow
  • secrets theft
  • VS Code
  • maintainer account takeover

What the sources report

  • Wave 1 (31 August to 30 September 2026): the workflow github_actions_security.yml, committed as 'Add Github Actions Security workflow', reached 772 public repositories of 373 users and organisations and targeted 2,577 secrets (GitGuardian).
  • Of 3,669 wave-1 runs GitGuardian collected across 605 repositories, 499 executed in 32 repositories and 336 completed, exfiltrating 26 secrets from 13 repositories; only 124 repositories (16%) had been cleaned in public history by 5 October.
  • Wave 2 (8 to 12 October) targeted more than 30,000 repositories across 3,000 users and organisations through the compromised accounts of about 1,900 users; GitHub prevented the workflow from running from 9 October, so the 10 and 12 October waves extracted no secrets, and stolen data went over plain HTTP to 193.32.204.199 (GitGuardian).
  • my-github[.]com was registered on 9 October 2026 and points to 193.32.204[.]199; the same day it was used for a phishing email warning a maintainer of a suspicious login and telling them to secure the account. OpenSourceMalware's 9 October analysis noted that ownership of the domain by the GhostAction operator was not yet proven (The Hacker News, OpenSourceMalware).
  • Stage 2 commits a .vscode/tasks.json with runOn: folderOpen and a fake font file, public/fonts/fa-solid-400.woff2, that steals credentials and installs a cron job running whatever the attacker's server sends every five minutes (OpenSourceMalware, The Hacker News).
  • GitGuardian's 27 October analysis found 1,382 of the 1,792 pushing accounts had already pushed the 8 October payload, and that newer payload families target self-hosted runners, cloud instance metadata and AWS roles reachable through GitHub OIDC (GitGuardian, The Hacker News).

What it means for your organisation

GitGuardian found the malicious commits were made under victims' own identities with what appear to be stolen credentials, some likely left unrotated since earlier waves, and an OAuth grant with workflow scope was enough to add CI jobs that read every secret a repository exposes. In one sample reported by The Hacker News, 65 of 79 still-accessible repositories carrying the second-stage component had no commit for more than a year, so dormant projects still held live credentials. GitGuardian also notes that rotating the exfiltrated secrets is not enough: the GitHub credential that allowed the injection must be found and revoked, and the editor-task stage means controls need to cover developer workstations as well as runners.

What we check

  • Review OAuth app and device-flow authorisations for maintainers and revoke grants with repo or workflow scope that are not needed.
  • Search organisation repositories for unexpected workflow files (github_actions_security.yml, security-audit.yml), .vscode/tasks.json entries with runOn: folderOpen, and unexplained font files.
  • Enumerate Actions secrets on dormant and archived repositories and remove or rotate those no longer needed.
  • Confirm maintainers use phishing-resistant MFA, and test it with a simulated GitHub security-alert phishing email.
  • Check that runner egress is restricted and that plain-HTTP POSTs from CI to bare IP addresses raise an alert.

Sources

Services that cover these checks

  • Social engineering assessment

    Phishing, vishing and physical pretexting run against your staff, help desk and finance team, only under written authorisation that names the targets, pretexts and limits. Results are reported by channel and pretext, never by name: how far a convincing approach got, how many people reported it and how long the first report took to reach someone who acted.

    Duration: 2 to 4 weeks including campaign preparation

  • Secure development training

    Hands-on workshops for engineers, run against a deliberately vulnerable copy of a codebase like yours. Developers exploit each bug before they fix it, so they have seen the attack their fix has to stop, and review real pull requests for the same bugs.

    Duration: 1 to 3 days on site or remote

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

  • Application security audit

    A white-box review of your application: source code, architecture, dependencies and build pipeline. Automated analysis finds the candidates; reviewers confirm each one by reading the code path, and only confirmed defects reach the report, each with a file and line reference.

    Duration: 5 to 15 working days, depending on codebase size

  • Cloud configuration review

    An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.

    Duration: 4 to 8 working days

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works