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

Source: Dev.to

GlassWorm Supply‑Chain Attack Overview

Supply‑chain attacks aren’t new, but GlassWorm is doing something we haven’t seen at this scale: weaponising the Solana blockchain itself as command‑and‑control (C2) infrastructure—making its C2 effectively untakedownable while targeting the very developers who build on it.

• Timeline: January – March 2026
• Impact: 433+ compromised components across GitHub, npm, VSCode, and OpenVSX.
• Goals: Steal crypto wallet data, SSH keys, and developer credentials.
• C2 channel: Transaction memos on the Solana blockchain.

How GlassWorm Works

1. Initial compromise – attackers obtain GitHub credentials (e.g., via credential stuffing or token theft).
2. Malicious commits – they force‑push commits that look legitimate (doc tweaks, version bumps, small refactors).
   Security researchers at Aikido suspect LLMs are used to generate these “cover” commits, matching each project’s coding style.

Compromised Assets

VSCode extension abuse – the latest wave exploits extensionPack and extensionDependencies in package.json. An initially clean extension passes review, then updates to pull in a GlassWorm‑linked package as a dependency—no code change needed in the “trusted” extension itself.

Invisible‑Unicode Payload

// 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]');

The invisible Unicode characters encode a loader that, when executed, fetches and runs a second‑stage script.

Blockchain‑Based C2

Instead of hard‑coding 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   │
└─────────────────────────────────────────────┘

Research findings (Step Security, Nov 2025 – Mar 2026): 50 memo transactions updating the payload URL; the attacker rotates both C2 URLs and Solana wallet addresses to evade detection.

Why Solana?

1. Low transaction costs – memo transactions cost fractions of a cent.
2. High throughput – polling every 5 seconds is trivial on Solana’s network.
3. Censorship resistance – you can’t “take down” a blockchain transaction; the C2 address lives forever on‑chain.

Impact on the DeFi Developer Ecosystem

GlassWorm specifically targets developers building DeFi tooling:

• Compromised GitHub tokens are used to force‑push malicious changes to other repositories.
• If you maintain a DeFi protocol SDK, a popular Solidity library, or Anchor program templates, your repos become attack vectors for downstream users.

Harvested data includes:

• 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

Potential consequences for a DeFi developer:

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

Because Solana developers routinely query the blockchain, the malware’s C2 traffic blends with legitimate RPC calls, making network‑based detection extremely difficult.

Immediate Indicators of Compromise

# 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
}'

Defensive Recommendations

Environment Hardening

• Enable GitHub 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.

Supply‑Chain Hardening

• Pin all dependencies to exact versions with integrity hashes (npm ci + package-lock.json).
• Adopt reproducible builds and signed artifacts.
• Implement automated scanning for invisible Unicode characters in source files.

Additional Recommendations

• 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 keep 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

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?

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.

Risk Matrix

Closing Thoughts

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) also make them attractive to attackers.

The best defense is to assume your development environment is hostile and build security layers accordingly:

• Hardware wallets for signing.
• Sandboxed environments for building.
• Verified provenance for dependencies.
• Never, ever keep 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.