Gheist: How Attackers Used Stolen GitHub Tokens to Silently Drain Enterprise Secrets via Actions Logs
Executive Summary
Beginning September 15, 2026, an automated threat campaign tracked as Gheist began exploiting stolen GitHub personal access tokens to plant malicious GitHub Actions workflows inside private repositories and GitHub Enterprise environments. The attacker tool created ci-sync- branches, committed a workflow that printed all accessible secrets encoded in base32 to bypass GitHub's masking, downloaded the logs via API, and deleted the run within seconds—leaving no outbound connection to block. Wiz researchers recovered over 13,500 planted branches across more than 850 compromised accounts, ranging from personal projects to enterprise organizations, with post-compromise activity including AWS Secrets Manager enumeration and lateral credential reuse.
Gheist exemplifies an accelerating class of CI/CD supply-chain attacks where the pipeline itself becomes the exfiltration channel. With tokens sourced from infostealer markets and prior supply-chain breaches, attackers require no vulnerability—only write access. As enterprises expand GitHub Actions usage for cloud deployments, the blast radius of a single stolen token now reaches production cloud credentials, making pipeline identity governance a board-level concern.
Why This Matters Now
GitHub Actions is now a primary deployment pathway for cloud workloads, meaning a single stolen write-access token can silently harvest every production secret an organization has stored—without triggering traditional perimeter controls. Gheist remained active and evolving through late October 2026, GitHub's protective hold does not cover private repos or Enterprise Server, and token sources include active infostealer markets, making exposure ongoing and widespread.
Attack Path Analysis
The Gheist campaign used stolen GitHub personal access tokens, sourced from infostealer logs and prior supply-chain breaches, to programmatically create malicious workflow branches in private GitHub repositories and GitHub Enterprise environments. The attacker tool automated branch creation, workflow execution, log download, and run deletion entirely within GitHub's own infrastructure, bypassing traditional network egress controls and exfiltrating secrets encoded in base32 through GitHub's API before rotating to cloud credential enumeration via AWS Secrets Manager.
Kill Chain Progression
This analysis maps confirmed threat intelligence to the full cloud kill chain to show where defensive gaps would emerge as an attack progresses.
Initial Compromise
Description
Attackers obtained valid GitHub personal access tokens from infostealer malware logs and secrets exposed in earlier supply-chain attacks such as the Trivy scanner compromise. These tokens provided write access to targeted private repositories and GitHub Enterprise organizations without any vulnerability exploitation or phishing at the target.
MITRE ATT&CK® Techniques
Steal Application Access Token
Scheduled Task/Job: Cron
Unsecured Credentials: Credentials In Files
Command and Scripting Interpreter: Unix Shell
Impair Defenses: Disable or Modify Cloud Logs
Exfiltration Over Web Service: Exfiltration to Code Repository
Supply Chain Compromise: Compromise Software Dependencies and Development Tools
Valid Accounts: Cloud Accounts
Potential Compliance Exposure
Mapping incident impact across multiple compliance frameworks.
NIST SP 800-53 Rev 5 – Account Management, Access Enforcement, and Authenticator Management
Control ID: AC-2, AC-3, IA-5
PCI DSS 4.0 – Protection of Stored Account Data, Strong Authentication, and Risk Management
Control ID: Requirement 3.5, Requirement 8.3, Requirement 12.3
DORA (EU Digital Operational Resilience Act) – ICT Security Controls, Threat Detection, and Incident Reporting
Control ID: Article 9 (ICT Security), Article 10 (Detection), Article 17 (ICT-related Incidents)
NIS2 Directive – Supply Chain Security and Incident Notification Obligations
Control ID: Article 21 (Cybersecurity Risk Management), Article 23 (Incident Reporting)
CISA Zero Trust Maturity Model 2.0 – Identity Assurance, Network Segmentation, and Application-Level Least Privilege
Control ID: Identity Pillar: Visibility & Analytics, Networks Pillar: Micro-Segmentation, Applications Pillar: Least Privilege Access
NYDFS 23 NYCRR 500 – Access Privilege Management, Security Awareness, and Incident Response Planning
Control ID: Section 500.7 (Access Privileges), Section 500.14 (Training), Section 500.16 (Incident Response)
Sector Implications
Industry-specific impact of the vulnerabilities, including operational, regulatory, and cloud security risks.
Computer Software/Engineering
Software engineering teams face critical supply-chain credential theft risk as Gheist exploits stolen GitHub tokens to exfiltrate CI/CD pipeline secrets, bypassing egress controls since exfiltration occurs entirely within GitHub's own infrastructure.
Information Technology/IT
IT organizations using GitHub Enterprise Server lack workflow approval safeguards, exposing AWS Secrets Manager credentials and OIDC tokens via lateral movement through compromised automation accounts and self-hosted runners.
Financial Services
Financial sector CI/CD environments risk production credential exfiltration through base32-encoded secrets bypassing GitHub masking, with compliance exposure across PCI 4.0, NIST 800-53 egress and privilege escalation controls.
Computer/Network Security
Security product pipelines are directly implicated via the compromised Trivy vulnerability scanner supply-chain origin, with 850-plus affected accounts threatening integrity of security tooling and cloud firewall enforcement capabilities.
Sources
- Gheist Uses Stolen GitHub Tokens to Steal Private Repository Secrets via Actions Logshttps://thehackernews.com/2026/10/gheist-uses-stolen-github-tokens-to.htmlVerified
- Gheist: Attempted Scaled Abuse of Stolen GitHub Tokens Stumbleshttps://www.wiz.io/blog/gheist-attempted-scaled-abuse-of-stolen-github-tokens-stumblesVerified
- GitHub Actions: Holds Potentially Malicious Workflows for Approvalhttps://github.blog/changelog/2026-07-28-github-actions-holds-potentially-malicious-workflows-for-approval/Verified
- GitHub Documentation: Security Hardening for GitHub Actionshttps://docs.github.com/en/actions/reference/security/secure-useVerified
- GhostAction: GitHub Actions Supply Chain Attack Returnshttps://blog.gitguardian.com/ghostaction-github-actions-supply-chain-attack-returns/Verified
- GitHub Documentation: About OIDC in GitHub Actionshttps://docs.github.com/en/actions/reference/security/oidcVerified
Frequently Asked Questions
Cloud Native Security Fabric Mitigations and ControlsCNSF
Based on the attack progression modeled above, these are the defensive controls that would constrain each stage.
The Gheist campaign exploited trusted GitHub tokens to move laterally from CI/CD pipelines into cloud environments, a pattern where Aviatrix Zero Trust CNSF's segmentation and east-west enforcement would likely reduce the attacker's ability to pivot from compromised workflow identities into production cloud infrastructure. By constraining reachability between CI/CD execution contexts and sensitive cloud workloads, the blast radius of a stolen token reaching AWS Secrets Manager would likely be significantly narrowed.
Control: Cloud Native Security Fabric (CNSF)
Mitigation: Workloads and cloud resources reachable from CI/CD execution contexts would likely be constrained by fabric-enforced identity-aware segmentation, reducing the set of cloud assets an authenticated but unverified workflow identity could reach after initial token use.
Control: Zero Trust Segmentation
Mitigation: Zero Trust segmentation would likely constrain the reachability of cloud workloads and IAM-accessible resources from workflow execution contexts, reducing how far a token-bearing identity could expand its privilege scope across cloud segments even after OIDC role assumption succeeds.
Control: East-West Traffic Security
Mitigation: East-west enforcement policies would likely reduce the attacker's ability to traverse freely from CI/CD execution segments into production cloud environments, constraining lateral paths between the pipeline context and sensitive cloud services like AWS Secrets Manager.
Control: Multicloud Visibility & Control
Mitigation: Multicloud visibility across cloud workload traffic flows would likely surface anomalous API call patterns and unusual inter-service communication volumes originating from workflow execution contexts, even when those calls travel over trusted SaaS channels, helping reduce the window of undetected attacker activity.
Control: Egress Security & Policy Enforcement
Mitigation: Egress policy enforcement applied to cloud workload execution contexts would likely constrain which external SaaS endpoints workflow identities are permitted to reach, reducing the set of outbound paths available for data to leave the cloud environment through non-approved API channels.
Had segmentation and east-west enforcement been applied earlier in the kill chain, the range of cloud assets reachable from the compromised workflow identities would likely have been narrower, meaning that exposed AWS credentials would have had reduced scope to enumerate production secret stores and the blast radius of any single stolen token reaching cloud infrastructure would likely have been more contained.
Impact at a Glance
Affected Business Functions
- CI/CD Pipeline Integrity and Software Delivery
- Cloud Infrastructure Access Control (AWS IAM, Secrets Manager)
- Source Code Repository Management (GitHub Enterprise)
- DevSecOps and Secrets Management
Estimated downtime: N/A
Estimated loss: N/A
Confirmed and potential exposure of GitHub repository secrets including cloud provider credentials (AWS access keys, IAM role tokens), deployment environment secrets (often production credentials), Kubernetes service account tokens, private SSH keys, process environment variables, and self-hosted runner credential files across more than 850 compromised GitHub accounts spanning personal projects and enterprise organizations. AWS CloudTrail evidence confirms that GitHub Actions workflows executed on malicious branches and assumed AWS IAM roles in at least some enterprise environments, indicating active cloud credential abuse. Secrets from GitHub Actions deployment environments, which frequently contain production-tier credentials, were also targeted. No confirmed count of organizations with successfully exfiltrated secrets has been published by Wiz as of the reporting date.
Recommended Actions
Key Takeaways & Next Steps
- • Apply Zero Trust Segmentation (CNSF) to OIDC trust policies by scoping IAM role assumption conditions strictly to protected branches and named deployment environments, preventing a planted ci-sync- branch from ever successfully exchanging a GitHub OIDC token for cloud credentials.
- • Enforce Egress Security & Policy Enforcement controls to monitor and alert on anomalous cloud API call patterns, specifically bulk enumeration of AWS Secrets Manager following an OIDC token exchange from a non-standard branch subject, closing the post-exfiltration cloud pivot window.
- • Leverage Multicloud Visibility & Control capabilities to baseline normal GitHub Actions OIDC subjects and AWS CloudTrail role assumption patterns, enabling detection of workflow runs originating from ci-sync- branches and automated flagging of runs deleted within minutes of completion.
- • Deploy East-West Traffic Security monitoring across cloud workload interactions to detect lateral credential use, specifically when credentials sourced from a GitHub Actions context are subsequently used to access Secrets Manager or other internal services from an unexpected identity or region.
- • Implement Encrypted Traffic and audit log integrity controls to ensure GitHub audit log streams and AWS CloudTrail are forwarded to an immutable, centralized platform in real time, preventing post-compromise log deletion from eliminating forensic evidence of planted workflow runs and secret access events.
