# GlassWorm Malware Returns with 73 "Sleeper" Extensions in OpenVSX: A Sophisticated Supply Chain Attack


Researchers discover a major coordinated campaign embedding malicious extensions in Visual Studio Code's open-source extension marketplace, marking a significant escalation in supplier-chain targeting of developers.


## The Threat


Security researchers have uncovered a sophisticated malware campaign dubbed GlassWorm that deployed 73 malicious extensions across OpenVSX (Open VSX Registry), the open-source marketplace for Visual Studio Code extensions. The campaign represents a carefully orchestrated supply chain attack designed to compromise developer environments at scale.


The extensions functioned as "sleepers" — dormant payloads that evaded initial detection by operating silently before activating malicious behavior. Once installed, the extensions could execute arbitrary code, steal sensitive credentials, and establish persistent access to compromised machines. This discovery underscores a critical vulnerability in open-source software distribution channels and highlights how threat actors are increasingly targeting the developer ecosystem as a high-value attack vector.


## Background and Context


### The Evolution of GlassWorm


GlassWorm is not a new threat. The malware family has been observed in the wild since at least 2022, when security researchers first documented its use in targeted attacks against organizations in the technology and finance sectors. However, the scale and sophistication of this latest campaign represents a significant evolution in the threat actor's capabilities and operational ambitions.


Previous GlassWorm variants were distributed through:

  • Compromised legitimate software repositories
  • Typosquatting attacks on popular package names
  • Watering hole campaigns targeting developer communities

    • The shift to OpenVSX represents a more direct and systematic approach to compromising developers at the source level.


    ### OpenVSX: The Target


    OpenVSX serves as an alternative to Microsoft's official Visual Studio Code Marketplace, providing developers with access to thousands of extensions for enhancing IDE functionality. While community-driven and open-source, this decentralized model creates unique security challenges:


  • Minimal submission barriers — Extensions can be published with limited verification
  • Asynchronous review processes — New extensions may not be thoroughly audited before availability
  • Trust-based distribution — Users often assume extensions are legitimate if they appear in the registry
  • Wide developer adoption — OpenVSX serves millions of developers globally

    • These characteristics made OpenVSX an attractive target for threat actors seeking broad reach and minimal friction in distributing malware.


    ## Technical Details


    ### The Attack Mechanism


    The 73 malicious extensions employed a multi-stage infection strategy:


    Stage 1: Installation and Dormancy

  • Extensions appeared legitimate, offering plausible functionality (productivity tools, code formatting, linting utilities)
  • Initial code contained minimal suspicious activity to evade automated scanning
  • Extensions requested permissions typical for legitimate VS Code extensions, masking their malicious intent

    • Stage 2: Activation Triggers

  • Malware remained dormant until specific trigger conditions were met:

    • - Specific repository names in open projects

    - Presence of particular environment variables

    - Network connectivity to command-and-control servers

    - Time-based activation mechanisms


    Stage 3: Payload Execution

    Once activated, extensions performed:

  • Credential harvesting — Stealing SSH keys, API tokens, and authentication credentials from developer machines
  • Environment variable exfiltration — Capturing sensitive project information
  • Clipboard monitoring — Recording copied credentials and source code
  • Reverse shell establishment — Creating persistent backdoor access
  • Lateral movement facilitation — Using compromised machines as pivot points for network intrusion

    • ### Evasion Techniques


    The extensions employed sophisticated evasion methods:


    | Technique | Purpose |

    |-----------|---------|

    | Code obfuscation | Making malicious code difficult to analyze statically |

    | Dynamic loading | Fetching additional payloads at runtime from remote servers |

    | Anti-debugging | Detecting and disabling debugging tools |

    | Environment detection | Checking for sandbox/analysis environments and disabling payloads |

    | Signature manipulation | Modifying their own signatures to avoid hash-based detection |


    ## Implications


    ### High-Risk Impact


    The compromise of developer machines carries outsized security consequences:


    Direct Impacts:

  • Source code theft — Access to proprietary code repositories and intellectual property
  • Supply chain poisoning — Compromised developers pushing malicious code into production systems
  • Credential exposure — Theft of authentication tokens enabling unauthorized access to organizational infrastructure
  • Infrastructure compromise — Using developer access to penetrate corporate networks

    • Cascading Effects:

  • Organizations relying on code commits from infected developers face unknowing distribution of backdoors
  • Third-party software utilizing compromised libraries or dependencies may inherit malware
  • Enterprise cloud infrastructure accessed through developer credentials becomes vulnerable
  • Customer environments downstream may be compromised through trojanized software releases

    • ### Affected Organizations


    While attack scope remains under investigation, organizations most at risk include:


  • Software development companies using OpenVSX extensions
  • Technology firms with developer-heavy workforces
  • Financial institutions employing software engineers
  • Government contractors with sensitive development activities
  • Open-source projects relying on community contributions

    • ## Detection and Remediation


    ### Identifying Compromised Systems


    Organizations should investigate machines where:

  • OpenVSX extensions were installed between specific date ranges (pending official attribution timelines)
  • Unusual outbound network connections appear from VS Code processes
  • SSH key files show recent modification timestamps
  • Command-and-control domains appear in network traffic logs
  • Unauthorized commits appear in repository history

    • ### Immediate Actions


    1. Audit OpenVSX Installations

    - Identify all machines with OpenVSX extensions

    - Cross-reference against the list of malicious extension identifiers

    - Document installation dates and affected users


    2. Revoke and Rotate Credentials

    - Reset SSH keys on potentially compromised machines

    - Rotate API tokens and authentication credentials

    - Change passwords for accounts accessed from affected systems

    - Review and revoke any unusual SSH authorized_keys entries


    3. Investigate Repository Activity

    - Audit Git commit history for suspicious changes

    - Review pull requests and code reviews from affected developers

    - Check for unauthorized deployments or releases


    4. Isolate and Analyze

    - Quarantine affected machines for forensic analysis

    - Capture memory dumps and filesystem snapshots

    - Analyze outbound network connections and process trees


    ## Recommendations


    ### For Individual Developers


  • Review installed extensions — Audit all OpenVSX extensions, removing unnecessary or unfamiliar ones
  • Verify extension authenticity — Check publisher information and community reviews before installation
  • Monitor extension permissions — Be cautious of extensions requesting excessive permissions
  • Keep VS Code updated — Ensure the latest security patches are installed
  • Rotate credentials proactively — Change SSH keys and API tokens as a precaution

    • ### For Organizations


  • Establish extension policies — Create whitelists of approved extensions
  • Implement endpoint detection — Deploy EDR solutions to detect malware activation and C2 communication
  • Enhance credential management — Use hardware security keys and centralized secret management
  • Monitor developer activity — Track Git commits and deployments for suspicious patterns
  • Conduct threat hunting — Proactively search for indicators of compromise in network logs
  • Develop incident response procedures — Establish clear processes for responding to developer machine compromises
  • Supply chain security review — Assess risks from other open-source tool dependencies

    • ### For OpenVSX Maintainers


  • Strengthen review processes — Implement more rigorous auditing of new and updated extensions
  • Implement code scanning — Deploy automated malware detection in submission pipelines
  • Add reputation systems — Create mechanisms for community reporting and publisher trust scoring
  • Security advisories — Maintain clear communication channels for reporting vulnerabilities
  • Extension signing — Consider implementing cryptographic signing for verified extensions

    • ## Conclusion


    The GlassWorm campaign represents a maturing threat landscape where attackers recognize the asymmetric value of compromising developer environments. By targeting the tools developers trust daily, threat actors gain access to sensitive intellectual property and organizational infrastructure with minimal detection.


    The discovery underscores a critical principle of modern cybersecurity: trust is a vulnerability. Organizations must move beyond assuming that tools and repositories are inherently safe, instead implementing layered verification, monitoring, and incident response capabilities.


    Developers and security teams should treat this incident as a wake-up call to strengthen their supply chain security posture — not just for VS Code extensions, but across all development tools and dependencies. In an ecosystem where a single compromised extension can compromise an entire organization, vigilance is no longer optional.