17,610 fake GitHub repositories make the README a security boundary

Apiiro's October 6 investigation counted 17,610 FakeGit lure repositories serving SmartLoader. During October 4–5, the researchers observed coordinated edits across more than 13,000 repositories in roughly 34 hours. The operation did not need to create thousands of new projects. It changed where existing projects told visitors to download software.

That distinction breaks a familiar developer assumption: a repository that has existed for months is less suspicious than one created yesterday. Apiiro calls the tactic RePointing. In its sample of 441 updated repositories, 97% of changes touched only the README, and 88% pointed a download button towards a verified malicious ZIP.

Repository reputation is not artefact integrity

The attack crosses two trust boundaries. A developer first trusts the GitHub project page, then follows an installation link embedded in its documentation. The second destination can change without changing the repository's apparent history, stars or project name. Reviewing the repository URL alone does not validate the executable ultimately run.

Apiiro reports a SmartLoader chain that can lead to the StealC information stealer. The most damaging result for a development organisation may be theft of live sessions and cloud credentials, not merely loss of a workstation. An authenticated GitHub or cloud session can remain valuable even when the user originally signed in with multifactor authentication.

A trusted repository is not a trusted download when its installation path can be silently repointed.

Move checks to the moment of execution

Development teams should favour package-manager provenance, signed releases and pinned digests over README download buttons. A build process should record the exact URL, hash, publisher and version of each external artefact. Where those attributes cannot be established, the installation belongs in an isolated test environment rather than on a privileged engineering laptop.

Security operations can correlate archive downloads with command interpreters, unusual child processes and subsequent access to credential stores. The relevant hunt is a chain of events, not a blanket ban on GitHub. Blocking a shared hosting domain would damage legitimate engineering activity while still missing rehosted payloads.

Treat developer sessions as incident assets

If a developer executed a suspicious ZIP, isolate the device and assess session exposure. Revoke affected sessions and tokens, rotate relevant credentials and inspect repository pushes, CI secrets and cloud audit events. Password resets alone may leave stolen sessions or application tokens active.

The practical response to FakeGit is therefore a change in verification point. Inspect the actual artefact before execution and the identities reachable afterwards. The campaign's scale matters, but its method is the more durable warning: attackers can reuse yesterday's apparently familiar project to deliver tomorrow's payload.

Produced through Devence Lab's automated research and publishing workflow, without prepublication human review. Devence Lab retains editorial responsibility. Sources are linked; report factual errors to contact@devencelab.com.

Written by the Devence Lab research team.