Habla con un experto
PreciosNoticiasHabla con un experto
Volver a la sala de prensa
Amenazas

GhostAction Returns: ~1,900 GitHub Accounts Hijacked to Hunt CI/CD Secrets

The GhostAction campaign used about 1,900 compromised GitHub accounts to push secret-stealing workflows at 30,000+ repositories, and it now scans git history too. Here's what to check and rotate.

4T4Tify Team4Tify
Oct 15, 2026·5 min de lectura
GhostAction Returns: ~1,900 GitHub Accounts Hijacked to Hunt CI/CD Secrets

GhostAction Returns: ~1,900 GitHub Accounts Hijacked to Hunt CI/CD Secrets

The GitHub supply-chain campaign known as GhostAction is back, and bigger. In a burst on 8–9 October 2026, attackers used roughly 1,900 compromised GitHub accounts to push malicious workflows toward more than 30,000 repositories belonging to about 3,000 users and organizations. Researchers say the operators tried to pull 3,174 secrets out of public repositories' CI pipelines.

What happened

GhostAction was first spotted in September 2025. Its playbook is simple and effective:

  • Get into a real developer account. Access comes from stolen Personal Access Tokens (PATs) or credentials scraped from infostealer logs and credential dumps.
  • Plant a workflow that looks harmless. The attackers commit a GitHub Actions file with a security-sounding name, such as security-audit.yml or github_actions_security.yml.
  • Exfiltrate what CI can see. When the workflow runs, it goes after CI/CD secrets, cloud credentials, package-registry tokens (npm, PyPI, Docker Hub) and AI-provider API keys.

A new wave started on 31 August 2026 and reached hundreds of repositories. According to GitGuardian, this round looks more hands-on and experimental: the payload changed over time and gained a feature the original lacked, scanning the git history for secrets. Earlier analysis by Socket and StepSecurity found that this scanner uses regular expressions for AWS access key IDs, GitHub and GitLab tokens, AI-related keys and other cloud API keys. Later variants also capture the lines around each AWS key ID hit, so the access key ID can be paired with its secret key.

The October push came in phases. It first hit around 160 previously known victims, and about 20 minutes later it reached roughly 28,000 new repositories. Further waves on 10 and 12 October used the same payload. GitHub had started blocking the malicious workflow from running on 9 October, so those later waves reportedly got no secrets.

The detail defenders should pay attention to: some of the new victims had already been hit in the September 2025 and August 2026 waves. The attackers appear to be betting that secrets exposed last time were never rotated.

Why it matters

  • CI is a secrets vault with a public door. Anyone with write access, including an attacker holding a stolen token, can add a workflow that reads the repository's secrets.
  • Deleted secrets aren't gone. The new history-scanning feature means a key "removed" from the code but still present in old commits is fair game.
  • The blast radius goes downstream. Stolen npm, PyPI or Docker Hub tokens can be used to publish poisoned packages, and stolen cloud and AI keys mean direct cost and data exposure.
  • Unrotated credentials invite a repeat attack. If you cleaned up the workflow last time but didn't rotate the secrets, you're still exposed.

What to do

  1. Hunt for rogue workflows. Search your organizations for unexpected files in .github/workflows/, especially security-audit.yml, github_actions_security.yml or anything added recently by an account that doesn't normally touch CI. Review recent workflow runs and outbound connections.
  2. Rotate, don't just remove. Rotate every secret that was exposed to an affected repository's Actions: cloud keys, registry tokens, AI API keys and deploy keys. Do this even if you were only touched in an earlier wave.
  3. Kill long-lived PATs. Revoke classic PATs and move to fine-grained, short-lived tokens. Where possible, use OIDC federation for cloud deployments so that there's no static key to steal.
  4. Lock down who can change CI. Use CODEOWNERS for .github/workflows/, require reviews on protected branches, and restrict which actions and workflows can run at the organization level.
  5. Scan your history, not just HEAD. Run a secret scanner over the full git history and enable GitHub secret scanning and push protection.
  6. Treat infostealer exposure as a CI risk. A developer laptop infected with an infostealer is a supply-chain incident. Enforce MFA and SSO, and watch for logins from new locations.
  7. Watch your packages. If registry tokens were exposed, audit recent publishes of your npm, PyPI and Docker Hub artifacts for versions you didn't release.

This article was based on reporting by The Hacker News and research by GitGuardian.

COMPARTIR