FakeGit Hits 17,610 GitHub Repos: Re-aiming Evades Takedowns

The FakeGit malware campaign reactivated on Oct. 4 with 17,610 malicious repositories. Its re-aiming mechanism renders traditional blocklists ineffective.

The FakeGit malware campaign reactivated on October 4, 2026, with a fleet of 17,610 GitHub repositories re-aimed to distribute SmartLoader and the StealC infostealer. According to an Apiiro report cited by BleepingComputer, the operators created no new repositories. Instead, they modified download links in the README files of existing projects — including forks, release assets, and issue attachments. This tactic evades URL-based takedown systems and makes selective DNS blocking of the threat impractical.

Key Takeaways

Over 13,000 repositories were re-aimed in 34 hours starting October 8, 2026, peaking at 2,999 re-aims per hour.
97% of sampled commits touched only the README, and 88% pointed the download button to a ZIP that installs SmartLoader.
At least 700 compromised accounts appear legitimate; 71% of the fleet was absent from URLhaus before the Apiiro report.
Malicious archives reside in forks, older files, release assets, issue attachments, and separate hosting repositories, making reactive removal structurally insufficient.

The Re-aiming Mechanism: Resilience by Design

FakeGit operators adopted a tactic Apiiro calls "re-aiming": rather than generating new repositories — an operation that would require fresh accounts and attract detection systems — they modified the README files of projects already on the platform. These projects, in some cases forks of legitimate software, in others historical repositories of real developers, were converted into entry points for the payload.

The modification is minimal and targeted. Ninety-seven percent of sampled commits affected only the README, altering the download button or link to point to a ZIP archive hosted elsewhere on the same GitHub infrastructure. Eighty-eight percent of these ZIPs install SmartLoader, a downloader that in turn distributes StealC. The compromise chain therefore spans at least two stages: the README as lure, the ZIP as first-stage, SmartLoader as second-stage, and StealC as final payload.

The critical detail is payload distribution. According to Apiiro, cited by BleepingComputer, malicious archives reside in "forks, older files, release assets, issue attachments, and separate hosting repositories." This fragmentation means removing a single file does not disarm the compromised repository: the operator can immediately re-aim the link to a backup copy, preserving the social-engineering infrastructure.

Speed and Scale: 2,999 Repos Per Hour

The campaign achieved exceptional proliferation velocity. Between October 8 and 9, 2026, FakeGit re-aimed over 13,000 repositories in a 34-hour window, peaking at 2,999 operations per hour. This cadence rules out direct human intervention in modifying individual READMEs; the operation is automated, likely via compromised tokens or sessions of legitimate accounts.

At least 700 of the involved accounts appear to belong to real developers. The source does not specify the method of initial compromise for these accounts, nor how many have been reclaimed by their legitimate owners or remain under campaign operator control. This ambiguity complicates any clean classification of repositories as "good" or "bad" based solely on account identity.

"No one had to create a single new repo. The fleet was already there. It was just re-aimed." — Apiiro researchers, via BleepingComputer

The Structural Failure of Perimeter Defenses

The Apiiro report highlights an architectural limit of traditional defenses: 71% of the fleet was absent from URLhaus, the URL-based malware detection database, before the analysis was published. This gap does not stem from indexing delays but from the nature of the hosting itself: GitHub is not a generic domain that can be selectively blocked at the DNS level.

A domain-level block of github.com would cut off access to the entire platform, an unacceptable impact for millions of developers and CI/CD pipelines. At the same time, blocking individual files on a domain that uses HTTPS with dynamic IP sharing is technically impractical for most enterprise security infrastructures. The researchers' comment is explicit: a domain-level DNS blocklist cannot block a single file on GitHub without blocking GitHub entirely.

This condition transforms the world's largest distributed hosting platform into a single point of failure for the software supply chain. The trust developers place in GitHub — legitimacy by association, community visibility, forks and stars as reputation indicators — is weaponized against them. The campaign exploits precisely this asymmetry: the cost of manually verifying every repository far exceeds the cost of a single click on an apparently authoritative README.

Escalation to AI Skills and MCP Servers

The campaign is not limited to traditional software. In a July 2026 report from Island, 800 malicious repositories masqueraded as AI skills or MCP (Model Context Protocol) servers, exploiting the wave of AI tool adoption in development workflows. This evolution indicates precise target awareness: developers rapidly integrating new AI capabilities are less likely to verify the provenance of repositories apparently linked to emerging ecosystems.

The data is not updated to the October reactivation, but the pattern aligns with FakeGit's logic: strike high-velocity adoption segments where community curation is thinner and prototyping pressure is highest. An MCP server impersonator has an advantage over a fake of a historic JavaScript library: the target audience is less familiar with official distribution channels and more inclined to follow links from documentation or tutorials.

Why It Matters

The dossier does not specify corrective measures taken by GitHub or law enforcement interventions against the campaign operators. No infrastructure overlaps linking FakeGit to other publicly tracked groups emerge. The method of initial compromise for the 700 legitimate-appearing accounts is undocumented: it could stem from credential stuffing, targeted phishing, or purchase of sessions on underground markets, but the brief provides no evidence favoring any of these hypotheses.

The source does not quantify the number of downloads of the SmartLoader/StealC payloads, nor the volume of data exfiltrated via the infostealer. The current status of any takedown actions on the 17,610 identified repositories is undocumented, as is whether GitHub has implemented specific detections for the re-aiming pattern described by Apiiro.

The terminal discrepancy between "pushed" (BleepingComputer's language for the 13,000 repositories) and "re-aimed" (Apiiro's technical explanation) leaves a margin of ambiguity: push implies an active commit operation, while re-aiming could also occur via modifications to release metadata or redirects at the issue-attachment level, without necessarily generating commits visible in standard logs. The brief does not clarify whether Apiiro normalized this terminology or whether the two verbs describe distinct phases of the same operation.

Frequently Asked Questions

What is SmartLoader and what is its relationship to StealC?

SmartLoader is the initial payload identified in the FakeGit compromise chain. According to sources, SmartLoader distributes "other malware, including the StealC infostealer." The dossier does not specify whether SmartLoader distributes StealC exclusively or other payloads, nor does it provide technical details on the loading mechanism.

Can I identify a FakeGit repository by analyzing the README alone?

Ninety-seven percent of sampled commits touched only the README, but this figure describes the observed pattern, not an invariant. The source provides no specific signatures or automatable indicators of compromise beyond analysis of the download link and its destination. The nature of re-aiming implies that a previously clean README can become malicious without altering the file's visual structure.

Why aren't the repositories removed more quickly?

Reactive removal is slowed by payload distribution across forks, release assets, issue attachments, and separate repositories. Even if GitHub removes a container repository, copies of the payload remain active elsewhere on the platform. Moreover, re-aiming allows operators to instantly reactivate the social-engineering infrastructure without rebuilding the fleet from scratch.

Sources

Information is based on the cited source and current as of publication.

Fonti

Sources and references

Get DeafLetter