Threat actors continue to find new ways to incorporate AI into schemes aimed at luring developers into downloading malware from fake repositories.
The latest example involves almost 7,600 malicious GitHub repositories that are being used to distribute a loader and an information-stealer. The FakeGit campaign is nothing new, with Oleg Zaytsev, lead security researcher with Island, noting that it and SmartLoader have been haunting developers for years with false GitHub repositories that deliver the malware.
What’s new is that the bad actors behind FakeGit have added AI into the mix, with many of the repositories presenting as AI skills or Model Context Protocol (MCP) servers and driving exposure via AI registries. They’re part of a technique Island calls “AgentBaiting,” which happens when a developer sends out an AI agent to autonomously find something they can use within GitHub repositories.
“This brought an established malware operation into the workflows people and agents use to discover and install new AI capabilities,” Zaytsev wrote in a report. “An AI agent searching for a new capability such as a Skill or an MCP server can discover a campaign repository on its own, treat the attacker’s README as legitimate documentation, and hand the installation instructions to the user.”
Surfacing Malicious Repositories
Island researchers in tests found that Anthropic’s Claude Code, Google’s Gemini, and OpenAI’s ChatGPT all pitched malicious campaign repositories to developers without being shown a link, he wrote, adding that “a playbook built to deceive people now deceives the agents acting on their behalf.”
The 7,600 or so malicious GitHub repositories confirmed by Island were created by about 6,600 profiles, with some 1,400 of those tied to AI tools, agents, or workflows, and more than 800 posing as Skills or MCP servers that reach from tools in such environments as Gmail, WhatsApp integrations, Databricks, Jenkins, and Docker, according to Zaytsev.
As of this month, there have been more than 14 million downloads from about 200 of the campaign’s repositories. Tied to the campaign were thousands of other repositories that embedded malicious ZIP files directly in the project, where downloads aren’t publicly counted.
Fast-Scaling Campaign
That said, the AI-focused part of the campaign ramped up quickly, he wrote. According to GitHub creation dates, that started to build in March and peaked in April, when almost 300 such AI-related repositories were created.
“The repositories were designed to meet demand already forming around AI capabilities, borrowing the names and workflows of familiar consumer and enterprise tools,” he wrote. “That familiarity gave the malicious ZIP files a credible reason to be downloaded, while the README guided users or agents from what appeared to be routine setup into the SmartLoader attack chain.”
According to Island, the fraudulent repositories are made to resemble real projects, and at times are simply copies of them.
If a fake repository is chosen, the “Download Latest Release” button sends the developer to a malicious ZIP archive inside, which includes instructions for downloading, extracting, and running the application. This kicks off the attack chain, starting with a heavily obfuscated 300 KB Lua payload that is disguised as a text, icon, license, or data file.
Next Comes SmartLoader, StealC
From there, SmartLoader is dropped, which then deploys StealC, which can steal a range of information, including browser passwords and extension data, cookies, active sessions, screenshots, host information, and email and remote-access credentials.
“The malware chain itself is familiar,” Zaytsev wrote. “What changes is the route that leads to execution.”
That route is exploiting the autonomous capabilities of AI agents. The agent doesn’t need to be given a malicious link. Instead, it can discover a FakeGit repository itself, treat the README file as legitimate, and then send the bad actor’s instructions to the user. This is AgentBaiting, and the FakeGit operators built the AI-based lures around it.
Top Coding Agents Fall for It
The Island researchers tested it using Anthropic’s Claude Code developer assistant, watching the model search the web, follow results through an MCP marketplace and GitHub, and open two repositories. One was benign, the other a FakeGit repository in the malicious skills category. Claude Code recommended the benign repository, but saw the malicious one as a legitimate alternative.
In other tries, the AI model detected the malicious content in the fraudulent repository and didn’t recommend it.
“That variability is the point: it independently discovered a campaign repository and, in one run, turned its attacker-written README into actionable installation guidance,” he wrote. “At the scale of this campaign, even an occasional miss creates a path to malware execution.”
Tests on both Gemini and ChatGPT showed similar results.
No Breach Needed
Zaytsev stressed that the FakeGit operators didn’t have to breach anything in the campaign.
They “published convincing repositories, borrowed real developers’ identities, spread its listings across public registries, and let discovery do the rest,” he wrote. “With AgentBaiting, that discovery no longer requires a person at all: an agent searching for a Skill or MCP server can find the lure, read the attacker’s README, and carry its instructions forward.”
Organizations need defenses to interrupt the chain before it executes. That includes evaluating each new capability in an isolated environment first, verifying the publisher and the project, and keeping an eye on the paths AI agents go down.
Island researchers aren’t the only ones to detect such activity. Straiker AI in February reported a campaign using fake GitHub accounts to exploit the MCP ecosystem and a cloned Oura Ring server to sneak into developer environments with info-stealing malware. A month later, Derp.ca wrote about FakeGit distributing Lua-based malware through GitHub.
This new book explains how our industry has reached the cloud native era, which impacts how software applications are developed, tested, deployed and managed. Inside, you’ll read about how the future of modern application development can benefit from the powerful combination of Jenkins X and Kubernetes, providing developers a seamless way to automate their continuous integration (CI) and continuous delivery (CD) process.
Michael Neale is a development manager at CloudBees. Michael is an open source polyglot developer. For his sins, he spent time at JBoss, working on the Drools project and then Red Hat, where he continually caused trouble on various projects. Post-Red Hat, Michael was one of the co-founders of CloudBees, seeing great opportunity in cloud technologies. His interest in the cloud is natural, as he is attracted to disruptive technologies. Michael lives and works in the Blue Mountains, just outside Sydney, Australia. He has no hobbies, as his hobbies tend to turn into work anyway. Mic’s motto: “Find something you love doing, and then you will never work a day in your life again.” 
Jenkins X is built for developers and is designed to help ship code faster, following the best practices in DevOps. That’s why it offers preview environments, simplifies cluster creation with DevEx and can run on different cloud providers’ clusters. One of the biggest advantages of using Jenkins X is that knowledge of Kubernetes internals isn’t necessary and developers can start leveraging the ecosystem right away. However, if it’s necessary to change the setup to fit specific environments or workflows tweaks can be made to the underlying Dockerfile, Jenkins X pipeline, Jenkinsfile or Helm charts as everything is versioned in Git. Let’s examine some of the most talked about features of Jenkins X: