FakeGit: 7,600 Malicious GitHub Repos Have Racked Up 14 Million Downloads

What Happened

Security researchers have uncovered a massive supply-chain poisoning campaign dubbed FakeGit, in which threat actors seeded 7,600 malicious GitHub repositories that collectively accumulated over 14 million downloads. The repositories are dressed up as legitimate open-source projects, tools, and libraries — the kind of repos that developers clone, CI/CD pipelines pull, and automation scripts reference without a second glance.

The payload chain involves two malware families: SmartLoader (a downloader/dropper) and StealC (a credential-stealing infostealer). SmartLoader retrieves and executes StealC on the victim machine, which then harvests browser credentials, session tokens, cryptocurrency wallets, and other sensitive data before exfiltrating it to attacker-controlled servers.

Why It Matters

Fourteen million downloads is not a rounding error — it is a supply-chain compromise at industrial scale. The attack is particularly dangerous for several reasons.

It exploits GitHub's trust model. Developers, CI pipelines, and package managers treat GitHub URLs as implicitly trustworthy. A repo with stars, forks, and a convincing README gets cloned without scrutiny. The attackers weaponize that assumption.

The infection can be completely passive. You do not have to knowingly execute a malicious script. You only need to pull a dependency that pulls another dependency that invokes SmartLoader — a transitive trust failure.

StealC specifically targets developer workstations. SSH keys, API credentials, browser-saved passwords, session cookies, and code-signing certificates are all in scope. A single compromised developer machine is a direct beachhead into production environments, source repos, and cloud accounts.

The scale implies automation. Generating and managing 7,600 repositories requires tooling, not manual effort. The campaign can be maintained and expanded cheaply, meaning the repo count will grow until the infrastructure is taken down.

This fits the same category as SolarWinds, XZ Utils, and Polyfill.io — supply-chain attacks where the infection vector is the development toolchain itself, not a phishing email or an exposed service.

What To Do

Right now:

1. Audit recent GitHub pulls. Review every repository your team cloned, forked, or ingested as a dependency in the last 90 days. Check the full BleepingComputer report for published indicators of compromise — file hashes and repo naming patterns are your starting point.

1. Scan machines that touched suspect repos. If anything in your audit looks questionable, treat that machine as potentially compromised. Run your EDR tool and look for outbound connections to known StealC C2 infrastructure.

1. Rotate credentials immediately on any affected machine. Prioritize SSH keys, GitHub tokens, AWS/cloud provider credentials, and any browser-stored passwords. Do not wait to confirm infection before rotating — treat contact as compromise.

1. Pin your CI/CD dependencies by commit SHA. Cloning by branch name (main, master) means you silently pick up whatever is at HEAD. Locking to a specific SHA breaks the attack chain even if an upstream repo is swapped.

1. Enable GitHub secret scanning and dependency review on your own repositories to catch cases where a dependency is quietly replaced going forward.

Treat every GitHub repository — regardless of star count, age, or apparent legitimacy — as unverified until you have reviewed the code yourself. FakeGit shows that the appearance of legitimacy is trivially cheap to manufacture at scale.