← All news
Supply ChainCredential SecuritySOC

Attackers Used 4,837 Hijacked GitHub Accounts to Plant Secret-Stealing Workflows Across Tens of Thousands of Repos. Would You Notice an Unfamiliar Branch in Your CI?

Obiguard Research Team·November 13, 2026·4 min read

A campaign dubbed "wfx-loot" used 4,837 compromised GitHub accounts to probe 61,764 repositories for write access and push a credential-stealing script into CI pipelines, with secrets confirmed stolen from at least 1,835 targets. According to BleepingComputer, published 12 November 2026, the research comes from application security company Aikido, whose write-up puts the start at around 12:45 UTC on 10 November. We have relied on BleepingComputer's summary and have not independently verified Aikido's figures.

What is known

  • Entry point: the attacker used stolen GitHub credentials for 4,837 accounts. The report does not say how those credentials were obtained.
  • The probe: pull requests titled "docs: dependency audit notes" were opened against repositories each account could reach, to test write permissions. About 92% were still open, suggesting owners did not notice them.
  • The payload: a roughly 1,500-line shell script delivered by editing an existing GitHub Actions workflow, adding a new workflow on a short-lived branch, or planting an npm install hook.
  • What it collects: Actions secrets and variables, the workflow's GITHUB_TOKEN, OIDC tokens, and AWS, Azure and Google Cloud credentials (including instance metadata on self-hosted runners). It also takes Git, SSH, Docker, Kubernetes, npm, PyPI, Vault and Terraform credentials, plus keys for AI tools such as OpenAI, Anthropic, Gemini, Hugging Face, Cursor and GitHub Copilot.
  • Cloud escalation: it exchanges GitHub OIDC tokens for temporary cloud sessions and, where permissions allow, can create long-lived credentials or change trust policies.
  • Cleanup: the attacker reverted changes and deleted workflow runs and logs, which Aikido says took under a minute.
  • Reach: affected accounts reportedly include Fortune 100 organisations, the US General Services Administration, the French government, Nextcloud and WebdriverIO. About 50 accounts appear to have publishing rights on other ecosystems (npm, PyPI, Go, crates, Packagist), and automated publishing carried the payload into a Packagist package and two Go module versions.

Why it matters

Nothing here broke GitHub. A valid login was enough to open a pull request, and a CI runner then did what workflows are built to do: read secrets and talk to the cloud. Because CI jobs often hold deployment keys and OIDC trust to production, one hijacked developer account can become a cloud compromise. The fast log deletion also means the evidence you would normally rely on may be gone.

This is a different failure from the vendor-side supply-chain risk in our recent look at N-able's N-central zero-days: here the exposure is your own pipeline credentials.

What to do now

  1. Search for the indicators. Look for a branch named wfx-docs, a pull request titled "docs: dependency audit notes", and gaps in workflow run numbers.
  2. Treat confirmed runs as full compromise. If the payload executed, rotate every secret and cloud role the affected workflows could reach.
  3. Review recent workflow changes. Check for unexpected edits to .github/workflows, new short-lived branches, and new postinstall hooks.
  4. Tighten the account side. Require phishing-resistant MFA, revoke stale personal access tokens, and review who has write access.
  5. Limit what CI can reach. Scope GITHUB_TOKEN permissions, restrict OIDC trust policies to specific repositories and branches, and avoid long-lived cloud keys in secrets.
  6. Watch the cloud side. New IAM users, changed trust policies, or token use from unfamiliar locations after a workflow run are the signal that credentials left the pipeline.

How Obiguard SOC fits

Steps 1 and 6 are detection problems: someone has to notice the odd branch, or the cloud identity that changed at 12:50 on a Tuesday. Obiguard SOC streams logs and metrics from what you already run through OpenTelemetry, so cloud audit events and other telemetry can be reviewed together rather than in separate consoles. Alerts arrive with a remediation plan split into now, this week and long-term, and its CVE Radar scans connected repositories on every push and daily, which covers the dependency side of the problem. Scope matters: SOC works from the telemetry you connect to it. It does not stop a stolen GitHub login, cannot see events that are not logged, and does not rotate your secrets for you. To see how it would work on your logs, get in touch or read about Obiguard SOC.

Sources

How Obiguard helps

Turn this into enforced policy, not just awareness.

Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.

See how it works →