What Happened
Between late 2024 and early 2025, attackers planted 73 malicious extensions in the OpenVSX registry—an open-source alternative to the Visual Studio Code Marketplace. These extensions appeared legitimate at publication but contained dormant malicious code. Six of these extensions were later activated through updates to deliver the GlassWorm malware, which exfiltrates sensitive data from developer environments. Socket's research team identified the campaign after detecting suspicious update patterns across the compromised extensions.
The attack represents an evolution in supply chain tactics: rather than immediately deploying malicious payloads that trigger automated security scans, attackers published benign-looking extensions, waited for adoption, then weaponized them through routine updates that developers trust.
Timeline
Initial Compromise Period (Late 2024 - Early 2025)
- 73 extensions published to OpenVSX registry
- Extensions passed initial review processes
- Developers began installing and using the extensions in their environments
Activation Phase (Early 2025)
- Six extensions received updates containing malicious payloads
- GlassWorm malware began exfiltrating data from compromised systems
- Socket detected the malicious behavior and published findings
Discovery and Response (2025)
- Socket identified the full scope of 73 sleeper extensions
- OpenVSX maintainers began removal process
- Security community alerted to the campaign
The delay between publication and activation is the critical element. Your security tools likely scanned these extensions when they were first installed and found nothing suspicious. The malicious code only appeared in subsequent updates—updates that many teams apply automatically or with minimal review.
Which Controls Failed or Were Missing
Supply Chain Verification
The OpenVSX registry lacked sufficient publisher verification. Unlike some commercial registries that require identity verification and reputation building, OpenVSX allowed anonymous publication of extensions that could later be updated with malicious code.
Post-Installation Monitoring
Most organizations scan dependencies at installation time but don't continuously monitor for behavioral changes after updates. The six activated extensions operated in developer environments for an unknown period before detection.
Update Review Process
Teams treated extension updates as routine maintenance rather than new security events. The updates that activated the malware likely went through automated or cursory approval processes.
Behavioral Analysis
Traditional signature-based detection missed the threat because the malicious code wasn't present initially. The attack also used invisible Unicode characters to hide malicious code—a technique that evades simple code review.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that software development personnel receive training on secure coding techniques, including how to avoid common coding vulnerabilities. This includes supply chain risks. If your environment processes payment data and uses OpenVSX extensions, you must demonstrate that your team understands the risks of third-party code and has processes to verify its integrity.
NIST 800-53 Rev 5 Control SA-12 (Supply Chain Protection) requires organizations to employ anti-counterfeit, anti-tamper, and other protections for acquired systems and components. For development tooling, this means:
- Verifying the authenticity of extensions before installation
- Monitoring for unauthorized modifications
- Maintaining an inventory of all third-party components
ISO 27001 Control 5.19 (Information Security in Supplier Relationships) requires you to define and agree upon information security requirements with suppliers—including open-source registries and extension publishers. You need documented processes for evaluating and monitoring the security of software you acquire, even when it's free.
SOC 2 Type II Common Criteria CC6.1 addresses logical and physical access controls. If you're pursuing SOC 2 certification, auditors will ask how you control what software enters your development environment and how you detect unauthorized changes. "We install extensions from OpenVSX" without additional controls won't satisfy this requirement.
The GlassWorm campaign specifically exploits a gap in how most teams interpret these requirements. You likely have controls for evaluating new software, but do you re-evaluate that software when it updates? The standards don't distinguish between initial installation and subsequent updates—both are supply chain events that require security review.
Lessons and Action Items for Your Team
Implement Continuous Dependency Monitoring
Don't just scan extensions at installation. Use tools that monitor for behavioral changes after updates. Socket, Snyk, and similar platforms can detect when an extension begins making network requests or accessing files it didn't touch before. Configure alerts for any extension that changes its permission requirements or communication patterns.
Treat Updates as New Security Events
Create a policy that requires security review for extension updates, not just initial installations. For critical development environments, implement a staging process: updates go to a test environment first, run for a defined period (48-72 hours minimum), and only promote to production after behavioral analysis confirms no suspicious activity.
Inventory Your Extensions
Generate a complete list of every extension installed across your development environments. For each one, document:
- Publisher identity and reputation
- Permissions requested
- Last update date
- Number of installations in your environment
- Business justification for the extension
If you can't justify why an extension is installed, remove it. The GlassWorm campaign succeeded partly because organizations had accumulated extensions without clear ownership or review.
Restrict Extension Sources
If you don't need OpenVSX specifically, restrict your IDE configuration to only allow extensions from verified sources. For VS Code, this means the official Microsoft marketplace with verified publishers. If you must use OpenVSX, maintain an allowlist of approved extensions and block installation of anything not on the list.
Review Unicode Handling in Code Review
The GlassWorm campaign used invisible Unicode characters to hide malicious code. Configure your code review tools to flag non-printable characters and bidirectional Unicode text. GitHub, GitLab, and Bitbucket all support this—enable it in your repository settings.
Document Your Supply Chain Risk Assessment
For SOC 2, ISO 27001, or PCI DSS compliance, you need documented evidence that you assessed the risk of third-party software. Create a supply chain risk register that includes:
- All third-party code sources (registries, package managers, extension marketplaces)
- Risk level for each source
- Compensating controls you've implemented
- Review schedule and ownership
The six activated extensions in this campaign are likely still running in some environments. Check your extension lists against Socket's published indicators. But more importantly, assume that additional sleeper extensions exist that haven't been activated yet. Your goal isn't to play whack-a-mole with known threats—it's to build monitoring that detects the activation pattern regardless of which extensions are compromised.
