GhostAction Campaign commits maintenance accounts and inserts workflows to exfilter secrets

Security researchers have re-detected a massive credentials theft campaign that exploits open source project maintainer accounts to insert malicious workflows in GitHub repositories. According to several technical reports - including those of StepSecurity, Socket and GitGuardian -, attackers linked to the campaign known as GhostAction they committed reputable maintenance accounts and pushed a workflow file that draws secrets to an operator-controlled server. The confirmed facts include documented commitments in multiple temporary windows (e.g. 27 repositories at 13: 20 UTC on Takashi Kitao's account and 318 repositories in 16 minutes on Henry Wu's account) and the detection of hundreds of accounts and thousands of exfiltered secrets in the reporting period.

The technique is not a vulnerability in GitHub itself, but an abuse of the maintenance credentials (probably personal access tokens, PAT) to modify the default branch of projects and add a workflow that runs with the repository permits. The malicious file is presented with legitimate names such as "security-audit.yml" or "github _ actions _ security.yml" and performs four key tasks during its "Audit" step: it adds the designated secrets of the repository, seeks in the working tree credentials patterns (13 patterns associated with AWS, IA providers, registries and cloud services), scans the entire git history for previously compromised credentials and combines AWS access IDs with their secret access keys. The data collected are sent by HTTP to a hard IP (193.32.204 [.] 199), which confirms the exfiltration of unencrypted secrets.

What is proven: multiple security firms have observed the same attack flow; malicious workflows activate workflow _ dispatch and run after unfiltered puzzles, use fitch-depth: 0 to access the history, and exfilter tokens and service keys such as PyPI, npm, DockerHub, AWS, OpenAI, Anthropic, OpenRouter and Tokens from GitHub / GitLab. Public reports indicate specific figures: Socket detected more than 500 accounts that have made workflow commitments since 7 October 2026 and, in a previous sweep, GitGuardian reported 772 public repositories affected between 31 August and 30 September 2026; another count cites 817 committed repositories and 3,325 exfiltered secrets.

What is inferred but not fully proven: the exact source of the credentials used to take the accounts - the analysis points to tokens filtered in information-stealers or credentials dump loops -; although this hypothesis fits previous GhostAction patterns, there is no public tracking that demonstrates the complete chain from the initial PAT theft to the malicious commit in each affected account. There is also no public evidence, for now, of malicious packages published in records with stolen credentials - although the modification of a Docker image has been documented to include a miner in at least one case.

The practical impact for projects and organizations is direct: any secret present in the repository (either in variables of Actions, in work tree files or in old commitments) can be read and exfiltered, and thus vectors are opened to compromise CI / CD infrastructures, registrations, cloud services and developer accounts. In addition, the use of the maintainer's own identity to insert the load makes it more difficult to distinguish malicious activity from legitimate changes in surface reviews, and the presence of workflow in forks and mirrors (including private forks) amplifies the exposure surface. Socket warned that many forks in the namespace of one of the affected accounts continued to carry the malicious definition, allowing additional execution if Actions is enabled.

For developers and repository administrators the response must be immediate and practical. First, check if there is a file on any branch (including default) called "security-audit.yml" or "github _ actions _ security.yml" or any suspicious workflow added since 31 August 2026; if it appears, make a commitment. Eliminating the malicious file from all branches is not enough on its own: it is necessary to revoke the compromised credential (PAT), rotate any key or token that may have been in the repository (PyPI, npm, DockerHub, AWS, IA services, GitHub / GitLab, and other listed in the reports) and regenerate access. It is also appropriate to inspect forks and myrors - public and private forks may inherit workflow and execute subsequent shipments - and to disable GitHub Actions in repositories that do not require it.

In operational terms, review the history of Actions runs to identify unusual executions (workflow _ dispatch externally invoked, executions caused by committed account puzzles), and audit network and CI records to detect outgoing connections to suspicious addresses (e.g., the IP observed 193.32.204 [.] 199) will help to narrow reach. Running search for credentials patterns on the tree and in the git history is critical: since the workflow does fsch-depth: 0, the opponent had access to the full history. To search for involuntary secrets, you can use scanning tools such as those offered by GitHub (secret scanning) and third party products specialized in detecting secrets in repositories; GitHub documents its secret scanning capabilities on its official site.

Specific recommended actions: 1) To immediately revisit and rotate PATs, service keys and listed tokens; 2) to remove malicious workflow in all branches and forks, and to disable Actions until you confirm cleaning; 3) to activate or review approval policies for external workflows and to block automatic execution of unverified workflows; 4) to enable secret scanning and security alerts in the organization; 5) to review and audit CI / CD logos and outgoing traffic to unrecognized IPs / hosts; 6) to force 2FA and to review sessions and to review authorized applications as well as to hold private reagents and / or to deal with the associated files;

To guide incidents and mitigation, official documentation on Actions and secret scanning can be found in the resources of GitHub (https: / / docs.github.com / en / actions and https: / / docs.github.com / en / code-security / secret-scanning / about-secret-scanning). It is also useful to follow analysis of third parties such as GitGuardian, which centralize public indicators and detections (https: / / www.gitGuardian.com /). Having these standardized procedures in incident response runbooks reduces exposure time and facilitates the orderly revocation of credentials.

The fact is that this episode highlights a recurring principle of supply chain security: human accounts with large permissions are high impact vectors. While investigating the total scale and provenance of the used tokens, project managers must assume that the mere presence of a suspicious workflow implies possible exfiltration and act with the rotation of credentials and the revocation of access. Effective defenses combine prevention (permit limitation, workflow review policies), detection (secret scanning, action monitoring) and rapid response (rotation and cleaning), and in this particular case are the only measures that cut the attacker's access to the already replicated secrets.