Supply chain security teams are confronting a wave of automated credential-harvesting campaigns targeting developer infrastructure at scale. Researchers at Wiz Research recently disclosed details on Gheist, an ongoing automated attack vector that weaponizes compromised GitHub Personal Access Tokens (PATs).
Operating without a centralized command-and-control server, Gheist systematically injects malicious workflow scripts into every accessible repository a stolen token can reach. The operation follows a parallel playbook to GhostAction, a campaign uncovered by Socket and StepSecurity that compromised roughly 1,900 accounts and targeted over 30,000 repositories.
Rather than exploiting complex software zero-days, these campaigns leverage permission abuse, turning trusted developer identities into automated vectors for secret exfiltration.
Technical anatomy | How Gheist and GhostAction operate
The attacks run through a fast, multi-stage automated pipeline. Initial access comes from infostealer logs, such as those harvested by RedLine or Vidar, or from leaked PATs. The bot then enumerates every public and private repository the stolen token has write access to, scanning existing .github/workflows/ files to identify configured secret names such as secrets.AWS_SECRET_ACCESS_KEY, secrets.NPM_TOKEN, or OpenAI API keys.
The bot creates a new branch, using names like ci-sync with randomized suffixes in the Gheist campaign, and commits a malicious workflow file with an innocuous name such as sync-check.yml, security-audit.yml, or github_actions_security.yml. Because GitHub Actions automatically masks plain-text secret strings in build output logs, the payload encodes the secrets with Base32 or Base64 before printing them to the runner console or transmitting them in unencrypted HTTP POST requests to external servers.
Any new cloud or repository tokens harvested during the run are immediately fed back into the bot network to compromise additional organization repositories. That self-propagation loop is what turns a single leaked credential into a campaign spanning tens of thousands of repos.
Why tokens, not zero-days | The attackers' advantage
The Gheist and GhostAction pattern matters because it bypasses the security industry's traditional focus on software vulnerabilities. There is no remotely exploitable bug here, no unpatched service, and no cryptographic break. The attackers simply abuse valid credentials whose permissions exceed what the account owner intended.
The same permission-abuse logic shapes the wider threat landscape. Pluto Security argues the enterprise AI workspace needs action-level enforcement precisely because employees are granting agents broad access to tools and APIs, and the Hugging Face incident showed an AI agent chain going wrong inside a vendor workflow. Credential sprawl is the shared root cause.
How to harden workflows against workflow injection
Because these attacks operate by abusing legitimate developer identities rather than breaking encryption, defending against them means hardening workflow permissions and restricting token blast radius.
Audit your workflows for injected files. Inspect .github/workflows/ directories for unrecognized additions. Watch for unexpected workflow names, unsigned commits authored under your identity, or build steps trying to run raw curl commands to unfamiliar IP addresses.
Move to fine-grained personal access tokens. Legacy classic PATs grant sweeping read and write access across every repository an account can reach. Fine-grained PATs let you specify exact repository access, granular permissions, and mandatory expiration dates of 30 or 90 days.
Restrict the default GITHUB_TOKEN permissions. In repository or organization settings under Actions, General, set default workflow permissions to read repository contents and packages. Force workflows to request write permissions explicitly in code only when required.
Require approval for external pull requests. Keep the require approval for all external contributors setting active so unvetted pull requests on fork events cannot trigger automated runners that expose environment-level production secrets.
The workflow-hardening message is a practical follow-on to the developer tooling coverage from the fall. GitHub Universe 2026 featured a session on fine-grained authorization for hosted MCP servers and the September AI infrastructure outages highlighted how fragile shared developer services can be, two signals that permission scope is the new battleground for every team running CI.
Rotate exposed credentials immediately
If you discover a malicious workflow commit on any branch, assume every repository, organization, and environment secret has been read. Deleting the malicious branch or build log does not reverse the data exposure. Rotate all associated AWS, Azure, npm, PyPI, and database keys immediately, and audit the audit trail for which tokens were used before the incident was detected.
For security teams that already handle high-visibility incidents, the response pattern is familiar: the HBO Max and Reddit credential breach earlier this year showed how quickly leaked tokens cascade across services, and the LockBit rebuild demonstrated that threat groups adapt quickly after takedowns. The common denominator in every case is credential hygiene.