10,000 GitHub Repositories Are Distributing Trojan Malware

What Orchid Found

The Orchid Files post is dated June 18, 2026, and the Hacker News thread drew sustained traffic for days after publication.^[3] The headline number from Orchid's analysis: 10,000 GitHub repositories match a five-point pattern that strongly correlates with Trojan distribution.

The pattern, paraphrased from Orchid's disclosure:

1. The repository is updated frequently, between 1 and 24 times per 24-hour window.
2. The latest commit only modifies the README file.
3. The README includes a link to a zip archive.
4. The repository is not a fork; it is a fresh top-level repo.
5. The commit history is copied wholesale from another repository (so the repo appears to have been around for a while, not just dropped yesterday).
6. The contributor list includes the original author of the legitimate repo, so clicking through the contributors shows real, established accounts.

Of the 40,000 repositories on GitHub that update this frequently, 10,000 (25 percent) match every element of the pattern. Each of those 10,000 repositories links to a zip archive. Each of those zip archives contains a Windows executable that VirusTotal's multi-engine scan flags as Trojan-class malware.^[1]

What Is in the Zip

Orchid documents the contents of three of the linked zip archives (the example repositories are still publicly listed in the post). The zip contains four files in the typical case:^[1]

• Application.cmd or Launcher.cmd: a Windows batch script that runs the executable.
• loader.exe, luajit.exe, or another name: the Trojan payload. VirusTotal detects it as a Trojan.
• A random-named .cso or .txt: a decoy or payload-staging file.
• lua51.dll: the Lua runtime, which the loader uses to execute the script-stage of the attack.

If a victim follows the README link, downloads the zip, and runs the batch script on Windows, the loader executes. Orchid's post links a separate April 18, 2026 analysis by other researchers that documented this Trojan family, identified at the time as SmartLoader, which deployed the StealC information-stealer as its second-stage payload. The April analysis found 109 repositories distributing the malware at that time. Orchid found 10,000 in June.^[1]

The growth from 109 repositories in April to 10,000 in June is the supply-chain scale signal. Whoever is running this campaign is operating at a volume that requires a partially-automated clone-and-modify pipeline. They are not hand-crafting each repository.

Why GitHub Did Not Catch It

The pattern is detectable. Orchid found it with a single Python script that filtered GitHub's commit-push event stream from the public gharchive feed, narrowed to high-frequency-update repositories, and looked for the README-update-plus-zip-archive signature.^[1] GitHub's anti-abuse systems have access to the same event stream, plus the full commit content, plus the full repository inventory.

Three design choices by the attackers exploit GitHub's existing trust signals.

Only clone new repositories. The attackers do not target popular repositories. They clone repositories that were just created, because brand-new repositories with a few commits rank at the top of search results for low-volume search terms, the terms that someone running a specific Google query might use to find a tool or a script. By the time the original author's legitimate version accumulates enough search-engine authority to outrank the clone, the attacker has moved on.

Preserve commit history and contributor lists. A casual visitor to one of the infected repositories sees a contributor list with established accounts and a commit history that goes back weeks or months. The visitor concludes the repo is legitimate because it looks lived-in. The signal the visitor is reading is real. It is just being attributed to the wrong repository.

Use "Update README.md" as the commit name. Every malicious commit on every one of the 10,000 repositories carries the identical commit name. Orchid found this by running the search. The commit name is the most boring name in software engineering: the kind of commit you make when you fix a typo. It is a camouflage choice. Automated detection that looks for unusual commit names will not flag it.

The compounding factor is the overwriting pattern: the attacker deletes the previous commit and pushes a new one with the same name. The deletion-plus-push looks like a force-push, which is a routine operation on collaborative repositories. GitHub's anti-abuse heuristics do not flag it as suspicious because force-pushes are not, on their own, a red flag.

GitHub's Two-Month Response Time

Orchid's timeline, paraphrased from the original post:

• The first malicious repository on Orchid's project was discovered when Orchid ran a Google search for the project name and saw the attacker's clone ranking alongside the real one.
• Orchid submitted a support request to GitHub through the standard abuse-report channel.
• Two weeks passed. GitHub support did not respond.
• Orchid opened a thread on the GitHub Community Forum. Three people replied with AI-generated suggestions that did not address the problem.
• One month after that, GitHub support emailed Orchid to confirm the original two repositories had been removed.
• By that point Orchid had discovered the full 10,000-repo pattern and the rest of the campaign.
• As of the Orchid post and our verification at 22:00 UTC on June 18, GitHub has started deleting the wider set but several of the example repositories Orchid named were still online and still serving the malicious zip.^[4]

The two-month response time on a single repository, multiplied by the 10,000-repo scale of the campaign, is the structural read. The pattern is detectable. The reporting channel is functional. The throughput is the failure. GitHub's abuse-response pipeline is not designed to handle the volume of malicious content the platform is hosting.

The Structural Problem: Trust Signals as Attack Surface

GitHub's value proposition rests on a handful of trust signals that visitors use to evaluate a repository in under a minute:

• Commit history length: more commits, more legitimate.
• Contributor count: more contributors, more legitimate.
• Contributor profile age: older accounts, more legitimate.
• Search ranking: higher ranking, more legitimate.
• Star count and fork count: more engagement, more legitimate.

The Orchid campaign weaponizes each of these signals. The commit history is copied from the original repo (real signal, wrong attribution). The contributor list includes the original author (real signal, wrong attribution). The search ranking is high because the repo is new (real signal, but only because newness is what the attacker wants). The star and fork counts may be lower than the original, but most users do not click through to compare.^[1]

This is a category of attack that has no clean technical fix. The signals GitHub uses to establish trust are the same signals an attacker can copy. A platform-level solution would require either (a) cryptographically-signed repository provenance so a clone cannot inherit the original repo's trust signals, or (b) a delay before a new repository ranks in search, so an attacker cannot benefit from the ranking before they are caught. Neither solution is on GitHub's roadmap as of June 2026.

What to Do Today

If you maintain a GitHub repository, search for clones of your work that you did not create. Use a search engine to query your project name and the names of your top contributors. The first time you do this, expect to find at least one clone you did not authorize. Report it through GitHub's abuse channel and expect a 4-8 week response time. Build your own monitoring if your project is high-value; the existing reporting pipeline will not catch new clones fast enough.

If you use GitHub to find tools, scripts, or libraries for a project, do not trust commit history alone. Cross-reference the repository URL against the original author's profile (click the contributor name, confirm it is the same person). Check the date the repository was created. If the repository is less than a month old but has commits going back a year, the commit history was copied. Walk away.

If you are on a Windows machine and you downloaded a zip from any GitHub repository link in the last year, scan it with VirusTotal before extracting. The Trojan in the linked zip is detected by multiple VirusTotal engines as of June 18, 2026.

What to Watch

Four developments will tell whether this is the campaign that forces GitHub to redesign its anti-abuse pipeline or the one that gets handled as a routine cleanup.

GitHub's full-deleted count. GitHub has started deleting the 10,000 repositories Orchid identified. If the deletion completes within days, the response was already in motion before the disclosure. If deletion drags for weeks, the campaign is bigger than the 10,000 Orchid found. Watch for GitHub's first public statement on the campaign.

The behavior of the .exe payload. Orchid's post links the April analysis that identified the malware family as SmartLoader, with StealC as the second-stage payload. The full SmartLoader + StealC chain is a credential and crypto-wallet stealer. If the June variant has been updated since April, the IOC list (file hashes, network indicators, C2 endpoints) needs to be regenerated. Watch for any follow-up technical analysis from a named security vendor.

The prior-report Reddit post. Orchid's post links a Reddit thread from February 2025 that warned about the same scheme. That thread did not gain traction. If the Reddit thread has been updated since Orchid's disclosure, it becomes the primary historical record for the campaign's origin date.

The cloaning-pipeline vendors. A campaign this large requires tooling. The attackers are running an automated pipeline that clones a repo, rewrites the README to add the zip link, and pushes the result. Watch for any security-vendor write-up that fingerprints the cloaning tool. If the tool is open-source (a malware-as-a-service offering, for example), the campaign volume will continue to grow.

Related Coverage

• GitHub Hacked Through a VS Code Extension Live for 11 Minutes The TeamPCP / Mini Shai-Hulud attack chain. The same trust-by-extension model, applied to the VS Code Marketplace instead of repository ranking. GitHub's auto-update delivered a malicious extension to 2.2 million developer machines in under 11 minutes.
• Supply Chain Attacks 2026: Your Vendors Are the Weak Link The broader pattern. Third-party vendor breaches doubled to 30 percent of all breaches in 2026. The 10,000-repo GitHub campaign is the consumer-facing supply-chain attack that the third-party-vendor frame does not yet capture.
• North Korea Hijacked the Axios npm Package. Your App Might Be Compromised. The state-sponsored npm-side parallel. UNC1069 used a deepfake video call to compromise the Axios maintainer. The GitHub repo-cloaning campaign uses a different entry point but the same downstream payload pattern: legitimate trust signals + malware in the deliverable.
• LinkedIn Recruiter Posts Fake Job to Plant Backdoor in npm The npm-side social-engineering parallel. A recruiter reached out to a package maintainer with a fake job offer, used the interview as a way to plant a backdoor in the package. The GitHub repo-cloaning campaign is the same social-engineering template applied to repository ranking instead of package maintainers.
• GitHub Copilot Safety Refusals Fail 100% in Coding Workflows, Turing Finds The same GitHub trust surface that gets weaponized by repository cloaning here gets weaponized from inside the Copilot model itself, with 100% of workflow prompts bypassing chat-level refusal.

Sources

1. Orchid Files: I discovered a large-scale malware distribution on GitHub (theorchid's primary blog post, June 18 2026, with the 10,000-repository count, the 25-percent hit rate on high-frequency-update repos, the full five-point detection pattern, the example repository list, the VirusTotal Trojan detection, the SmartLoader/StealC cross-reference, and the Reddit February 2025 prior report)
2. Hacker News: I found 10k GitHub repositories distributing Trojan malware (HN id 48583928, posted June 18, 2026)
3. GitHub lucasheriq4374/welink repository (one of the example repositories Orchid cited as containing the Update README.md commit + linked zip archive pattern)
4. Hacker News comment on the Orchid disclosure thread (HN comment id 48597391)
5. Hacker News comments on the Orchid disclosure thread (HN comment id 48598630)
6. Hacker News comment on the Orchid disclosure thread (HN comment id 48597808)