GitHub Security Crisis: Over 10,000 Hijacked Repositories Distribute Infostealer Malware
Summary
A widespread malware campaign on GitHub has been uncovered, where attackers use automated scripts to create nearly 10,000 malicious repositories. These clones mimic legitimate open-source projects in detail, including commit history and contributor profiles. The goal of the campaign is to deliver credential-stealing Trojan malware (such as infostealers) to developers’ systems. Automated workflows and AI-driven coding agents are also at risk, as they might automatically download malicious dependencies.
What happened?
A developer using the pseudonym “Orchid” noticed that their own repositories were cloned, modified with malicious code, and republished under unrecognized accounts. Further research revealed:
- Scale: Nearly 10,000 manipulated clones exist on the platform.
- Tactics: Attackers edit README files to include download links to external ZIP archives containing Trojans like Lumma Stealer.
- Activity Spoofing: To rank higher in search results (SEO poisoning) and mimic legitimacy, attackers delete and recreate commits (“Update README.md”) hourly.
- GitHub Criticism: The developer Orchid criticized GitHub’s handling of the threat, noting that the platform only deletes repositories that are manually reported, instead of proactively scanning for matching patterns.
Why it matters
This incident highlights an escalating threat to the software supply chain. As developers increasingly rely on automation and autonomous AI coding agents that download and run code independently, the risk of devastating infections grows. A single cloned repository of a popular project can be enough to harvest sensitive API keys, AWS credentials, or crypto wallets on a massive scale.
Evidence
The campaign was documented by security researchers and IT news portals in June 2026:
- News Reports: Golem.de and it-daily.net reported extensively on June 22 and 23, 2026, about Orchid’s findings and the 10,000 hijacked repositories.
- Technical Indicators: Security analyses confirmed that the linked ZIP archives contain malicious scripts (
.cmd), loaders (.exe), and DLL files designed to bypass standard antivirus detection.
Analysis
The campaign exploits blind trust in GitHub metadata. Because the commits and contributors of a repository can be duplicated to look identical when cloned, users can rarely distinguish the clone from the original project. The hourly updates create the illusion of an active project. The slow response time of GitHub’s security workflows enables these mass infections to persist.
Practical Takeaways
- Verify URLs Carefully: Before cloning a repository, double-check the URL and the author’s account name to avoid typosquatting.
- Avoid ZIP Downloads from READMEs: Never download pre-compiled binaries or ZIP archives via links embedded in README files. Use official release assets or package managers.
- Restrict AI Agents: Ensure that autonomous coding agents run in isolated sandboxed environments and do not have the authorization to execute or install unverified code directly on the host system.
- Secrets Management: Use dedicated tools like HashiCorp Vault or AWS Secrets Manager to safeguard API keys on your local machine in case of compromise.
Open Questions
- Will GitHub update its security mechanisms to proactively block automated repositories with identical commit histories and suspicious README links?
- To what extent have developer environments or CI/CD pipelines already been compromised by this specific campaign?