GlassWorm: Invisible-Code Supply Chain Worm Attack

Date Observed: October 2025 – ongoing (March 2026)

Ecosystem: VS Code/OpenVSX extensions, npm packages, GitHub repositories

Attack Type: Stealthy supply-chain compromise → hidden payload execution → credential theft → lateral spread

Key Takeaways:

• Invisible payloads: Malicious code is hidden in Unicode characters, making it invisible in editors and diffs.

• Decentralized C2: Uses Solana blockchain with Google Calendar fallback for resilient command delivery.

• Wide propagation: 72+ extensions, 150+ GitHub repos, npm packages, and hundreds of Python projects affected across multiple related campaigns.

• Credential theft: Targets GitHub/npm tokens, SSH keys, and ~49 crypto wallet extensions.

GlassWorm is a highly stealthy supply-chain malware campaign that emerged in October 2025 and rapidly expanded across the developer ecosystem as first reported by Koi Security. Its defining innovation is the use of invisible Unicode characters to hide malicious code inside seemingly clean VS Code extensions and npm packages.

While this initially appears to target developer environments, its real impact extends into CI/CD pipelines. When infected packages or extensions are introduced into a repository, the malicious code can be executed during automated build processes where security visibility is typically limited and trust assumptions are high.

To developers and reviewers, the code appears empty. No suspicious diff. No visible payload. Yet when executed, it silently loads a multi-stage malware chain.

During execution, GlassWorm retrieves commands from decentralized infrastructure (primarily the Solana blockchain), deploys its payload (“ZOMBI”), and attempts credential exfiltration. In CI/CD contexts, this can include access tokens, build secrets, and signing credentials; enabling attackers to tamper with artifacts, move laterally across repositories, and compromise downstream releases.

By early 2026, the campaign had evolved into a self-propagating supply-chain worm. Crucially, this propagation is not limited to developer machines as it can leverage build systems as a distribution point, turning CI pipelines into amplification channels for further compromise.

Figure: GLASSWORM attack progression

Scope and Impact of the Attack

Scope

• 72+ malicious extensions via dependency abuse (per Socket)

• 150+ GitHub repos in one week, March 2026 (per Aikido)

• ~130K combined npm downloads backdoored and distributed (per StepSecurity)

• Hundreds of Python repos (ForceMemo Campaign coined by StepSecurity)

• ~49 crypto wallet extension types

Targeted across multiple related campaigns and variants.

Impact

GlassWorm’s impact extends far beyond individual developers, targeting the software delivery pipeline itself. Data shows an estimated 1600% rise in affected package artifacts over the last 7 days alone.

While the full scale of the attack is still being evaluated, reports from OpenSourceMalware indicate that GlassWorm has already compromised 433 components across the ecosystem, including:

• npm packages and Python code

• GitHub repositories

• VSCode extensions

This broad reach demonstrates how the worm spreads through multiple layers of the development environment, making defense at the pipeline level critical.

Attack Sequence

Step 1: Malware Ingestion

A developer unknowingly installs a compromised npm package or a VS Code extension containing hidden malicious logic. This dependency is committed to the repository or referenced in build configuration. Once the build system runs (e.g., pull request, commit, scheduled run), it installs the affected dependencies and executes scripts as part of the standard workflow.

Step 2: Build Execution

During dependency installation or script execution, the hidden Unicode-based payload is interpreted and executed, corrupting the build environment.

Step 3: Command Retrieval

The malware fetches commands from the Solana blockchain by decoding data embedded in blockchain transactions. If unavailable, it falls back to Google Calendar events.

This design makes takedown extremely difficult as there is no single server to block.

Step 4: Credential and Environment Access/Exfiltration

The malware accesses environment variables and CI secrets, including:

• Repository access tokens

• Package registry credentials

• Cloud and deployment keys

However, some variants reportedly abort the execution if any Russian Locale is found to be associated.

Step 5: Payload Deployment and Propagation

Using stolen credentials, the attacker can:

• Modify repositories or inject additional malicious code

• Publish compromised packages

• Tamper with build outputs

• Spread laterally across CI-integrated systems

Why GlassWorm Matters to DevOps Teams

GlassWorm matters because it turns the build environment itself into the attack surface. The malicious logic may arrive through a package, extension, or dependency update, but the real danger appears when trusted automation executes it inside a high-privilege CI/CD environment.

For DevOps teams, this means:

• the pipeline itself becomes a target

• trusted automation can execute untrusted logic

• secrets and tokens become accessible when malicious code runs inside the pipeline

• compromise can occur without any malicious code ever being merged into the application

This fundamentally shifts the threat model from “secure code” to secure execution.

How InvisiRisk Neutralizes the Attack Sequence

Defense 1 : Blocking Unauthorized Outbound Connections

InvisiRisk monitors all network activity in real time. By denying unexpected calls to unknown IPs, external APIs, or blockchain nodes, InvisiRisk ensures the environment remains isolated from malicious command-and-control servers.

Defense 2 : Secret Exfiltration Detection

InvisiRisk identifies and denies suspicious outbound transfers of credential theft. This ensures that harvested secrets or tokens are blocked at the source, preventing them from ever leaving your secure build environment.

Defense 3 : Blocking Unauthorized Actions

InvisiRisk validates every attempt to push code or publish artifacts. By restricting these actions to authorized policies, InvisiRisk prevents attackers from using stolen credentials to propagate the worm to downstream users.

Defense 4 : Stability Buffer Period

A mandatory cooling-off period for newly published dependencies allows the security community time to identify and pull malicious versions, preventing "zero-day" packages from entering your pipeline.

Together, these controls convert GlassWorm from a silent, self-spreading worm into a contained and detectable event preventing the attack at execution time.