🚨 GhostAction: When a Trusted GitHub Maintainer Becomes a Supply-Chain Entry Point

Two reported maintainer-account compromises turned a seemingly defensive GitHub Actions workflow into a credential-harvesting path across hundreds of repositories. This investigation separates researcher-reported evidence from unresolved questions and outlines practical CI/CD defence.

A trusted maintainer identity can turn one workflow file into a supply-chain entry point. GhostAction’s October 2026 wave shows why a workflow named “security audit” must be judged by what it executes—not what its filename promises.

346Repositories reported by Socket for the October 8 wave

2Maintainer identities reported as compromised

HTTPReported cleartext exfiltration to 193.32.204[.]199

Evidence boundary: These are researcher-reported findings, not an independent forensic examination of every affected repository. Socket reported 346 repositories while StepSecurity summarized 345; their reporting appears to count the Uber repository differently. Do not combine the totals or assume every repository leaked secrets.

1. Executive Summary

On 8 October 2026, Socket reported a new burst in the GhostAction credential-theft campaign. Two GitHub maintainer accounts were reportedly used to add a workflow named .github/workflows/security-audit.yml to repositories where those identities had write access.

The reported workflow did more than inspect CI/CD secrets. This wave also searched the repository working tree and full Git history for credentials, including cloud, AI, SaaS and source-control tokens, then sent collected data to a hard-coded external IP over unencrypted HTTP.

Defensive headline: Treat an unexpected workflow change as a potential production security incident. Review the workflow content and its execution history, not merely the commit message or file name.

The available public reporting supports a serious credential-exposure lead. It does not establish that every repository executed the workflow, that every secret was exfiltrated, or that downstream misuse occurred in every affected environment.

2. What Researchers Reported

Observation	Reported detail	Boundary
Workflow	`.github/workflows/security-audit.yml`	Reported by Socket in the October 8 wave.
Maintainer identities	`henrywoo` and `kitao`	Reported as compromised identities; this does not mean the account owners knowingly conducted the activity.
Repository count	Socket: 346; StepSecurity: 345 in its summary	Published totals differ in how the Uber-owned repository is counted.
Reported destination	`193.32.204[.]199` over plain HTTP	An indicator from public research; validate against current intelligence and local telemetry.
Downstream package abuse	Socket had not observed malicious package versions published to PyPI or crates.io from this activity as of 9 October.	A dated observation, not a guarantee that no later activity occurred.

Socket’s breakdown describes 318 repositories associated with the henrywoo sweep, 27 associated with kitao, and an Uber-owned repository, uber/athenadriver, to which the Henry Wu account reportedly retained write access. StepSecurity’s total is one lower and describes the Uber repository within the Henry-linked sweep. The reports should be cited separately rather than force-fitted into a single count.

3. Attack Flow — From Trusted Identity to Credential Exposure

The supplied research brief includes the following illustrative flow. It describes the reported mechanism and defensive priorities; it is not proof that every stage happened in every listed repository.

GhostAction defensive flow: maintainer account compromise, malicious GitHub Actions workflow, workflow execution, collection of secrets and Git history, data exfiltration, possible credential abuse, and containment — Figure 1. Defensive model derived from the supplied research brief. Validate each stage against repository, audit-log and egress evidence.

Maintainer identity compromised→Workflow injected→Secrets and history searched→Data sent externally→Credentials revoked and rotated

GitHub Actions workflows can run with permissions granted by repository configuration and workflow context. A malicious workflow committed under a trusted maintainer identity can therefore exploit trust in the development process without requiring a newly disclosed GitHub platform vulnerability.

4. How the Workflow Expands the Blast Radius

Step 1 — Abuse of maintainer write access

Researchers described commits made under the affected maintainer identities. A workflow change in a repository where the account can write may be accepted by the normal repository trust model, especially if the change does not require a pull request or an independent review.

Step 2 — Defensive-sounding file name

The name security-audit.yml looks benign. The actual workflow behavior is what matters: unexpected access to secrets, scans for credential patterns, access to commit history and outbound network calls should receive immediate review.

Step 3 — Search beyond configured CI secrets

The October wave was reported to combine GitHub Actions secret collection with searches of checked-out files and the full Git history. A credential deleted from the current tree may still be recoverable from an earlier commit.

Step 4 — External transfer

The reported workflow sent collected data to 193.32.204[.]199 using unencrypted HTTP. Treat this as a high-priority hunting indicator, not as a standalone proof that a particular host sent data.

5. What Is Supported — and What Remains Unconfirmed

Reported by researchers

Malicious workflow files were observed across hundreds of repositories; credential collection included GitHub Actions secrets and, in the October variant, working-tree/Git-history searches; a hard-coded external HTTP destination was reported.

Not established for every victim

Whether every listed workflow executed; the exact number of secrets exfiltrated in the October wave; complete downstream credential abuse; the initial method used to compromise the maintainer sessions; and a confirmed identity or sponsorship for the operator.

The repository count describes the scope observed in reporting, not a count of confirmed secret leaks. Separate indicators such as a workflow file, a successful run, evidence of outbound transfer and confirmed credential use should not be treated as interchangeable findings.

6. GhostAction Timeline — Keep the Waves Separate

September 2025: GitGuardian documented an earlier campaign affecting 817 public repositories across 327 GitHub users and reported at least 3,325 secrets exfiltrated.
31 August–30 September 2026: GitGuardian reported a further wave affecting 772 public repositories belonging to 373 GitHub users and organisations and targeting 2,577 secrets.
8 October 2026: Socket reported the new burst across 346 repositories; StepSecurity described the activity as 345 repositories. The October variant added working-tree and historical-commit credential searches.
9 October 2026: Socket and StepSecurity published technical reporting. Their counts and observation windows should be retained with attribution.

Do not add wave totals blindly. Repositories, accounts, workflows and secrets may overlap across waves. The earlier and later counts are not one deduplicated victim total.

7. Detection and SOC Hunting

Search repositories, forks and mirrors for unexpected .github/workflows/security-audit.yml files and related commits from 8 October onward. Also search for legacy names such as .github/workflows/github_actions_security.yml.
Review commit history and GitHub audit logs for workflow creation/updates, unusual maintainer sessions, token creation, permission changes, unexpected pushes and workflow runs.
Inspect workflow YAML and related scripts for broad secret access, checkout or traversal of full Git history, credential-pattern searches, hard-coded external destinations and outbound HTTP.
Review runner, firewall, proxy and DNS telemetry for connections to 193.32.204[.]199 and unusual plaintext HTTP from CI workloads. Confirm the indicator against current threat-intelligence sources before blocking or attributing.
Inventory secrets available to affected workflows and examine cloud, SaaS, source-control and package-provider audit logs for use after the suspected exposure period.
Check downstream repositories and organisations that a maintainer account could write to; do not limit hunting to the person’s own namespace.

High-value correlation: unexpected workflow commit + workflow run + external egress + subsequent use of the same credential is stronger evidence than any single signal alone.

8. Containment, Recovery and Hardening

Disable or remove the malicious workflow after preserving a copy and relevant commit/run evidence. Temporarily restrict workflow execution if the exposure scope is still unclear.
Revoke and rotate every credential that may have been accessible, prioritising cloud-admin keys, GitHub tokens, deployment secrets and package-publishing credentials. Rotate secrets that were ever committed to Git history, even if later deleted.
Invalidate suspicious sessions and tokens, secure the affected maintainer accounts and enforce phishing-resistant MFA where supported.
Audit all repositories, forks and organisation projects where the identities had write access, including cross-organisation repositories.
Minimise GITHUB_TOKEN permissions, use required workflow approvals where appropriate, protect workflow files with CODEOWNERS/review rules, pin third-party actions to verified full commit SHAs and restrict CI runner egress.
Use secret scanning and push protection; keep short-lived credentials where feasible and prefer narrowly scoped credentials over long-lived tokens.
After containment, verify the repository, runner and downstream identity logs before declaring the incident closed.

9. MITRE ATT&CK Perspective — Analytical Mapping

These mappings are investigation hypotheses based on reported behavior. Validate them against the workflow, commit data and telemetry before using them as confirmed adversary techniques.

ID	Technique	Relevance and limitation
`T1078`	Valid Accounts	Potentially relevant to the reported use of compromised maintainer identities.
`T1552.001`	Credentials in Files	Relevant to the reported search for credentials in working files and Git history.
`T1195`	Supply Chain Compromise	Analytical mapping for abuse of repository and workflow trust to affect development/build processes.
`T1567`	Exfiltration Over Web Service	Broad candidate mapping only. Validate the precise technique against the observed transfer and current ATT&CK taxonomy; plain HTTP to an IP is not by itself enough to confirm a specific sub-technique.

CyberRakshakLabs Assessment

Assessment: HIGH. The reported behavior combines a trusted maintainer identity, CI/CD execution and broad credential discovery. If a workflow executes with access to sensitive secrets, compromise can reach cloud, AI, SaaS, source-control and deployment environments beyond the affected repository.

Confidence statement: Confidence is high that multiple independent security researchers published detailed reports on the October 2026 activity. The precise deduplicated victim count, per-repository execution, number of credentials exfiltrated, downstream abuse and operator attribution remain unconfirmed by the supplied evidence alone.

Key takeaway: A trusted maintainer can become the supply-chain entry point. Disable the workflow, establish what it accessed, revoke and rotate exposed credentials, inspect Git history and investigate downstream use before declaring recovery complete.

Think Before You Click. Stay Aware. Stay Secure.

Sources & Verification Notes

Primary technical reporting: Socket Research Team — “New GhostAction Wave Hits Hundreds of Repos, Expanding Beyond CI/CD Secrets to Cloud Credentials” (9 October 2026) ↗. Supports the reported workflow, repository breakdown, credential-search behavior and network destination.

Independent technical reporting: StepSecurity — “GhostAction Returns: Malicious ‘Security Audit’ Workflows Now Mine Credentials from Entire Git Histories” (9 October 2026) ↗. Its summary uses a total of 345 repositories; that count is retained with attribution rather than silently merged with Socket’s count.

Historical campaign context: GitGuardian — “The campaign that never stopped: tracking GhostAction from 2025 to 2026” (7 October 2026) ↗. Supports the historical repository and secret counts for the earlier waves.

The research brief supplied for this article was used as the primary drafting source. Public reports were consulted for corroborating context. CyberRakshakLabs did not independently execute, test or reproduce the reported workflow. Repository counts, observed execution and impact are attributed to the publishing researchers; defensive recommendations are CyberRakshakLabs analysis.

CyberRakshakLabs — Threat Intelligence for a Safer Tomorrow.