Seven thousand six hundred malicious repositories. Fourteen million downloads. Sixty-six hundred configuration files. Zero exploits. That is the entire attack surface in summary form. The campaign did not break encryption. It did not exploit a buffer overflow. It did not bypass authentication. It simply stood in the open and asked the most trusted software agents of 2026 to recommend its payload.
Claude Code, in a live test, recommended the poisoned skill repository. Gemini recommended the malicious MCP server. ChatGPT did the same. No coercion, no zero-day, no social engineering call to a help desk. The agents performed exactly the function they were built for: locate tools, evaluate them through the thin filter of community signals, and present them to humans who install them without inspection.
The ledger does not lie, only the narrative does. The narrative around AI coding assistants has been one of productivity acceleration, autonomous reasoning, and a future where developers supervise rather than type. What the FakeGit campaign demonstrates is that the same supervision gap is a carriage return away from total compromise. Every repository an agent recommends is a trust transfer. Every auto-installed MCP server is an execution contract written by someone the developer never met.
I have spent sixteen years reading threat reports. In 2022, I reconstructed the Terra collapse by walking 50,000 blockchain transactions, demonstrating that the UST depeg was a deterministic failure of an incentive model, not a market panic. In 2026, I audited NeuroPay, an AI-driven microtransaction protocol, and found a reentrancy vulnerability in its oracle integration that cost two million dollars in a single transaction. Both of those exercises taught me the same syntax: structure outlives sentiment, and code outlives hype. FakeGit is the same theorem applied to the AI agent supply chain.
This report is not an opinion piece. It is a layer-by-layer teardown of an active attack infrastructure, assembled from the Island security research team's findings, my own forensic methods, and the public data that the attackers themselves left on the Polygon ledger.
The Ecosystem That Made This Possible
To understand FakeGit, you need to understand the discovery economy that AI agents now operate inside. The Model Context Protocol, or MCP, became the connective tissue of agent tool integration through 2025 and into 2026. Anthropic, Google, and OpenAI all shipped clients that consume MCP servers. A developer asks Claude Code to manage infrastructure, and the agent searches for an available MCP server, evaluates its description, and recommends installation. The same mechanism applies to skill repositories, plugin directories, and tool registries.
The problem is architectural. MCP servers are code. They execute locally, with the privileges of the user who invokes them. A malicious server can read files, exfiltrate credentials, and persist on the host. Yet the discovery layer that recommends these servers applies no meaningful security verification. It ranks by description quality, star counts, fork counts, and download volume. It does not validate publisher identity. It does not inspect the package manifest. It does not sandbox the installed code. An attacker does not need to break an AI model; he only needs to make a repository that an agent considers useful.
Version control platforms become the upstream of a trust waterfall. GitHub ranks high in agent crawlers. Registry platforms like LobeHub, Glama, MCP.so, and MCP Market pull repository metadata and mirror it to their own catalogs. Agents query these catalogs, and developers install what the agents recommend. FakeGit poisoned this waterfall at the top and let gravity do the rest.
The campaign ran at production scale. Island identified approximately 7,600 malicious repositories, more than 600 malicious registry listings, and roughly 6,600 malicious configuration files. Across about 200 of those repositories, the cumulative download count exceeded 14 million. For perspective, that is more downloads than many legitimate open-source projects will see in their lifetime. The numbers alone suggest a machine-generated operation, not a hobbyist's weekend project.
The Attack Chain, Stage by Stage
The campaign's technical pipeline is worth mapping in precise order, because the architecture repeats a pattern that will define supply chain attacks for the rest of the decade.
Stage one: the seed repository. The attackers registered thousands of GitHub repositories with names that read like legitimate productivity tools: API utilities, database connectors, note-taking integrations, and data-processing helpers. Each repository carried a realistic README, a plausible license, and in many cases a configuration manifest intended for agent consumption. In the MCP ecosystem, this means an mcp.json or a server directory with an entry point. For Claude Code skills, this means a SKILL.md that exposes a command the agent can invoke.
Stage two: the poisoned artifact. Embedded inside the repository was a ZIP archive. The archive contained a LuaJIT bytecode loader. LuaJIT is an unusual choice for malware delivery because it is not a mainstream payload format, and it resists classic signature-based detection. The initial ZIP file does not contain a Windows executable or a shell script that a scanner would flag instantly. It contains compact, compiled Lua bytecode that is designed to look like configuration data or a static asset.
Stage three: the loader execution. When the agent or the developer follows the installation instructions, the ZIP archive is extracted and the LuaJIT loader runs. The loader's job is minimal: it allocates memory, writes the next-stage payload, and executes it. This next-stage component is identified by Island as SmartLoader. SmartLoader is a delivery mechanism designed to fetch additional command data from an external source. And here is where the campaign makes its turn into blockchain infrastructure.
Stage four: the Polygon command channel. SmartLoader does not call a traditional HTTP server to receive instructions. It queries a smart contract deployed on the Polygon blockchain. The contract's state stores encoded commands. SmartLoader reads those commands, decodes them, and executes the corresponding next-stage activity. By using a smart contract as a command-and-control server, the attackers gain a persistence mechanism that does not depend on a domain name, a static IP, or a hosting provider that can be taken down with a single abuse report.
Stage five: the payload. The final stage of the chain is StealC, an information theft trojan. StealC is not new. It circulates in underground markets as a commodity credential stealer. What matters is how it is deployed here: after the Polygon contract instructs SmartLoader to release StealC, the stealer executes on the target host. It harvests browser cookies, saved credentials, autofill profiles, OAuth tokens, and session data from a wide range of applications. It also targets SSH keys and cryptocurrency wallet extensions. The stolen data is packaged and exfiltrated to the attackers' infrastructure.
The full chain is therefore: malicious repository, weaponized ZIP, LuaJIT launcher, SmartLoader, Polygon smart contract, StealC trojan. It is a complete pipeline from recommendation to credential theft, and every stage is disposable. If the GitHub repository is removed, the ZIP is gone but the loader already exists on thousands of machines. If the Polygon contract is blacklisted, the attackers can deploy a new one in minutes for pennies.
The Discovery Vulnerability: How Agents Were Turned Into Accomplices
The structural novelty of FakeGit is not in the malware, which is ordinary. The novelty is in the distribution vector, which is an AI agent's discovery system. Island's researchers demonstrated that the attack worked against all three major coding assistants. Claude Code recommended a malicious skill repository when asked to find a productivity-enhancing tool. Gemini recommended a malicious MCP server. ChatGPT did the same. The agents were not compromised; their recommendation functions were simply operating in an environment where malicious content outranked legitimate content.
This reveals a core assumption that every agent developer got wrong. The assumption was that community signals, like stars, forks, and download counts, correlate with trustworthiness. That assumption was already shaky in the human-driven open-source world, where campaigns have inflated stars and coordinated fake usage for years. In the agent-driven world, the assumption becomes catastrophic. An agent cannot distinguish between a repository that is popular because it is useful and a repository that is popular because the attacker spent a few hundred dollars on bot traffic. The agent's ranking model sees signals, not intentions.
The attack also exploits the timing of the recommendation moment. When a developer installs an MCP server, the installation itself is the trust boundary. A human administrator might inspect the code before granting it access. An AI agent, by design, makes the recommendation and often executes the installation in the same flow. The user sees a command line that says “Installing MCP server: note-sync-helper,” and presses yes. That single confirmation grants the payload access to the user's session, file system, and network. There is no sandbox. There is no permission prompt for the specific files the payload wants to read. The agent's entire value proposition, which is speed, becomes its security hole.
Island's tests are not theoretical. The researchers observed actual recommendations for the malicious repositories. That means the agents' retrieval systems had indexed the fake content, weighted it favorably, and served it to the user in a production environment. In one test, Claude Code recommended the malicious skill for a legitimate task relating to date formatting. In another, Gemini recommended a malicious MCP server for database interaction. The pattern holds across vendors because the retrieval layer is the same: crawl the repositories, rank by signals, present to the user.
What makes this particularly difficult to remediate is that the attack does not require a model vulnerability. It exploits the absence of a security layer between the model and the external world. The AI model is functioning exactly as trained. The failure is in the platform integration layer, which does not verify the provenance of the content it recommends.
The Trust Economy: Social Proof, Manufactured
The repository ecosystem runs on a currency of trust indicators. Stars, forks, issue responses, release cadence, and of course downloads. These indicators are what an agent's ranking system consumes when it decides what to recommend. The FakeGit operation manufactured these indicators at industrial scale.
Island's report notes that the attackers borrowed the identities of real developers. This is a technique that goes beyond simple fake account creation. By taking over or impersonating accounts that already have a history of legitimate contributions, the attackers inherit whatever trust score the platform has assigned to the identity. When a repo is pushed from an account with a two-year history, a few dozen followers, and a handful of legitimate-looking projects, the platform's trust model treats the new repository as a legitimate continuation of that identity. An AI agent crawling the platform sees the same signals and inflates its recommendation score accordingly.
The attackers paired identity borrowing with a manufacturing pipeline. Creating 7,600 repositories by hand is implausible. The volume strongly suggests a generator that programmatically assembles repositories from templates. Each repository is given a name that follows common open-source naming conventions, a README generated from a template, and a SKILL.md or MCP manifest containing an infection hook. The generator then pushes the repositories through authenticated accounts, perhaps dozens or hundreds of accounts operating in parallel. From a distance, the output looks like organic open-source activity. In practice, it is a factory.
The scale is where the data gets disturbing. Fourteen million downloads is not a small test population. Even if a fraction of those downloads occurred on automated systems, the number represents a massive installed base for a stealer payload. It also reflects the speed at which AI-driven installation has normalized. A developer in 2026 does not need to visit a registry, read the docs, and manually download a tool. He simply asks the agent to find a tool, and the agent responds with a one-line install command. The friction that once acted as a security gate, inconvenience, has been removed.
This is the attack's most effective social engineering element: it exploits the user's belief that the agent has done the vetting. The user delegates trust to the agent, the agent delegates trust to community signals, and the attackers manufacture those signals. It is a delegation chain with no accountability at any node.
The Polygon Decision: Why a Layer-2 Chain Became a Command Server
The use of Polygon as the command-and-control transport is one of the more interesting engineering decisions in this campaign. A traditional C2 infrastructure relies on domains and IP addresses, both of which are fragile. Domain names get suspended. IPs get blocked. Hosting providers terminate accounts. Blockchain-based C2 avoids these failure modes. The smart contract is deployed on a decentralized network that no single entity controls. The contract's state is read by the malware through a standard RPC endpoint or a public node. Takedown is effectively impossible without coordinated action by multiple validators in multiple jurisdictions.
Why Polygon specifically? The decision comes down to three factors that the attackers would have weighed carefully. First, transaction cost. Polygon's gas fees are fractions of a cent. Deploying a contract and updating its state costs pennies. An attacker planning to update commands in real time can do so for negligible cost, and a campaign that deploys hundreds of contracts can do so for a few hundred dollars total. Second, obfuscation. Polygon processes a high volume of legitimate transactions. A few additional contract calls from a botnet are statistically meaningless. The C2 traffic blends into the ambient noise of the chain. Third, programmability. The attacker can store commands in contract state that is readable by anyone but only writable by the controlling address. The contract can also be split into multiple functions, each storing different instructions, making signature detection harder.
There is a fourth factor, often overlooked: the tooling ecosystem. Polygon is EVM-compatible. The attacker can use Solidity, standard deployment tools, and any Ethereum library. There is no need for custom infrastructure. They can create a contract, write a minimal ABI, and embed the ABI's function signatures into SmartLoader. When the loader wants its next instruction, it calls a function like getCommand(uint256 index) and reads the returned bytes. The chain becomes a distributed bulletin board.
The cost analysis is stark. Deploying a simple contract that stores bytes32 values on Polygon costs less than one dollar. Updating the stored value costs a fraction of a cent. Running the C2 for the entire observed campaign, if it used multiple contracts, likely cost the attackers less than the price of a budget cloud server. In terms of cost per victim, the campaign achieved a ratio that would be the envy of any disinformation operation.
From a forensic perspective, however, the choice of Polygon gives researchers a powerful advantage: the entire command history is public. Every instruction the malware ever received is recorded on the chain. Once the C2 contract address is identified, analysts can reconstruct the full timeline of commands, including the intervals between updates and the sequence of payload versions. The ledger does not lie, and in this case the ledger is the kill chain.
Propagation Loops: How the Registries Amplified Everything
The campaign did not limit itself to GitHub. Island identified malicious listings across LobeHub, Glama, MCP.so, and MCP Market. The propagation model is a feedback loop. The attacker creates a malicious repository on GitHub. Registry platforms automatically pull repository metadata into their own catalogs. An agent querying MCP.so finds the listing, reads the README, and recommends the tool. When a developer installs it, the payload executes. When the registry is cleaned, the repository on GitHub remains, ready to be mirrored again. The loop is self-healing.
The README becomes the infection vector for the platform. The agents do not read the source code; they parse the README, the manifest, and the repository's metadata. The attacker writes a README that describes the tool in terms that the agent's retrieval model ranks highly. This is SEO poisoning for machine readers. Names are chosen to match common queries: typescript helpers, API clients, deployment tools. Descriptions are crafted to match the semantic vector of a query like “postgres utility” or “slack notifications.” The agent's embedding model matches the request to the poisoned document. The developer clicks install. The machine trust loop is complete.
This propagation model also explains the download count. Fourteen million downloads across 200 repositories is roughly 70,000 per repository. Some of that traffic is likely automated, generated by other bots that crawl and execute installation commands. Some is likely from agent-mediated installs, where the agent provisioned the tool in a development environment. Either way, the distribution curve is not organic. It is the signature of a supply chain attack that has been running long enough to accumulate millions of infections before anyone published a report.
The Payload: What StealC Actually Takes
StealC is a credential stealer that has been observed in underground markets for several years. It is typically sold as a malware-as-a-service product, meaning the operator of FakeGit may have licensed the stealer rather than developed it. The stealer's functionality is broad. It targets browser profiles, including passwords, cookies, autofill data, and session storage. It also targets browser extensions, particularly cryptocurrency wallets. It collects files from desktop folders with names suggesting secrets, keys, or notes. It extracts SSH keys and tries to identify cloud configuration files.
The most dangerous feature is session cookie theft. An attacker who obtains a session cookie does not need a password. He can authenticate to a web application as the victim without triggering an MFA challenge. This is the attack that passwords alone cannot stop. StealC's harvest of OAuth tokens compounds the issue: a stolen GitHub token, Slack token, or AWS token can grant persistent access to production systems long after the victim rotates their password.
For a developer workstation, the impact is severe. The victim's GitHub account can be used to push malicious code to internal repositories. Their AWS console session can be used to exfiltrate data. Their Slack session can be used for social engineering. Their SSH keys grant access to servers. The stealer payload turns one unverified installation into a full pipeline of lateral movement and privilege escalation. The attacker does not need to exploit a server vulnerability if he already has the keys.
The response challenge is equally serious. If a developer's machine was compromised, simply resetting passwords is not enough. Session tokens have to be revoked, OAuth grants have to be revoked, SSH key pairs have to be rotated, and every service the developer accessed during the compromise window has to be reviewed. The security team must treat the compromise as a full credential breach, not just a malware event.
The Operational Profile: Who Is Behind This
The scale and organization of FakeGit point to a sophisticated operator. Creating 7,600 repositories requires an automation pipeline. Maintaining parallel listings on four registry platforms requires coordinated account management. Borrowing real developer identities requires either account takeover or impersonation at a level that involves identity verification evasion. That operational profile does not match a lone hacker; it matches a group with defined roles and a budget.
Trend Micro has previously linked similar activity to a group it tracks as Water Kurita, known for using the Lumma Stealer. Island's report notes that the FakeGit campaign uses SmartLoader and StealC, which are not identical to the Lumma Stealer toolchain. However, the LuaJIT loader technique shares characteristics with prior Water Kurita operations. Whether FakeGit is the same group, a splinter, or an imitator, the tactical overlap is not coincidental. The supply chain attack playbook is being shared, refined, and improved across the underground.
The attackers' motivation is straightforward: data monetization. Stolen credentials have a reliable resale value. Session cookies and OAuth tokens are sold to initial access brokers, who sell them to ransomware operators. Mail credentials are used for financial fraud. Crypto wallet data is drained directly. The FakeGit operation is a harvesting layer in a criminal economy where the pipeline from access to ransom is already mature.
What the Detection Layer Misses
The FakeGit campaign exposes blind spots across every layer of traditional defense. At the repository layer, GitHub's automated scanning looks for known malware signatures and common C2 patterns. LuaJIT bytecode in a ZIP archive is not a signature that scanners detect by default. The malicious repositories avoid committing known malicious binaries; they commit a loader that fetches everything else from the smart contract. The registry platforms consume the repositories from GitHub and inherit the same blind spot. They validate that the package installs, not that the code is safe to run.
At the network layer, the C2 traffic is an RPC call to a public Polygon node. The traffic is indistinguishable from any other Web3 RPC request. It is encrypted. It is not a suspicious destination. It is a chunk of JSON to a well-known endpoint. Network detection cannot spot the C2 without knowing the malicious contract address.
The endpoint layer only detects StealC after it drops to disk and begins execution. Endpoint detection has improved, but the LuaJIT loader's evasive design means the stealer may be in memory before the AV engine sees it. The loader's small footprint and benign-looking name reduce the probability of behavioral detection.
The final gap is at the recommendation layer: the AI agent. None of the major agent vendors have yet shipped a security filter that verifies the provenance of an MCP server before recommending it. None have integrated package signing into the agent's installation flow. None have sandboxed code execution for newly discovered tools. The recommendation layer remains wide open.
Contrarian Angle: What the Bulls Got Right
It would be easy to read this report as a prophecy of doom for AI agents, MCP ecosystems, and blockchain infrastructure. That reading would be incomplete. There are several ways in which the bulls' vision is actually validated by this attack, and those points matter for how the ecosystem evolves.
First, the public blockchain made the C2 infrastructure traceable in a way that traditional infrastructure never is. If SmartLoader had used an HTTP server, the operators could have taken it down, moved domains, and erased their command history. Because they chose Polygon, every command they sent is permanently recorded on a public ledger. Security researchers can enumerate every C2 contract, analyze every instruction, and follow the money trail from the controlling wallets. The same immutability that protects transactions is what preserves the forensic evidence for prosecution. The ledger does not lie; in this case, the ledger is the witness.
Second, the attack proves that agent adoption is real. Fourteen million downloads did not happen in a vacuum. Developers and enterprises are genuinely installing MCP servers and skill repositories at scale. The bull case for the agent economy depends on this adoption, and the data confirms it. What the ecosystem lacks is not adoption; it is a security layer to match the adoption rate. This is a solvable engineering problem, not a fundamental design failure.
Third, the AI agents are not broken. Claude, Gemini, and ChatGPT all performed exactly as designed. A retrieval system that ranks by community signals will surface content that is crafted to rank highly. This is the same challenge search engines faced in the 2000s, and it was solved with PageRank evolution, spam filters, and content verification. The agent ecosystem can solve it with signed packages, allowlist registries, and provenance verification. The failure is a missing middleware layer, not a model alignment flaw.
Fourth, the responsible disclosure path is functioning. Island published its findings. Trend Micro identified related activity. The registry platforms can respond. The security community is converging on shared indicators. The attack ecosystem is fast, but the defense ecosystem is showing the capacity to adapt. In a perverse way, FakeGit is evidence that the market for AI supply chain security is about to expand, and that expansion will produce better detection, better tooling, and clearer standards.
Fifth, the blockchain's role here is infrastructure, not incentive. The attacker used Polygon because it was cheap and programmable, not because the chain is malicious. Regulating blockchain infrastructure because criminals use it as a communication channel is like banning the postal system because someone mailed a bomb threat. The genuinely valuable regulatory focus belongs on the AI supply chain: verifying publisher identity, requiring package signing, and creating a chain of custody for agent-recommended code.
I have made my share of skeptical arguments about institutional crypto. The 2024 ETF custody deep dive made it clear that the trustless narrative was overstated at the settlement layer. But this attack does not indict Polygon; it indicts the AI platforms that recommend code without verification. It is a reminder that the chain itself is neutral. It can just as easily be a defense mechanism as an attack tool, and the public nature of the ledger is the key that unlocks the investigation.
The Remediation That Would Actually Work
The first practical response for any organization using AI coding agents is to treat agent-recommended code as untrusted input. That means establishing an approved registry of MCP servers and skill packages. The approved registry must be curated by a human who reads the code before it is added. The registry must be the only source that agents are allowed to install from. Agent configuration should disable auto-discovery and auto-installation. The default behavior should be “ask the agent to describe, then verify manually.”
The second response is code execution sandboxing. When an agent installs a tool, that tool should run in a virtualized environment with no access to the host file system, network, or process list. This is technically straightforward for container-based development environments. It is also the only way to contain a malicious MCP server before it touches credentials. Until the agent vendors ship this as a default, enterprises must enforce it at the deployment layer.
The third response is session hygiene. Immediate rotation of all developer credentials is necessary, but the greater priority is revoking OAuth tokens and session cookies for any machine that may have been exposed. The security team must not assume that a clean AV scan means a clean machine. The safest assumption is compromise. MFA enforcement is necessary but insufficient; the threat model now includes session token theft, which bypasses MFA entirely.
The fourth response is the construction of an AI supply chain software bill of materials, or SBOM for agents. Every agent installation should produce a manifest: the name of the repository, the publisher identity, the commit hash, the dependency graph, the files installed, and the commands executed. That manifest should be auditable and searchable. Without such a manifest, an organization cannot know which tools were installed, by which agent, with what access. The price of agent convenience is a new accounting layer.
For the security industry, the immediate opportunity is in detection. Monitoring Polygon and Ethereum for contract deployments that match C2 patterns is a novel but tractable signature. Researchers can cluster contract deployments by creation time, funding address, and bytecode similarity. A contract that is funded by a known malicious wallet and that stores command-like byte strings is a strong indicator. The security tools of the future will include a blockchain detection feed, not just a domain reputation feed.
Takeaway: The Next Attack Will Not Need a Million Repositories
The FakeGit campaign's greatest contribution to the criminal ecosystem is the playbook. It has now been demonstrated, at scale, that AI agents can be turned into malware distribution channels without any exploit. The consequences are already measurable in the form of stolen credentials. The next campaign will not need to manufacture 7,600 repositories. It will need one repository that is well-crafted enough to earn a high recommendation score, and a supply chain that lets the agent install it automatically. The marginal cost of an attack runs to zero.
What remains to be seen is whether the agent vendors will treat this as a security engineering problem or as a public relations problem. If they treat it as engineering, we will see signed package verification, sandboxed execution, and provenance checks built into the installation pipeline. If they treat it as PR, we will see marketing blog posts and a continued reliance on pausing adoption in response to incidents. The code will still be capable of executing; only the trust will change.
I have written this article in the same manner I write all technical audits: with a focus on structure, evidence, and the assumption that the machine will run exactly as designed. What the machine is designed to do depends on who wrote the code, and in the case of FakeGit, the code was written by an adversary who understood the trust model better than the platforms that built it.
The final check for any organization is a simple one. If you ask your AI agent to install a tool tomorrow, asking it to install a tool you have never heard of, what happens? If the answer is that it installs and runs, you have already been exposed. And if your log files do not record the installation, you will never know what you lost. Panic is just poor data processing in real-time. The better response is to turn the ledger on, inspect the chain, and build the verification layer that the agents should have shipped with on day one.
