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.
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.
No single signal identifies this campaign; the accounts are built to survive a glance. What does not survive is the combination:
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.
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.