GlassWorm shows how VS Code extensions can become worm carriers

At a glance

What this is: GlassWorm is a self-propagating worm that abuses VS Code extension supply chains to steal credentials, persist through republishing, and hide command-and-control traffic in blockchain activity.

Why it matters: It matters because development tooling, marketplace trust, and non-human credentials now sit on the same attack surface, which means IAM, AppSec, and platform teams have to govern extension and token exposure together.

By the numbers:

• GlassWorm targets 49 cryptocurrency-wallet extensions.

👉 Read Knostic's analysis of the GlassWorm VS Code extension supply-chain worm

Context

GlassWorm is a supply-chain worm built for the developer tooling ecosystem. It enters through compromised Visual Studio Code extensions, hides malicious loader logic with invisible Unicode characters, and then steals the credentials that let it move laterally through extension marketplaces.

The governance gap is straightforward: marketplace trust assumes extension publishers, signing paths, and review processes remain intact, while developer credentials are often treated as ordinary secrets rather than high-impact non-human identities. That combination creates a propagation path that looks like software distribution but behaves like identity compromise.

For IAM and NHI teams, this is not just an extension-review problem. It is a lifecycle problem for tokens, publishing rights, and developer credentials that can be reused to reintroduce the same malicious package under a new identity.

Key questions

Q: How should security teams govern credentials that can publish software packages?

A: Treat every credential that can publish, sign, or republish software as a privileged non-human identity. Assign an owner, enforce rotation and revocation, require approval for publisher changes, and review distribution rights on the same cadence as other high-risk access. Publishing rights are not ordinary developer convenience; they are supply-chain control points that can propagate malware at scale.

Q: Why do developer credentials create supply-chain risk beyond repository access?

A: Because those credentials often control release, signing, and marketplace distribution, not just source-code access. If an attacker steals them, they can republish trusted artifacts, inherit legitimate distribution paths, and reach downstream users without breaking perimeter defenses. The risk comes from identity reuse across the software lifecycle, not from source control alone.

Q: What do security teams get wrong about extension marketplace reviews?

A: They often assume visible code review is enough to catch malicious packages. Hidden Unicode, obfuscated loaders, and republishing through trusted accounts can all bypass that assumption. Effective review must include raw-text inspection, automated normalization, and identity checks on the publishing path, not only human inspection of the extension contents.

Q: Who is accountable when a stolen publishing token is used to spread malware?

A: Accountability sits with the team that owns the publishing identity, the platform that governs distribution, and the security function that defines revocation and monitoring requirements. In practice, governance must cover the full lifecycle of the token, from issuance to offboarding, because stale publishing access becomes an attack primitive once compromise occurs.

Technical breakdown

How GlassWorm hides malicious extension logic

GlassWorm uses invisible Unicode variation selectors to conceal loader logic inside extension code, making the malicious path harder to spot in normal review and diff workflows. That matters because code review often relies on rendered text, syntax highlighting, and human inspection, all of which can miss hidden characters. Once the extension executes, the worm can transition from dormant code to active credential theft without changing its visible structure. The technical trick is not only obfuscation but review bypass through representation mismatch.

Practical implication: add Unicode normalization and hidden-character scanning to extension and package review pipelines.

Credential theft from developer and marketplace identities

The worm targets npm, GitHub, OpenVSX, Git, and SSH credentials because those identities control code publishing, repository access, and extension distribution. In NHI terms, these are high-value publishing secrets with direct supply-chain reach, not low-risk developer conveniences. Once stolen, they let the attacker republish packages, alter trusted artifacts, and keep the worm alive through legitimate channels. This is classic standing privilege abuse, but applied to software distribution rights rather than infrastructure access.

Practical implication: inventory every credential that can publish, sign, or republish code and treat it as a privileged NHI.

Blockchain-based command-and-control and self-propagation

GlassWorm uses Solana blockchain memo fields as a command-and-control path, which gives it a noisy public substrate that blends into ordinary blockchain traffic. The worm then self-propagates by compromising and republishing extensions on OpenVSX and other marketplaces, turning stolen identity into automated distribution. That combination makes detection harder because the C2 layer is decoupled from conventional infrastructure and the propagation layer uses legitimate marketplace mechanics. The result is an attack that behaves like software supply chain compromise with worm properties.

Practical implication: monitor for anomalous marketplace republishing and treat blockchain-based C2 as a distinct detection pattern.

Threat narrative

Attacker objective: The attacker aims to turn trusted developer tooling and publisher identities into a durable worm distribution channel that steals credentials and spreads malicious extensions.

1. Entry via a malicious Visual Studio Code extension that hides loader logic with invisible Unicode characters and reaches developers through trusted marketplace channels.
2. Credential access through theft of npm, GitHub, OpenVSX, Git, and SSH secrets that control publishing and repository operations.
3. Escalation through republishing compromised extensions and using stolen credentials to extend the worm across additional marketplaces.
4. Impact through persistent supply-chain propagation, credential reuse, and blockchain-based command-and-control that keeps malicious code in circulation.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

GlassWorm is a supply-chain identity breach, not just a malware event. The worm succeeds because developer publishing credentials function as privileged non-human identities with direct distribution power. When those credentials are stolen, the attacker does not need to break the marketplace itself; they simply become a trusted publisher. Practitioners should treat extension publishers, npm tokens, and GitHub credentials as governed identities with lifecycle controls, not as background tooling secrets.

Invisible Unicode creates a review-gap concept we should name: representation drift. The malicious logic is present in the package, but the human reviewer sees a cleaner rendering than the runtime executes. That gap breaks the assumption that code review alone can reliably validate package intent. The implication is that supply-chain assurance must account for how code is displayed, parsed, and executed, not only what a reviewer believes they saw.

Self-propagation changes the blast radius of a single stolen credential. One compromised publishing identity can republish the worm across marketplaces, which means access scope is multiplied by distribution rights rather than by infrastructure privileges. OWASP NHI and Zero Trust thinking both apply here because the attacker is abusing trust relationships, not brute-forcing endpoints. Practitioners should assume a stolen publishing token can become a malware distribution mechanism within minutes.

Blockchain C2 makes conventional detection coverage incomplete. Solana memo fields are not a normal C2 pattern for most enterprise monitoring stacks, so the attack can hide in plain sight unless teams look for the behaviour rather than the port or host. That matters for SecOps, but it also matters for IAM because compromised identities are what enable the worm to keep re-entering the ecosystem. The practitioner takeaway is to connect threat detection, identity telemetry, and marketplace governance into one control plane.

Developer tooling now sits inside the NHI perimeter. Knostic is right to frame AI coding tools as high-value targets, but the broader lesson is that IDE extensions, package registries, and bot-controlled publishing rights all belong in the same governance model. Credential lifecycle, access review, and revocation standards that stop at human employees leave the most reusable identities outside scope. Practitioners should extend governance to every identity that can publish software.

From our research:

• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For the broader control model, see Ultimate Guide to NHIs , Static vs Dynamic Secrets for why long-lived credentials remain such an efficient attacker path.

What this signals

The next control boundary is not the endpoint, it is the publisher identity. Once package registries, IDE extensions, and AI coding tools can all be repurposed through stolen credentials, access governance has to move from account-centric review to distribution-centric oversight.

Representation drift: a package can look clean in review and behave differently at runtime when hidden Unicode or obfuscated loaders are present. That means software supply-chain assurance now needs parsing-aware inspection, not just policy and approval workflows.

With only 44% of developers following security best practices for secrets management, according to The State of Secrets in AppSec, the operational gap is already wide enough for worms like GlassWorm to exploit. Teams should watch for publisher identities with broad reuse, weak rotation, and no offboarding discipline.

For practitioners

• Classify publishing tokens as privileged NHIs Put npm, GitHub, OpenVSX, Git, and SSH credentials that can publish or republish code into the same governance tier as other high-risk service identities. Review owners, rotation schedules, and revocation paths for every token that can distribute artifacts.
• Scan extension content for hidden Unicode and loader obfuscation Add Unicode normalization, invisible-character detection, and package diff checks to extension and dependency review pipelines. Use pre-publish gates that inspect rendered and raw text so hidden logic cannot bypass human review.
• Monitor for anomalous republishing across marketplaces Correlate publishing events, token use, and extension updates across OpenVSX and adjacent marketplaces. Alert when a credential suddenly republishes multiple packages, changes distribution patterns, or appears from an unusual developer context.
• Treat blockchain-based C2 as a distinct detection pattern Add detections for Solana memo-field activity associated with malware retrieval and tie them to identity compromise indicators. Threat hunting should connect on-chain lookups with developer token abuse rather than treating them as separate problems.
• Expand offboarding to developer publishing rights When a contributor leaves a project or role changes, revoke marketplace, repository, and signing access immediately. The goal is to prevent stale publishing rights from becoming a propagation path for compromised extensions.

Key takeaways

• GlassWorm shows that developer publishing identities can be turned into worm carriers when supply-chain trust and credential governance are not aligned.
• The attack combines hidden Unicode, credential theft, marketplace republishing, and blockchain-based C2 to create a propagation path that looks legitimate until it is too late.
• The control that matters most is lifecycle governance for publishing credentials, because revocation, review, and normalization are what shrink the attack path.

Key terms

• Supply-chain identity breach: A compromise where the attacker abuses trusted publishing, signing, or distribution identities to reach downstream users. The core issue is not only malicious code, but the misuse of legitimate credentials and workflows that let that code enter a trusted ecosystem.
• Representation drift: A mismatch between how content appears to a human reviewer and how it is parsed or executed by tooling. In supply-chain security, drift can hide malicious logic inside otherwise normal-looking code, which makes raw-text inspection and normalization essential controls.
• Publishing credential: A secret or account that can release, republish, or sign software artifacts for distribution. These credentials are high-impact non-human identities because compromise can turn ordinary build or extension workflows into malware delivery channels.
• Blockchain command and control: A command-and-control method that uses blockchain transactions or metadata to convey instructions or retrieve payloads. It complicates detection because the traffic may blend into legitimate on-chain activity while still enabling attacker-controlled execution.

What's in the full article

Knostic's full research covers the operational detail this post intentionally leaves for the source:

• YARA signature logic for GlassWorm behaviours across extension loaders, credentials, and self-propagation.
• Detailed detection coverage for Solana blockchain C2, including memo-field based retrieval patterns.
• Specific indicators tied to npm, GitHub, OpenVSX, Git, and SSH credential theft.
• Repository-level examples for tuning and adapting the rules to local environments.

👉 Knostic's full post covers the YARA detections, credential abuse patterns, and propagation details behind GlassWorm.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.