GhostAction Attack: How Hackers Weaponized GitHub Actions to Steal Thousands of Credentials
In the world of software development, automation is king. Tools like GitHub Actions have revolutionized how we build, test, and deploy code, creating seamless CI/CD pipelines. But this convenience comes with a new set of security challenges. A recent, sophisticated campaign dubbed the “GhostAction attack” has exposed a critical vulnerability in this ecosystem, leading to the theft of over 3,300 sensitive credentials from public GitHub repositories.
This attack serves as a stark reminder that the software supply chain remains a prime target for malicious actors. Understanding how this attack works is the first step toward protecting your own projects.
What is the GhostAction Attack?
The GhostAction attack is a supply chain attack that targets public GitHub repositories using the platform’s own automation features against them. Attackers exploit a specific GitHub Actions trigger to execute malicious code within a project’s trusted environment.
The goal is simple but devastating: exfiltrate sensitive secrets and credentials, such as API keys, cloud service provider tokens, and other authentication data stored within the repository’s environment. Once stolen, these secrets give attackers the keys to your kingdom, allowing them to access private infrastructure, databases, and other critical services.
How the Attack Works: A Step-by-Step Breakdown
The attackers behind GhostAction demonstrated a deep understanding of GitHub’s inner workings. Their method is clever, stealthy, and designed to evade common security checks.
The Fork and Pull Request: The attack begins when a threat actor forks a public repository. They then submit a seemingly harmless pull request (PR) back to the original project. This PR doesn’t contain any obviously malicious code in the main branch, making it difficult to spot during a routine code review.
The Malicious Workflow: The true danger lies in a separate, malicious GitHub Actions workflow file the attacker adds to their forked repository. This workflow is specifically designed to activate when another workflow runs in the target repository.
Exploiting the
workflow_runTrigger: The core of the attack leverages theworkflow_runtrigger. This legitimate feature allows one workflow to be triggered by the completion of another. The attackers craft their malicious workflow to trigger whenever a standard event, like apushorpull_request, occurs in the target repository. This means that as soon as the project maintainer interacts with the PR, the trap is sprung.Stealing Secrets: Once triggered, the malicious workflow executes with access to the repository’s context. This includes the highly privileged
GITHUB_TOKENand any other secrets the CI/CD pipeline is configured to use. The script then immediately sends these stolen secrets to an external server controlled by the attacker.Covering Their Tracks: In a final act of stealth, the attacker often deletes their fork of the repository after the secrets have been stolen. This erases the evidence of the malicious workflow, making it incredibly difficult for victims to perform a post-mortem analysis and understand how they were breached.
The Impact: Thousands of Secrets Compromised
The scale of the GhostAction campaign is alarming. Security researchers have confirmed that at least 3,325 unique secrets were stolen from numerous public repositories. These aren’t just minor credentials; they include high-value keys for major cloud providers and other third-party services. A single stolen token could be enough for an attacker to pivot into a company’s entire cloud infrastructure, leading to data breaches, financial loss, and catastrophic reputational damage.
Actionable Steps to Secure Your GitHub Repositories
While the GhostAction attack is sophisticated, it’s not unstoppable. You can take concrete steps to harden your CI/CD pipelines and protect your repositories from similar threats.
Audit Your
workflow_runTriggers: Carefully review all workflows that use theworkflow_runtrigger. Ensure they are absolutely necessary and are not configured in a way that could be exploited by pull requests from forked repositories.Enforce the Principle of Least Privilege: By default, the
GITHUB_TOKENhas broad permissions. Explicitly restrict the permissions for your workflows to the bare minimum required for them to function. This can be done at the workflow or job level. If a job only needs to read issues, it should not have permission to write code or access secrets.Require Approval for First-Time Contributors: GitHub offers a setting to require approval before running GitHub Actions on pull requests from first-time contributors. Enable this feature immediately. It acts as a crucial manual gate, preventing automated attacks from unknown sources.
Use OIDC for Cloud Authentication: Whenever possible, avoid storing long-lived cloud credentials as GitHub secrets. Instead, use OpenID Connect (OIDC) to grant workflows short-lived, temporary access to cloud resources. This drastically reduces the impact if a token is ever compromised.
Implement Secret Scanning: Utilize GitHub’s built-in secret scanning or third-party tools to continuously monitor your codebase for accidentally committed credentials. This provides a critical safety net to catch mistakes before they can be exploited.
The GhostAction attack highlights a new frontier in cybersecurity. As developers rely more heavily on automation, attackers will continue to find creative ways to abuse it. Proactive security, vigilant monitoring, and a defense-in-depth strategy are no longer optional—they are essential for protecting the integrity of your software supply chain.
Source: https://www.bleepingcomputer.com/news/security/hackers-steal-3-325-secrets-in-ghostaction-github-supply-chain-attack/
