A supply chain attack is actively harvesting credentials and sensitive data from thousands of developer repositories. The attack uses Gheist, a tool designed to exploit exposed GitHub tokens, turning routine code pushes into data exfiltration events. If your team stores secrets in environment variables or commits tokens to repos, you're at risk.
What Happened
Attackers are scanning public and private repositories for exposed GitHub personal access tokens (PATs) and OAuth tokens. Once they find a valid token, they use it to access additional repositories the token owner can reach, extract cloud credentials, API keys, and other secrets, then pivot to connected systems. This attack is compromising thousands of developer repositories.
The attack doesn't exploit a GitHub vulnerability. It exploits how your team handles tokens.
Timeline
This is an ongoing campaign with a repeatable pattern:
- Initial exposure: Developer commits code containing a token (in a config file, environment variable, or hardcoded string).
- Discovery: Attacker scans GitHub for token patterns using automated tools.
- Validation: Attacker tests the token against GitHub's API to confirm it's active.
- Lateral movement: Using the compromised token, attacker accesses other repositories the token owner can reach.
- Exfiltration: Attacker extracts secrets, credentials, and sensitive data from accessible repositories.
- Persistence: If the token isn't revoked, the attacker maintains access indefinitely.
The gap between exposure and exploitation can be minutes. Public repository scans happen continuously.
Which Controls Failed
Secrets never reached a vault. Your developers are committing tokens directly to repositories instead of using secret management systems. This violates the basic principle that credentials should never appear in source code.
No pre-commit scanning. Your CI/CD pipeline isn't blocking commits that contain token patterns. Secret scanning should fail the build before code reaches the remote repository.
Token permissions were too broad. The compromised tokens likely had read/write access to multiple repositories when they only needed access to one. The principle of least privilege wasn't applied.
No token rotation policy. Tokens that should expire after 30 or 90 days remained valid indefinitely. Without forced rotation, a single exposure becomes permanent access.
Missing audit logging. Your team didn't detect unusual API activity from the compromised token because you're not monitoring token usage patterns or alerting on geographic anomalies.
What the Standards Require
NIST 800-53 Rev 5, IA-5(7): "The organization ensures that unencrypted static authenticators are not embedded in applications or access scripts or stored on function keys." Your GitHub tokens are static authenticators. Embedding them in code violates this control.
ISO/IEC 27001:2022, Annex A.8.3: Organizations must handle the lifecycle of authentication information, including secure storage and regular review. Tokens committed to repositories fail secure storage requirements.
PCI DSS v4.0.1, Requirement 8.3.2: Authentication credentials must be secured during transmission and storage. If your repositories touch cardholder data environments, exposed tokens create a direct compliance violation.
SOC 2 Type II, CC6.1: The entity implements logical access security measures to protect against threats from sources outside its system boundaries. Exposed tokens undermine boundary controls by giving external attackers authenticated access.
OWASP ASVS v4.0.3, V2.10.4: Verify that service accounts used for authentication are not default credentials. While not default credentials, hardcoded tokens function the same way: they're static, discoverable, and rarely rotated.
Lessons and Action Items
Implement pre-commit hooks today. Install git-secrets, Talisman, or GitHub's secret scanning on every repository. Configure them to block commits containing token patterns. This costs you 30 minutes per repository and prevents the initial exposure.
Move to short-lived tokens. GitHub fine-grained personal access tokens support expiration. Set maximum lifetime to 90 days. For CI/CD, use GitHub Apps with installation tokens that expire after one hour. This requires more automation but limits the blast radius.
Scope tokens to single repositories. Stop issuing org-wide tokens. Create separate tokens for each repository or workflow, with only the permissions that workflow needs. If a token leaks, the attacker gets one repo, not your entire codebase.
Rotate tokens on a schedule. Don't wait for an incident. Rotate all tokens quarterly. Track token age in a spreadsheet or secret management system. Revoke tokens that haven't been used in 60 days.
Enable GitHub Advanced Security. If you're on GitHub Enterprise, enable secret scanning and push protection. These features block pushes containing credentials and alert you to historical exposures. The historical scan will find tokens you committed years ago.
Monitor token usage patterns. Log every API call made with each token. Alert on tokens used from new IP addresses, tokens accessing repositories they haven't touched before, and tokens making bulk download requests. Your SIEM should track GitHub audit logs.
Audit your repositories now. Run a scan across all repositories looking for token patterns. Use truffleHog, GitLeaks, or GitHub's API to search commit history. Assume any token you find has been compromised. Revoke it, rotate it, and check access logs for the window it was exposed.
Train developers on token hygiene. Your team needs to understand that tokens are credentials, not configuration. Include token handling in onboarding. Make "never commit secrets" a code review requirement. When someone commits a token, treat it as a security incident, not a mistake.
The Gheist attack succeeds because token management is still treated as a developer convenience problem instead of a security control. Your standards already require you to protect these credentials. The tooling exists. The question is whether you'll implement it before or after your tokens appear in an attacker's collection.
