CyberSecurityNews

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


A campaign called GhostAction has placed malicious GitHub Actions workflows in 790 repositories, putting cloud credentials, software-publishing tokens, and AI service keys at risk.

The total is OpenSourceMalware’s count of publicly recoverable, validated repositories through October 9, 2026; it is not a claim that every repository leaked credentials or suffered confirmed misuse.

The campaign abuses trusted developer accounts. Once an attacker can write to a maintainer’s repositories, they can add a workflow that runs when code is pushed or when someone starts it manually.

This can expose secrets available to the workflow, turning a stolen account into a route toward cloud systems, package registries, and other projects.

Researchers from OpenSourceMalware identified this latest stage while investigating a malicious PyPI package called claudecord and helping its maintainer respond. They found the malicious workflow and traced related activity across hundreds of repositories.

Hackers Hijack 790 GitHub Repositories

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

It also scans reachable Git history, where a key removed from the current version of a file may still appear in an older commit.

To obtain that history, the workflow uses fetch-depth: 0. It then looks for credential-like patterns and, in some cases, gathers nearby lines around AWS key IDs.

Those lines may contain useful context, such as a matching secret key or details about an account or service. The same collection steps can therefore expose more than a standalone key string.

The workflow sends the collected data to attacker-controlled infrastructure over plain HTTP. Because the transfer occurs from a CI runner, it can resemble routine build activity unless defenders inspect workflow changes and outbound network traffic.

For background on a previous GhostAction wave, see Cyber Security News’ GhostAction supply chain campaign report. The number reflects a campaign that has grown over time.

GitGuardian reported 772 affected repositories between August 31 and September 30, 2026. OpenSourceMalware’s later review recovered 790 through October 9, including repositories that may not remain publicly visible.

In a separate October 8 burst, Socket and StepSecurity reported activity across 346 repositories tied to two compromised accounts. These figures cover different periods and evidence sets, so they should not be added together.

That burst included repositories owned by the kitao and henrywoo accounts, as well as Uber’s uber/athenadriver. The activity reached active projects, forks, and repositories that had been dormant for years, suggesting automated discovery of repositories the compromised accounts could change.

The report says some workflows ran successfully, but it had not found malicious PyPI or crates.io releases linked to this latest burst as of October 9.

Why removing the workflow is not enough

A successful workflow run may expose credentials even if the file is later deleted. Removing it does not revoke a stolen GitHub token, invalidate cloud or publishing keys, or remove credentials from old commits.

Teams should preserve relevant workflow files, run logs, commits, and audit records, then revoke the account credentials that enabled the changes and rotate every secret the workflow could access. They should also check package releases, deployments, and cloud activity from the affected period.

For related context, Cyber Security News has covered GitHub Actions PyPI token theft and the financial risk of stolen AI service keys.

GitHub’s secure use guidance for Actions recommends least-privilege access, review of workflow code, and rotation of exposed secrets. Requiring approval for sensitive workflow changes and limiting runner network access can add further checks.

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

A similarly named GitLab domain is listed only as a watch item, not confirmed campaign infrastructure. Defenders should preserve that distinction when creating alerts.

Indicators of compromise (IoCs):-

TypeIndicatorContext
SHA-2567fbd40446a82c77b23432c6ab73bd8595c98e90e4f4a473198b4d1256f3e8c4bclaudecord version 0.3.2 artifact
IP address193.32.204[.]199Current collection and scanning infrastructure
URLhttp://193.32.204[.]199/?c=monamiNewer workflow’s reported collection endpoint
URLhttp://193.32.204[.]199:3000/api/workflow/receive?inj=Variant endpoint reported in seven repositories
Domainmy-github[.]comSuspicious domain resolving to the current IP; attribution not proven
Domain pattern*.my-github[.]comWildcard DNS; individual subdomains need corroboration
Domainmy-gitlab[.]comWatchlist only; not attributed to GhostAction
Historical IPs/domains170.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[.]funEarlier campaign infrastructure
Workflow paths.github/workflows/github_actions_security.yml; .github/workflows/security-check.yml; .github/workflows/security-audit.ymlReported malicious workflow paths; verify file contents and behavior
Text markersAKIA_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-binaryPayload and collection markers identified in the report

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

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.



Source link