A large-scale malware distribution campaign utilizing GitHub repositories has been uncovered. This coordinated effort weaponized over 10,000 repositories to deliver Trojanized payloads.
The activity was first identified on June 18, 2026, and highlights significant gaps in automated detection and monitoring of repositories on one of the world’s most widely used developer platforms.
Massive GitHub Attack
The campaign came to light when a researcher from OrchidFiles noticed a cloned version of their own GitHub repository appearing in search engine results. This clone had identical metadata, commit history, and contributor attribution.
However, it included a new link in its README file pointing to an external ZIP archive. Further investigation revealed that this was not an isolated incident but part of a broader pattern involving thousands of similarly structured repositories.
These malicious repositories were not simple forks; they were independently created clones with copied commit histories and contributor profiles. This approach seemed designed to build legitimacy and avoid suspicion.
A distinctive operational pattern emerged: attackers frequently deleted previous commits and re-pushed identical commits every few hours, modifying the README file to include a link to a ZIP archive each time. The commit messages consistently followed a generic format, such as “Update README.md,” indicating automation.
Analysis of the linked ZIP archives revealed a consistent payload structure, typically containing four files: a command script (e.g., Application.cmd), a loader executable (e.g., loader.exe or luajit.exe), a secondary file with a random name, and a lua51.dll library.
Notably, direct URL submissions to security scanners like VirusTotal returned no detections, while uploading the ZIP file itself triggered Trojan alerts, indicating an attempt to evade URL-based scanning mechanisms.
To quantify the campaign’s scope, the researcher developed a custom detection script using GitHub event data from the GH Archive.
Instead of scanning all repositories, which are estimated to exceed 500 million, the script focused on recent activity, zeroing in on repositories with frequent commits. Initial filtering reduced 16 million commit events over five days to approximately 3,000 repositories exhibiting periodic updates.
Further refinement involved stricter heuristics, including the presence of non-bot commit activity, irregular timing gaps between commits, and the involvement of multiple contributors. While early iterations identified only a small subset of repositories, adjustments to the detection criteria to account for less frequent update intervals significantly expanded the detection coverage.
The final analysis identified around 40,000 suspicious repositories, of which exactly 10,000 matched the malware distribution pattern.
The scale and persistence of the campaign raise serious concerns. Many of the identified repositories had existed for months or longer without detection.
Despite reporting efforts, remediation appeared reactive rather than proactive, with repository removals happening only after explicit submissions. Subsequent scans identified newly created malicious repositories, indicating that the threat actors were actively maintaining and replenishing their infrastructure.
The attackers’ strategy seems to combine search engine optimization (SEO) abuse with social engineering. By cloning newly created or low-visibility repositories and appropriately tagging them, these malicious projects gain visibility in search results. The inclusion of legitimate contributor histories further enhances credibility, increasing the likelihood of user interaction and payload execution.
Open questions remain regarding the full functionality of the delivered malware and the campaign’s ultimate objectives. However, similar techniques have previously been linked to loaders such as SmartLoader and information stealers like StealC, suggesting potential for credential theft and system compromise.
This incident underscores the need for improved large-scale behavioral analysis within repository hosting platforms. While GitHub has started removing reported repositories, the lack of proactive detection mechanisms allows such campaigns to persist and evolve.
Security teams are advised to treat external download links in repositories with caution, especially when added via recent README modifications, and to verify artifacts independently before execution.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
