Solana Memo Program as Malware C2: Inside the GlassWorm Supply Chain Attack That Weaponized the Blockchain

The Attack Nobody Expected

When Solana engineers designed the Memo program, they envisioned legitimate use cases: payment references, human-readable notes, compliance metadata. What they didn't anticipate was that in March 2026, threat actors would repurpose it as an uncensorable, immutable command-and-control (C2) infrastructure for one of the most sophisticated supply chain attacks the open source ecosystem has ever seen.

The GlassWorm and ForceMemo campaigns have compromised hundreds of GitHub accounts and Python repositories, hijacked popular npm packages in the React Native ecosystem, and weaponized Solana's decentralized architecture to create C2 channels that are effectively impossible to take down.

How Solana Memo Program Became a C2 Channel

The Solana Memo program (MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr) is trivially simple. It takes arbitrary data as instruction data and logs it as a transaction memo. Any wallet can call it. The data is stored permanently on-chain.

The GlassWorm attackers exploited these properties with elegant simplicity:

1. Create a Solana wallet that becomes the C2 address
2. Send transactions to yourself with Memo instructions containing encrypted URLs
3. Malware queries the Solana RPC for transaction history on that wallet
4. Read memo data from the most recent transaction to get the current C2 URL
5. Update the C2 by simply sending a new transaction with updated memo data

The brilliance and the danger is in what this architecture provides the attacker:

• No domain to seize. Traditional C2 relies on domains or IPs that can be taken down. A Solana address is permanent.
• No server to block. The data is replicated across every Solana validator. There are hundreds of public RPC endpoints.
• Instant updates. Sending a new Memo transaction costs fractions of a cent and takes about 400ms.
• Perfect deniability. Anyone can read Solana transaction data. The RPC calls look identical to legitimate blockchain queries.

The earliest transaction on the attacker C2 wallet was recorded on November 27, 2025, meaning this infrastructure was being set up months before the mass compromise began.

The Kill Chain: From VS Code to Your Repository

Phase 1: Credential Harvesting via GlassWorm

GlassWorm initially spread through malicious VS Code and Cursor IDE extensions published to the OpenVSX marketplace. The extensions appeared legitimate but contained obfuscated payloads using invisible Unicode characters to evade code review.

Once installed, GlassWorm Stage 3 payload deployed a dedicated credential theft module targeting git credential fill output, VS Code extension storage (where GitHub auth tokens live), ~/.git-credentials files, GITHUB_TOKEN environment variables, and npm authentication tokens from .npmrc.

Stolen credentials were validated against the GitHub API and exfiltrated to attacker-controlled servers.

Phase 2: Silent Repository Poisoning (ForceMemo)

Starting March 8, 2026, the attackers began using stolen GitHub tokens to compromise repositories at scale. The technique was surgically precise:

1. Clone the target repo
2. Take the latest legitimate commit on the default branch
3. Append obfuscated malware to a key Python file (setup.py, main.py, app.py)
4. Rebase the commit, preserving the original commit message and author date
5. Force-push to the default branch

The result: the repository looks unchanged. Same commit message, same author, same code except for the malicious payload appended at the end. The only telltale sign is a discrepancy between the author date and the committer date.

Some of the date gaps were staggering. A repository last legitimately committed in 2017 was silently poisoned in 2026, a 9-year gap hidden behind preserved metadata.

Phase 3: npm Package Hijacking

The campaign extended beyond GitHub repositories. Two popular React Native packages, react-native-country-select (~20,000 weekly downloads) and react-native-international-phone-number (~10,000 weekly downloads), were hijacked with malicious versions containing the same Solana-based C2 mechanism.

The malicious install.js script waited 10 seconds post-installation before activating, checked system locale, timezone, and username, immediately exited on Russian-configured systems (a common attribution indicator), retrieved encrypted C2 URLs from Solana Memo transactions, and downloaded and executed a second-stage payload capable of arbitrary code execution.

The Payload: Three Layers of Obfuscation

Every compromised repository contained an identical payload, stored in a variable named lzcdrtfxyqiplpd, a marker that security researchers now use to track affected repos via GitHub Code Search.

The obfuscation chain: Base64 decode, zlib decompress, XOR decrypt (key: 134). The obfuscation wrapper used randomized 15-character variable names but maintained the same structure across all injections.

Once decrypted, the payload executes entirely in memory with no files written to disk, and proceeds to steal cryptocurrency wallet data and sensitive credentials.

Why Blockchain C2 Changes the Threat Model

This attack represents a fundamental shift in how we think about blockchain security. The threat is not just smart contract exploits or DeFi protocol vulnerabilities anymore. The blockchain itself, specifically its permissionless, immutable nature, is being weaponized as infrastructure for traditional attacks.

Consider the defense challenge. Traditional C2 can be disrupted via domain takedowns, IP blocking, certificate revocation, server seizure, and hosting provider cooperation. Blockchain C2 has no domain to seize, hundreds of RPC endpoints that cannot all be blocked, no certificates involved, data replicated globally with no single point of seizure, and no hosting provider to cooperate.

The only viable defenses are at the endpoint level:

1. Monitor outbound Solana RPC calls from non-blockchain applications
2. Flag getSignaturesForAddress and getTransaction calls from Python/Node processes that should not be making them
3. Audit IDE extensions by reviewing permissions, checking publisher history, and limiting marketplace sources
4. Implement branch protection rules to require pull requests and prevent force-pushes to default branches
5. Pin dependency versions and never use latest in production
6. Verify commit signatures since GPG-signed commits would have revealed the tampering immediately

Lessons for the Blockchain Security Community

1. Blockchains are neutral infrastructure. Just as Tornado Cash was used for money laundering, the Memo program is now used for C2. Permissionless systems will be used by adversaries.

2. The attack surface is expanding. DeFi security is not just about smart contracts anymore. The same blockchains hosting your protocols are hosting adversary infrastructure.

3. RPC providers are the chokepoint. While on-chain data cannot be censored, RPC providers can monitor for known malicious wallet queries and flag suspicious patterns.

4. Developer tooling is the weakest link. The initial compromise vector was IDE extensions, tools that developers install with full trust and broad system access.

5. Git history is not an integrity guarantee. Force-pushes can rewrite history. Without signed commits and branch protection, repository integrity is an illusion.

The GlassWorm/ForceMemo campaign is still active as of mid-March 2026. If you maintain Python packages on GitHub or use React Native packages from npm, audit your repositories and dependencies now. The attacker infrastructure is on-chain, permanent, and watching.

---

References: StepSecurity threat intelligence report, Sonatype Security Research (sonatype-2026-001153), Aikido Security GlassWorm analysis