The GitVenom Campaign: When Open-Source Trust Becomes the Attack Surface
Two hundred GitHub repositories. AI-generated documentation indistinguishable from legitimate projects. A single objective: siphon Bitcoin from wallets and credentials of crypto developers and investors. This is not a hypothetical threat model. It is the GitVenom campaign, uncovered by Kaspersky’s security team in early 2025. The scale is unprecedented for a targeted supply chain attack on the crypto ecosystem. And it reveals a vulnerability that no smart contract audit can patch: the human assumption that code on GitHub is safe.
Fragility is the price of infinite composability. In DeFi, composability connects protocols; in open-source, composability connects codebases. The GitVenom attackers exploited this chain by creating entire fake projects—each with a polished README, a convincing commit history, and embedded malware. The malware itself is not groundbreaking: an infostealer that targets Bitcoin Core wallet files, browser cookies, and saved credentials, paired with a remote access trojan for persistent control. What is groundbreaking is the production line. Two hundred repos demand either a large team or heavy automation. The use of large language models to generate documentation lowers the barrier to creating believable fakes. This is not a lone hacker posting a malicious script on Pastebin. This is an organized, industrialized attack on the trust layer of crypto development.
From my first deep dive into Solidity in 2017—spending 40 hours tracing the integer overflow in Golem’s distribution algorithm during its ICO—I learned that the distance between a whitepaper claim and the actual code is where most attacks live. GitVenom weaponizes that distance. The “whitepaper” is now an AI-generated README. The “code” is a node.js dependency that exfiltrates your private keys. The victim never writes a line of code; they simply run the project locally, believing they are testing a trading bot or a wallet recovery tool. The attack surface is not a smart contract. It is the developer’s own machine.
The technical mechanics are straightforward but effective. The fake repositories typically impersonate popular tools like trading bots, automated arbitrage scripts, or mining software. The AI-generated documentation includes detailed installation instructions, dependency lists, and even fake issue discussions. The malicious payload is hidden in a sub-dependency or a post-install script. Once executed, the infostealer scans for Bitcoin Core’s wallet.dat files, browser extensions like MetaMask or Phantom, and locally stored SSH keys. The RAT then opens a backdoor, allowing exfiltration of future credentials. The attackers are patient—they wait until the victim uses the compromised machine to access an exchange or sign a transaction. Then they drain.
During DeFi Summer 2020, I mapped the composability risks between Aave and Compound flash loans. The lesson was that efficiency often masks security debt. GitVenom is the same lesson applied to development workflows. The efficiency of using a pre-built GitHub repository to launch a new project hides the debt of blind trust in unverified code. The security community has long warned about “dependency confusion” and “typosquatting” in package managers. GitVenom takes this to the next level: full project impersonation with a human touch.
Hype creates noise; protocols create history. The hype around AI-generated content has created noise that makes it harder to distinguish genuine projects from fakes. The protocol of GitHub—a platform built on the assumption of good faith and openness—is now being used to create a history of fraudulent contributions. This is a systemic fragility that cannot be fixed with a single patch. It requires a cultural shift: every developer must become an auditor of the repos they depend on.
The contrarian angle? The industry is obsessed with DeFi hacks—reentrancy, oracle manipulation, sandwich attacks. These are important but addressable through formal verification and updated compilers. GitVenom targets something more fundamental: the supply chain of code itself. A single compromised developer machine can lead to contaminated smart contract deployments, backdoored libraries, and stolen protocol funds. Yet the crypto media will likely treat this as “just another malware campaign.” It is not. It is a sign that attackers have realized the most profitable vulnerability is the human operating the machine—not the machine itself.
Let me be precise about the data. Kaspersky’s report indicates over 200 active repos, some with hundreds of stars (likely fake stars to boost credibility). The malware has been detected in at least half a dozen countries, with victims ranging from individual traders to small development teams. The estimated Bitcoin stolen so far is unknown, but the infrastructure suggests a high-value target set. Attackers are after more than pocket change; they want high-net-worth individuals who manage significant on-chain assets.
During the Terra/Luna collapse of 2022, I retreated to São Paulo and reverse-engineered the UST burn logic to understand the death spiral. That trauma taught me that fragility is often hidden in plain sight. GitVenom is a different kind of death spiral: once a developer trusts a malicious repo, that trust cascades into their projects, their team’s codebase, and eventually into the protocols they build. The fragility is not in an algorithmic peg; it is in the social layer of open-source collaboration.
The ecosystem response should be multi-layered. First, GitHub must improve detection of AI-generated documentation that has no corresponding genuine development activity. Second, wallet providers should implement alert systems that warn users when they are running code from a repository with suspicious patterns—new account, few contributors, no real issue tracker. Third, and most importantly, developers must adopt a zero-trust approach to open-source: run unknown code in sandboxes, verify signatures, and demand verifiable build processes.
Fragility is the price of infinite composability. The GitVenom campaign proves that infinite composability extends beyond DeFi protocols to the code that builds them. Until the industry treats supply chain security with the same rigor as smart contract audits, we will continue to see campaigns like this succeed. The question is not if the next one will come, but how many repos will be infected before we learn to verify.
Hype creates noise; protocols create history. The history of this attack will be written in the Bitcoin addresses that receive stolen funds. But the protocol we need is not a blockchain—it is a new culture of verification. Every line of code is a promise. GitVenom reminds us that promises can be broken.