Hackers Compromise 790 GitHub Repositories to Steal Cloud Credentials and AI API Keys

GhostAction campaign compromises 790 GitHub repositories

A campaign dubbed GhostAction has placed malicious GitHub Actions workflows in 790 repositories, creating a risk that cloud credentials, package-publishing tokens, and AI service keys could be exposed.

That figure is OpenSourceMalware’s count of publicly recoverable, validated repositories as of October 9, 2026. It does not mean every listed repository leaked credentials or experienced confirmed misuse.

The attackers exploit trusted developer accounts. With write access to a maintainer’s repository an attacker can add a workflow that runs on push or when triggered manually.

Such a workflow can access secrets available to Actions runs, turning a compromised account into a path to cloud environments, package registries, and other projects.

Researchers at OpenSourceMalware discovered this stage while investigating a malicious PyPI package named claudecord and assisting its maintainer. They uncovered the malicious workflow and traced related activity across hundreds of repositories.

Hackers hijack 790 GitHub repositories

The newer malicious workflow does more than read selected GitHub Actions secrets. It scans repository files for strings that resemble credentials — including AWS access keys and tokens for GitHub, GitLab, Google, Slack, SendGrid, OpenAI, Anthropic, and OpenRouter.

It also searches reachable Git history, since keys removed from the current working tree may still appear in older commits.

To retrieve that history the workflow performs a full fetch (fetch-depth: 0). It then searches for credential-like patterns and, in some cases, extracts nearby lines around AWS key IDs for added context.

Those surrounding lines can include matching secret values or other details about an account or service, meaning the workflow can collect more than isolated key strings.

The workflow transmits the gathered data to attacker-controlled infrastructure over plain HTTP. Because the exfiltration originates from a CI runner, the traffic can look like normal build activity unless defenders review workflow changes and outbound connections.

For background on previous activity attributed to GhostAction, see Cyber Security News’ coverage of an earlier GhostAction supply-chain campaign. The campaign appears to have expanded over time.

GitGuardian reported 772 affected repositories between August 31 and September 30, 2026. OpenSourceMalware’s subsequent review recovered 790 repositories through October 9, including some that may no longer be publicly visible.

In a separate burst on October 8, Socket and StepSecurity tied activity across 346 repositories to two compromised accounts. These different reports refer to distinct time windows and evidence sets and should not be summed together.

That October 8 activity affected repositories owned by the kitao and henrywoo accounts and included Uber’s uber/athenadriver. The campaign reached active projects, forks, and repositories dormant for years, consistent with automated discovery of repositories writable by the compromised accounts.

Socket and StepSecurity reported that some of the workflows ran successfully, but as of October 9 they had not observed malicious PyPI or crates.io releases tied to that burst.

Why removing the workflow is not enough

A workflow that has already run can expose credentials even if the workflow file is later deleted. Deleting the workflow does not revoke a stolen GitHub token, invalidate cloud or publishing keys, or remove credentials from past commits.

Teams should preserve relevant workflow files, run logs, commits, and audit records; revoke the account credentials that allowed the changes; and rotate every secret the workflow could have accessed. They should also review package releases, deployments, and cloud activity for the affected time frame.

Cyber Security News has previously covered GitHub Actions PyPI token theft and the financial risks from stolen AI service keys, which provide useful context.

GitHub’s guidance for secure use of Actions recommends least-privilege access, reviewing workflow code before merging, and rotating exposed secrets. Requiring approvals for sensitive workflow changes and restricting runner network access are additional mitigations.

OpenSourceMalware also flagged the domain my-github[.]com, which resolves to the campaign’s current collection IP, as a high-priority indicator. The report describes the domain as suspicious but does not assert that the GhostAction operator registered it.

A similarly named GitLab domain (my-gitlab[.]com) appears only on a watchlist and is not confirmed as campaign infrastructure. Defenders should preserve that distinction when creating alerts.

Indicators of compromise (IoCs)

Type Indicator Context
SHA-256 7fbd40446a82c77b23432c6ab73bd8595c98e90e4f4a473198b4d1256f3e8c4b claudecord version 0.3.2 artifact
IP address 193.32.204[.]199 Current collection and scanning infrastructure
URL http://193.32.204[.]199/?c=monami Newer workflow’s reported collection endpoint
URL http://193.32.204[.]199:3000/api/workflow/receive?inj=<id> Variant endpoint reported in seven repositories
Domain my-github[.]com Suspicious domain resolving to the current IP; attribution not proven
Domain pattern *.my-github[.]com Wildcard DNS; individual subdomains require corroboration
Domain my-gitlab[.]com Watchlist only; not attributed to GhostAction
Historical IPs/domains 170.39.218[.]2; 45.139.104[.]115; bold-dhawan.45-139-104-115.plesk[.]page; objective-hopper.45-139-104-115.plesk[.]page; carte-avantage[.]com; *.oast[.]fun Earlier campaign infrastructure
Workflow paths .github/workflows/github_actions_security.yml; .github/workflows/security-check.yml; .github/workflows/security-audit.yml Reported malicious workflow file paths; verify file contents and behavior
Text markers AKIA_CTX_START; AKIA_CTX_END; send-secrets; Prepare Cache Busting; git log -p --all 2>/dev/null | head -200000; curl -s -m 20 -X POST --data-binary Payload and collection markers identified in the report

Note: IP addresses and domains are intentionally defanged (for example, using [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat-intelligence platforms such as MISP, VirusTotal, or your SIEM.

Reminder: Update defenses against new malware promptly and integrate threat intelligence feeds with data from your SOCs.

spot_img

More from this stream

Recomended