GlassWorm's Solana C2: How a Supply-Chain Monster Turned the Blockchain Into a Dead Drop

Supply-chain attacks aren't new. But GlassWorm is doing something we haven't seen at this scale: weaponizing the Solana blockchain itself as command-and-control infrastructure — making its C2 effectively untakedownable while targeting the very developers who build on it.

Between January and March 2026, GlassWorm compromised 433+ components across GitHub, npm, VSCode, and OpenVSX. The campaign steals crypto wallet data, SSH keys, and developer credentials. And its C2 channel? Transaction memos on the Solana blockchain.

Let's break down how it works, why it matters for DeFi security, and what you can do about it.

---

The Attack Chain

Stage 1: Compromise Developer Accounts

GlassWorm starts by compromising GitHub accounts — likely through credential stuffing or token theft from previous infections. Once inside, attackers force-push malicious commits to legitimate repositories.

The commits are crafted to look normal: documentation tweaks, version bumps, small refactors. Security researchers at Aikido believe LLMs are being used to generate convincing cover commits that match each project's coding style. This makes manual review nearly useless as a defense.

Stage 2: Multi-Platform Propagation

From the compromised GitHub repos, the campaign fans out:

• 200+ Python repositories on GitHub
• 151+ JavaScript/TypeScript repositories on GitHub
• 72 malicious VSCode/OpenVSX extensions (mimicking popular tools like linters, AI coding assistants, and formatters)
• 10+ npm packages with rogue dependencies

The VSCode extensions are particularly clever. The latest wave abuses extensionPack and extensionDependencies in package.json — an initially clean extension passes review, then gets updated to pull in a GlassWorm-linked package as a dependency. No code change needed in the "trusted" extension itself.

Stage 3: Invisible Payload Delivery

GlassWorm's signature technique: invisible Unicode characters that encode the malicious payload. The code looks clean in editors and terminals. But when executed, those invisible characters decode into a loader that fetches and runs a second-stage script.

// What you see in your editor:
const config = require('./utils');

// What's actually there (invisible Unicode between quotes):
const config = require('./utils\u200B\u200B\u200B...[encoded payload]');

Stage 4: The Solana Dead Drop

This is where it gets interesting for the blockchain security community.

Instead of hardcoding C2 server addresses (which defenders can block), GlassWorm queries a Solana wallet's transaction memo field every 5 seconds. The C2 address is embedded as a memo in regular Solana transactions.

┌─────────────────────────────────────────────┐
│  Infected Machine                           │
│                                             │
│  1. Query Solana RPC for wallet txns        │
│  2. Parse memo field → extract C2 URL       │
│  3. Download Node.js runtime                │
│  4. Execute JS-based info stealer           │
│                                             │
│  Stolen: wallet keys, SSH keys, tokens,     │
│          credentials, env variables          │
└─────────────────────────────────────────────┘
          │
          ▼
┌─────────────────────────────────────────────┐
│  Solana Blockchain (C2 Infrastructure)      │
│                                             │
│  Wallet: [attacker address]                 │
│  Memo: encrypted C2 URL                     │
│                                             │
│  - Immutable, uncensorable                  │
│  - 50+ URL rotations since Nov 2025         │
│  - New wallet addresses to evade detection  │
└─────────────────────────────────────────────┘

Between November 2025 and March 2026, researchers at Step Security identified 50 memo transactions updating the payload URL. The attacker rotates both C2 URLs and Solana wallet addresses to evade detection.

Why Solana? Three reasons:

1. Low transaction costs — memo transactions cost fractions of a cent
2. High throughput — polling every 5 seconds is trivial on Solana's infrastructure
3. Censorship resistance — you can't "take down" a blockchain transaction; the C2 address lives forever on-chain

---

Why DeFi Developers Should Care

This isn't just a generic malware story. GlassWorm specifically targets the DeFi developer ecosystem:

1. Stolen GitHub Tokens Bootstrap the Worm

Every compromised developer's GitHub token is used to force-push malicious changes to their other repositories. If you maintain a DeFi protocol's SDK, a popular Solidity library, or Anchor program templates — your repos become attack vectors for downstream users.

2. Wallet Data Is the Primary Target

The info stealer specifically harvests:

• Cryptocurrency wallet seed phrases and private keys
• Browser extension wallet data (MetaMask, Phantom, etc.)
• .env files containing RPC endpoints and deployer keys
• SSH keys used for server access

For a DeFi developer, a single compromised machine could mean:

• Drained treasury wallets
• Compromised deployment keys
• Unauthorized contract upgrades
• Stolen user funds

3. The Blockchain C2 Creates a Trust Paradox

Solana developers who query the blockchain as part of their normal workflow won't notice anomalous RPC calls. The malware's C2 traffic blends perfectly with legitimate blockchain interactions, making network-based detection nearly impossible in crypto development environments.

---

Detection & Defense

For Individual Developers

Check for compromise indicators now:

# Search for GlassWorm marker variable
grep -r "lzcdrtfxyqiplpd" ~/projects/

# Check for persistence file
ls -la ~/init.json

# Look for unexpected Node.js installations
ls -d ~/node-v22* 2>/dev/null

# Inspect recent Git commits for date anomalies
# (committer date much newer than author date)
git log --format="%H %ai %ci" | awk '{
  split($2,a,"-"); split($5,b,"-");
  if (b[1]*10000+b[2]*100+b[3] > a[1]*10000+a[2]*100+a[3]+7)
    print "SUSPICIOUS: "$1
}'

Lock down your environment:

• Enable GitHub's Vigilant Mode — unsigned commits become visually obvious
• Use npm audit signatures to verify package provenance
• Review VSCode extensions quarterly — remove anything you don't actively use
• Never store private keys or seed phrases in .env files on development machines
• Use hardware wallets for any keys controlling protocol funds

For DeFi Protocol Teams

Supply chain hardening:

• Pin all dependencies to exact versions with integrity hashes (npm ci + package-lock.json)
• Use Socket.dev or Aikido for real-time dependency scanning
• Implement StepSecurity Harden-Runner in CI/CD to detect anomalous network calls
• Require commit signing (GPG or SSH) for all contributors
• Separate development machines from deployment infrastructure — never have deployer keys on a machine that installs npm packages

Monitor for blockchain-based C2:

# Monitor Solana wallet for suspicious memo transactions
# (useful for threat intelligence teams)
from solders.pubkey import Pubkey
from solana.rpc.api import Client

KNOWN_GLASSWORM_WALLETS = [
    # Add known attacker wallets from threat intel feeds
]

client = Client("https://api.mainnet-beta.solana.com")

for wallet in KNOWN_GLASSWORM_WALLETS:
    pubkey = Pubkey.from_string(wallet)
    txns = client.get_signatures_for_address(pubkey)
    for sig in txns.value:
        tx = client.get_transaction(sig.signature)
        # Parse memo instructions for C2 URLs
        # Alert on new transactions

---

The Bigger Picture: Blockchain as Malware Infrastructure

GlassWorm isn't the first malware to abuse blockchains for C2 — but it's the most successful at scale. Previous examples include EtherHiding (2023, BNB Chain) and various Bitcoin-based dead drops. What makes GlassWorm different:

1. Scale: 433+ compromised components across 4 platforms in a single month
2. Self-propagation: Stolen tokens automatically expand the attack surface
3. Targeting: Specifically aimed at developers who work with crypto/blockchain
4. Persistence: LLM-generated cover commits make detection extremely difficult

This creates an uncomfortable question for the blockchain community: How do you defend against an attack that uses your own infrastructure as a weapon?

The answer isn't to restrict blockchain memo fields — that defeats the purpose of permissionless systems. Instead, the defense must happen at the endpoint:

• Code signing and provenance for all packages and extensions
• Sandboxed development environments that limit what installed packages can access
• Behavioral monitoring that flags unexpected blockchain RPC calls from development tools
• Hardware security modules for any keys with real financial exposure

---

Key Takeaways

Risk	Impact	Mitigation
Compromised npm/VSCode packages	Credential theft, wallet drain	Pin deps, verify signatures, use Socket.dev
GitHub account takeover	Malicious code in trusted repos	Enforce commit signing, enable 2FA + vigilant mode
Solana-based C2	Untakedownable command infrastructure	Endpoint detection, behavioral monitoring
LLM-generated cover commits	Evades code review	Automated commit analysis, require PR reviews
Stolen deployer keys	Protocol compromise	Hardware wallets, air-gapped deployment

GlassWorm shows that the next generation of supply-chain attacks won't just target blockchain developers — they'll use the blockchain itself as attack infrastructure. The same properties that make decentralized systems resilient (immutability, censorship resistance, permissionless access) make them ideal for attackers too.

The best defense is assuming your development environment is hostile and building security layers accordingly. Hardware wallets for signing. Sandboxed environments for building. Verified provenance for dependencies. And never, ever, keeping deployer keys on a machine that runs npm install.

---

This article is part of our ongoing DeFi Security Research series. Follow for weekly deep dives into smart contract vulnerabilities, audit tools, and security best practices.