FakeGit

Active campaign · tracked since 1 August 2026 · reviewed 1 September 2026

What this is. An active campaign in which throwaway maintainer accounts publish repositories that look ordinary and ship a trojanised release-asset ZIP. Roughly 14 million of those downloads have been observed. The payload arrives through the browser, not through git clone.

Why the download path is the whole story

Most supply-chain tooling watches package registries and dependency manifests. FakeGit does not need either. The victim is a developer who finds a repository, believes it, and presses Download ZIP — or takes a release asset from the Releases tab. Nothing is installed, nothing is resolved, no manifest is touched. By the time the archive is extracted the code is already on the machine.

That is the path RepoGates gates. It is also the reason the gate lives in the browser: a backend cannot see the click, and a CLI scanner is never invoked.

What the checks look for

No single signal identifies this campaign; the accounts are built to survive a glance. What does not survive is the combination:

What RepoGates does about it

Two things, and they are separate. The 22 checks assess the repository and return a verdict; a failing verdict holds the download and cancels it before the file reaches its final path. Independently, the campaign blocklist carries confirmed indicators — accounts, repositories, and asset hashes — and blocks them outright, ahead of the checks and ahead of an organisation's own allowlist. Every entry on that list carries its evidence and an expiry; entries that cannot be removed as fast as they were added are not entries we ship.

What it does not do

RepoGates does not stop git clone, gh, curl, npm install, go get, a Docker build, or an AI agent that fetches on its own. A browser extension cannot observe processes outside the browser. If a FakeGit repository is cloned rather than downloaded, this product is not in the path — and we would rather say so than imply cover we do not provide.