Stolen GitHub Tokens Exfiltrate Secrets via Actions Logs
Introduction
An automated intrusion campaign has been observed leveraging compromised GitHub personal access tokens to inject malicious workflow definitions into target repositories. Once the workflow runs, it prints the full set of repository secrets—such as API keys, database passwords, and cloud credentials—directly into the GitHub Actions log output. The operators then retrieve the log artifacts and delete the workflow runs to erase traces of the activity.
How the Attack Works
The chain begins when attackers obtain a valid token, often through phishing, credential stuffing, or accidental exposure in public code. With that token they create or modify a workflow file (typically .github/workflows/) that contains a step designed to echo all environment variables and secret values. Because GitHub Actions automatically injects repository secrets into the runner environment, the step can dump them to stdout. The workflow is triggered immediately, the logs are collected via the Actions API, and the run is removed using the same token before defenders can notice.
Impact on Private Repositories and Enterprise
Research from cloud security firm Wiz confirms that the technique succeeds against private repositories and GitHub Enterprise Cloud instances. The token’s scope determines the blast radius; a token with repo‑level admin rights can affect every repository in the organization. Since the workflow runs inside the victim’s own infrastructure, network‑based egress controls do not block the exfiltration, and the logs remain accessible through the GitHub UI or API until the run is purged.
GitHub Safeguard and Its Limits
GitHub has introduced a safeguard that pauses workflow execution when a newly added workflow file modifies secret‑related steps, requiring a maintainer approval before the run proceeds. This control raises the bar for opportunistic automation, yet it can be bypassed if the compromised token already possesses the necessary permissions to approve the run or if the attacker edits an existing, already‑approved workflow instead of creating a new one.
Practical Mitigations for Defenders
- Rotate and scope tokens aggressively – enforce short‑lived, fine‑grained personal access tokens and revoke any that are no longer needed.
- Enable secret scanning and push protection – GitHub’s native secret scanning can alert on tokens that appear in code, reducing the chance of accidental leakage.
- Monitor Actions activity – set up alerts for workflow runs that output large amounts of text, for runs that are deleted shortly after completion, or for modifications to workflow files by non‑admin accounts.
- Restrict workflow permissions – use the
permissionskey in workflow YAML to limit theGITHUB_TOKENto read‑only where possible, preventing it from creating or deleting runs. - Require signed commits and protected branches – this makes it harder for an attacker to push a malicious workflow without detection.
Grivyonx Expert Analysis
The campaign illustrates how a single compromised credential can cascade into full secret exposure without any vulnerability in the platform itself. Defenders should treat token hygiene as a first‑line control and complement it with continuous runtime monitoring of Actions logs, because the exfiltration occurs entirely within the trusted CI/CD pipeline.
Conclusion
Stolen GitHub tokens remain a potent lever for attackers seeking to harvest secrets from private codebases, and the ability to erase workflow runs makes detection difficult. Organizations that combine strict token lifecycle management, branch protection, and real‑time Actions telemetry will dramatically reduce the attack surface. Grivyonx’s AI‑driven DevSecOps automation can help teams enforce these controls continuously across large GitHub estates.
- #GitHub
- #token theft
- #Actions logs
- #secret leakage
- #Wiz research
- #DevSecOps
- #cloud security
