Your GitHub Secrets Are Leaking Through Action Logs
TL;DR: An automated attack is using stolen GitHub tokens to print your repository secrets into Actions logs. Attackers then download these logs to steal sensitive data from private and enterprise codebases, creating a significant new security risk.
Key facts
- Category
- Cybersecurity
- Impact
- Critical
- Published
- Source
- The Hacker News
Full summary
Attackers are using stolen GitHub tokens to print your repository secrets directly into Actions logs, exposing sensitive data from private code.
An active and automated attack campaign is targeting private and enterprise GitHub repositories by exploiting stolen developer tokens. According to a report from cloud security firm Wiz, attackers are gaining access to codebases and then modifying CI/CD workflows to steal sensitive information. The campaign, dubbed "Gheist," has successfully breached both private repositories and GitHub Enterprise environments. The attackers use a compromised GitHub token to push a malicious workflow file into a repository. This new workflow is designed to access the repository’s secrets—such as API keys, cloud credentials, and private certificates—and simply print them out. The output containing these secrets is captured in the standard GitHub Actions logs, a feature developers use every day for debugging. The attackers then download these logs, capture the credentials, and delete the workflow run to cover their tracks, making the breach difficult to detect after the fact.
The novelty of this attack lies in its simplicity and its abuse of a trusted, fundamental feature of the CI/CD process. Rather than attempting to exfiltrate data to an external server, which might be flagged by network monitoring tools, the attackers turn the logging system itself into the exfiltration channel. By printing secrets to the console output, the malicious code mimics legitimate debugging behavior. This makes it blend in with the normal operational noise of a busy development environment. The final step—deleting the workflow run—is a clever anti-forensic technique that erases the primary evidence of the attack. This forces security teams to rely on proactive and comprehensive audit log analysis to spot the initial unauthorized commit, rather than discovering a failed or suspicious workflow run later. The entire process is automated, allowing the attackers to scale their operation efficiently across any repository accessible via a stolen GitHub token.
This campaign is a stark example of the ongoing shift in cybersecurity threats toward the software supply chain. Attackers increasingly recognize that the development pipeline is a high-value target, often less fortified than production environments. A single stolen developer token can provide extensive access, effectively acting as the keys to the kingdom. This incident follows a pattern seen in other major supply chain attacks, where the tools and processes used to build software are themselves turned into weapons. However, unlike attacks that compromise a third-party dependency or CI/CD provider, this method is more direct. It only requires one compromised credential to initiate a breach, highlighting that the security of an entire organization's codebase can hinge on the security practices of a single developer. It underscores the critical need to treat developer credentials with the same level of protection as production system passwords.
For engineering and security leaders, the key takeaway is that securing the CI/CD pipeline is no longer an optional extra but a core business necessity. The immediate priority is to ensure that all developer accounts are protected by multi-factor authentication (MFA) to prevent the initial token theft. Organizations must also implement the principle of least privilege for their GitHub tokens, using fine-grained Personal Access Tokens with short expiration dates and the narrowest possible scopes. Regularly auditing GitHub Actions logs for unusual activity, such as workflows being added or modified by unexpected users, is crucial for early detection. Looking ahead, we can expect attackers to refine this technique and apply it to other CI/CD platforms like GitLab, Jenkins, and CircleCI. The fundamental strategy of abusing trusted automation and logging features is a versatile and effective playbook that security teams must now actively defend against. As platforms like GitHub add more safeguards, the cat-and-mouse game between attackers and defenders in the software supply chain will only intensify.
Why it matters
This attack bypasses traditional secret scanning by weaponizing a trusted CI/CD feature: logs. It shows how a compromised developer token can lead to full-scale secret exfiltration from private and enterprise repositories, turning an everyday development tool into a major security liability.
Business impact
A breach of repository secrets like API keys and credentials can lead to catastrophic data breaches, service disruptions, and significant financial loss. This attack vector increases the risk profile for any company using GitHub, requiring immediate review of CI/CD security posture.
⚡ Action needed
Immediate review of GitHub Actions permissions and audit logs is required. Teams should rotate potentially exposed credentials and implement stricter token access policies to mitigate this active threat.
Action checklist
- 1Audit GitHub Actions logs for unexpected workflow runs or suspicious script outputs.
- 2Enforce multi-factor authentication (MFA) for all GitHub accounts to prevent token theft.
- 3Rotate all secrets, API keys, and credentials stored in your GitHub repositories immediately.
- 4Review and restrict which users and services have write access to your repositories.
- 5Use fine-grained Personal Access Tokens (PATs) with limited scopes and short expiration dates.
- 6Consider using a dedicated secrets management solution instead of GitHub secrets for critical credentials.
Tags
Related on Notifire
Related stories
Primary source: The Hacker News
