10,000 cloned GitHub repos are delivering LuaJIT loaders — why engineering teams must stop trusting repo search results
A coordinated campaign has spun up roughly 10,000 fake GitHub repositories that clone real projects’ histories while swapping in malicious ZIP links and AI-written READMEs. Engineering teams, dependency scanners, and security ops need to treat repository search results and automated dependency pulls as potential attack surfaces, not trusted signals.
Organized supply-chain mimicry, not random uploads
This is a supply-chain poisoning campaign, not isolated malware noise: attackers cloned legitimate projects, duplicated commit histories and contributor metadata, and created unique repo names and owners to look authentic. Rather than targeting high-traffic projects, they leaned on newer or niche repositories that rank higher in search for obscure dependencies, increasing the chance developers or automated tools will pick them up.
Researcher Orchid used heuristic searches—flagging repos whose README files linked to ZIP archives and displayed unusual recent commit churn—to find the campaign’s footprint. Despite reports, many of these repos persisted for months because GitHub’s API rate limits and the campaign’s volume make blanket takedowns slow and incomplete.
Technical chain: SmartLoader + modular stealers
The malicious ZIPs contain a LuaJIT-based loader called SmartLoader that runs obfuscated Lua scripts and then fetches secondary payloads. Confirmed payloads include StealC and Lumma Stealer, both focused on exfiltrating browser data, credentials, and cryptocurrency wallets—assets attractive to highly automated theft operations.
SmartLoader’s modularity matters: it acts as a flexible initial stage that downloads updated payloads from attacker-controlled servers, and the operators rotate download links while synchronizing repo updates. The campaign also integrates blockchain-based command-and-control mechanisms, complicating takedown and attribution work because C2 endpoints can be less static and harder to enumerate.
Why platform limits and AI tooling make this effective
Two mechanisms amplify the campaign’s reach: developer trust in GitHub search and automation, and AI-assisted dependency resolution that blindly follows repo manifests or Releases sections. Attackers exploited both by placing malicious deliverables where maintainers and dependency crawlers expect code—README links, Releases, and download artifacts—so automated agents can pull and execute them without human review.
Operational constraints on GitHub matter: API rate limits and the scale of ~10,000 repositories slow automated scanning, while frequent, scripted repo updates (deleting and re-adding commits) are used to evade heuristics. The combination means detection is a moving target; platform policy changes will likely trigger rapid campaign adaptation, so the next checkpoints are how quickly GitHub tightens creation/modification filters and how attackers respond.
Practical checkpoints and quick detection rules
Security teams can’t wait for platform fixes. Below are compact signals and actions to triage suspicious repositories and automated pulls faster.
| Suspicious signal | Why it matters | Immediate action |
|---|---|---|
| README linking to ZIPs or external downloads | Common placement for SmartLoader ZIPs; bypasses code review | Block automated pulls of release assets; require human review and signed artifacts |
| Recent repos duplicating commit histories | Signal of cloning to inherit trust | Verify upstream origin and contributor accounts before use |
| Obfuscated Lua/JIT binaries or unusual native artifacts | Indicator of SmartLoader-style loaders | Sandbox artifacts and block outbound calls to unknown C2s, including blockchain-based endpoints |
| Frequent commit churn with deletions | Evasion tactic to avoid static heuristics | Alert on odd commit patterns and quarantine repos pending manual inspection |
These checks prioritize preventing automated systems and CI runners from pulling and executing unvetted artifacts—exactly what the campaign exploits.
Short Q&A
How bad is the scale? The investigation identified roughly 10,000 repositories; researchers warn this is likely a lower bound because the operators rotate names and links.
Who found it and what slowed fixes? Independent researcher Orchid used heuristic searches to map this campaign; GitHub’s API limits and volume slowed comprehensive takedowns, allowing some repos to remain active for months.
What’s the next monitoring checkpoint? Watch for changes in GitHub’s repository-creation and release artifact policies and for the campaign’s adaptation—particularly how they alter README content, commit behavior, or C2 mechanisms.
