Kaspersky flags GitHub-targeting crypto malware as threat actors move supply chain off-platform
A newly disclosed malware framework uses trojanised GitHub apps to drain crypto wallets, landing the same week a high-profile developer told followers to trust only code hosted on his own site.
Cybersecurity vendor Kaspersky told investors on 18 July 2026 that a newly identified malware framework is targeting cryptocurrency holders through social-engineering lures and trojanised GitHub applications, the company said in reporting carried by Cointelegraph. The disclosure lands a day after a developer known on X as Darkweb Informer announced he had moved every one of his repositories off GitHub onto a self-hosted site, citing an inability to verify what the platform still ships.
The combination is a useful test of a long-running argument inside the crypto community: that the safest place to publish code is also the easiest place to weaponise it. Open repositories lower the cost of legitimate collaboration, but the same openness gives attackers a free distribution rail and a credibility wrapper. A wallet-drainer dressed up as a trading bot, hosted on a real GitHub organisation page with a green commit history, is harder for a hurried user to spot than the same payload pushed through a Telegram channel.
The lure, and what the framework does
Kaspersky's researchers describe the framework as a kit that operators can reconfigure per campaign, with social-engineering scripts that pose as trading tools, arbitrage bots, or wallet "fixers". Once a victim installs the trojanised application and grants the requested permissions, the malware reads clipboard contents, browser-extension state, and seed-phrase input fields, then exfiltrates balances to attacker-controlled addresses. The vendor has not, in the public reporting so far, named a dollar figure for aggregate losses, and the framework is described as newly identified rather than widely deployed.
The detail that matters for the wider ecosystem is the delivery mechanism. GitHub's organisation accounts, release pages, and contributor graphs supply exactly the surface legitimacy that phishing pages cannot. A user who would delete an unsolicited .exe without thinking will happily git clone a repository with three contributors, a passing CI badge, and a recent merge from a name they recognise.
The supply-chain counter-current
A day earlier, on 17 July 2026, the X account @darkwebinformer posted that he had migrated all his repositories to a self-hosted site, telling followers that anything purporting to be his code on GitHub was no longer genuine. The post, captured at 18:34 UTC and archived at the redirect domain git.darkwebinformer, is a small data point but a representative one. The drift away from hosted-for-you infrastructure and onto personal domains has been visible for years in security-conscious corners of crypto; the news this week is that a developer with a public following has now made the move a public instruction.
The implication is asymmetric. Legitimate developers leaving centralised forges shrinks the pool of named, verifiable projects that malicious actors have to impersonate. It also shrinks the audit surface for everyone else, because the tooling, signing, and dependency-graph benefits of a hosted platform do not travel automatically to a single maintainer's VPS.
What a sober reading looks like
There is a temptation, on this kind of story, to treat the threat as either overblown vendor marketing or as an extinction-level event for retail self-custody. The reporting does not support either reading. Kaspersky disclosed a real framework with a real delivery vector; the framework has not been shown, in the public material, to have drained funds at scale. The honest framing is narrower: a category of attack that has worked in adjacent forms for years now has a reusable kit, and the platforms it rides on are not designed to police it in real time.
The structural pattern is the one security researchers have been naming for a decade without resolving. Open code repositories externalise trust to maintainers, contributors, and platform moderators; attackers exploit the gap between "a thing exists on GitHub" and "the thing on GitHub is what its README claims". The mitigation is not secrecy; it is verification overhead that most retail users will not perform, applied to tooling that most retail users cannot read.
What to watch
Three dates are worth pencilling in. First, whether Kaspersky or a peer vendor publishes indicators of compromise tied to a specific campaign, rather than the framework alone; that is the difference between a research note and a live threat. Second, whether GitHub's trust-and-safety operation comments publicly on the trojanised-app pattern, which would be a signal that platform-level controls are being recalibrated rather than left to downstream detection. Third, whether other mid-following developers follow Darkweb Informer's lead and migrate off hosted forges, because the security of the supply chain is a function of where the credible names choose to publish.
The remaining uncertainty is real. The reporting so far does not specify which cryptocurrencies or wallet clients are most exposed, how the trojanised apps are distributed (search-engine poisoning, direct messaging, or compromised legitimate developer accounts), or whether the framework has been observed in the wild beyond Kaspersky's own telemetry. Each of those will need a primary-source confirmation before this story hardens into something investors can act on with confidence.
Desk note: this publication treats Kaspersky's disclosure as a vendor advisory rather than an incident report, and reads the Darkweb Informer migration as an indicator of supply-chain drift rather than a confirmed compromise of GitHub itself.