Hackers Used 10,000 Fake GitHub Repositories to Spread Trojan Malware

A researcher has uncovered a large malware distribution campaign on GitHub involving roughly 10,000 repositories that copied legitimate projects and pushed users toward Trojan-laced ZIP archives.

The findings were published by security researcher Orchid, who first noticed a copied version of their own GitHub project appearing in search results. The cloned repository used the same name, description, commit history, and contributor metadata, but its README had been changed to include a download link to a ZIP archive.

The campaign does not appear to rely on compromising the original repositories. Instead, attackers create separate lookalike repositories that mimic real projects, then modify the README file to direct users to malware.

Fake Repositories Copied Real Projects

The cloned repositories were designed to look trustworthy at a glance. They preserved source code, commit history, and contributor information, which could make developers believe they were looking at the original project or a legitimate mirror.

The malicious change usually appeared in the README file. Attackers replaced useful project documentation or added prominent download links that pointed to ZIP archives containing Windows malware components.

The researcher also published a public detection project called Git Malware Finder, which was built to identify suspicious repositories by analyzing GitHub event patterns and then inspecting repositories that matched the campaign’s behavior.

How the GitHub Malware Campaign Worked

Stage	What attackers did	Why it worked
Repository cloning	Copied legitimate projects into new repositories.	The copies looked credible because they retained code and commit history.
README modification	Added or replaced README content with download links.	Users were pushed toward ZIP archives instead of normal releases or package managers.
Archive delivery	Distributed ZIP files containing scripts, executables, and DLLs.	The archive format helped bundle several malware components together.
Search visibility	Targeted new or low-traffic projects that could surface in niche searches.	Lookalike repositories could appear in search results for specific project names.
Repeated updates	Pushed recurring README updates, often with similar commit names.	The activity may have helped maintain visibility or refresh malicious links.

Orchid used GH Archive, a public archive of GitHub event data, to narrow the search. The researcher initially focused on repositories with repeated push activity, then refined the search after finding that some malicious repositories updated less often than expected.

According to the report, about 16 million commit pushes from a five-day period were analyzed. The first filtering step found about 3,000 repositories with frequent update patterns, but later adjustments led to a much larger set of roughly 10,000 repositories matching the malicious pattern.

The public Git Malware Finder repository also includes a list of thousands of suspicious repositories found by the script. Orchid said GitHub removed many of the listed repositories after the findings became public, although newly found copies reportedly remained active later.

Trojan ZIP Archives Were the Main Payload

The ZIP archives followed a consistent structure. Orchid said the archives often contained a command script, an executable such as a loader or LuaJIT binary, a random text-like file, and a Lua DLL.

The researcher also observed a detection gap. Submitting only the archive link to VirusTotal returned no detections, while uploading the actual ZIP archive revealed Trojan malware. This suggests the campaign benefited from tools or workflows that check URLs but do not inspect the downloaded archive itself.

Earlier research by HexaStrike documented a similar campaign involving 109 fake GitHub repositories across 103 accounts. That campaign delivered a LuaJIT-based SmartLoader stage and a follow-on StealC payload.

Earlier Reports Point to the Same Pattern

Research source	What it found	Why it matters
Orchid	Roughly 10,000 repositories matching the Trojan ZIP distribution pattern.	Shows the campaign may be much larger than earlier reports suggested.
HexaStrike	109 fake repositories distributing SmartLoader and StealC.	Provides malware-level analysis of a related fake-repository campaign.
Artem Golubin	More than 100 malicious repositories using similar ZIP download lures.	Shows the technique had already been visible before the latest large-scale count.
GitHub Community	Developers reported copied repositories with changed README download links.	Shows maintainers had already noticed the abuse pattern.

Security researcher Artem Golubin also reported an ongoing rise in malicious repositories on GitHub in March 2026. The Rushter analysis described fake repositories that mimicked legitimate projects but replaced normal release information with links to suspicious Windows binaries.

A GitHub Community thread from May 2026 showed similar complaints from Orchid, who described repositories whose README files were constantly edited and whose download links changed over time. The GitHub Community discussion included examples of copied projects and README links to ZIP archives.

Together, these reports suggest the campaign was not a one-off incident. It appears to be part of a broader pattern where attackers abuse trusted developer platforms, copied repository metadata, and search visibility to push users toward malware.

Why Fake GitHub Repositories Are Dangerous

GitHub users often trust repositories because they see familiar names, contributor profiles, commit histories, and realistic project structures. Attackers exploit that trust by keeping most of the copied project intact and changing only the parts that influence downloads.

This makes the attack especially risky for developers, students, security researchers, and AI coding agents that search for niche repositories. A user who only skims the README may not notice that the repository owner is different or that the download flow no longer matches the original project.

HexaStrike’s report also showed why the payload side matters. In its analyzed samples, the fake repositories delivered a loader that could hide execution, resolve command-and-control infrastructure, collect system data, and support follow-on payload execution.

What Developers Should Check Before Downloading

• Check the repository owner and compare it with the official project website or package page.
• Avoid ZIP archives linked from a README when the project normally uses GitHub Releases, npm, PyPI, Homebrew, or another official package channel.
• Review recent commits, especially README-only updates that add download buttons or archive links.
• Be cautious if documentation was removed and replaced with generic download instructions.
• Scan downloaded archives, not only the URL that points to the archive.
• Do not run scripts, installers, or executables from copied repositories without verifying the source.
• Report lookalike repositories through GitHub Support when they impersonate real projects or distribute malware.

Organizations should also monitor developer workstations for suspicious archive extraction followed by script execution. ZIP files that contain a command script, unsigned executable, and bundled runtime DLL should receive extra scrutiny.

Security teams can also use the public GitHub timeline data archived by GH Archive to look for abnormal repository update patterns, repeated README-only changes, and copied projects that suddenly introduce external download links.

The GitHub Community thread shows that maintainers have already raised concerns about this abuse pattern, but repository removal can lag behind new clone creation. That makes user caution and internal controls important.

Platform Detection Remains a Challenge

The campaign highlights a difficult problem for code-hosting platforms. Fake repositories can mimic legitimate development behavior closely enough to avoid simple automated rules, especially when the source code itself is mostly copied and the malicious content is hidden behind download links.

The earlier research also noted that some suspicious repositories had been active for months, with README files repeatedly updated to improve visibility or refresh links.

For GitHub and other platforms, scalable detection may require combining several signals: repository age, owner reputation, copied commit histories, README-only changes, ZIP links, executable content, unusual topics, and repeated clone patterns across unrelated accounts.

Developers Should Treat GitHub Downloads as Untrusted by Default

GitHub remains a central part of the open-source ecosystem, but this campaign shows that a repository page alone does not prove trust. Attackers can copy names, descriptions, commit history, and contributor metadata to make a malicious repository look real.

The safest approach is to verify the publisher, use official release channels, avoid unexpected ZIP downloads, and inspect archives before running any file. Teams should also train developers to recognize copied repositories and report them through the GitHub abuse reporting flow.

Orchid’s findings show how easily open-source trust signals can be reused by attackers. The campaign does not need to compromise a popular project to create risk. It only needs users, search engines, or automated tools to land on the wrong copy.

FAQ