Between January 31 and March 9, 2026, attackers deployed 72 malicious extensions on the Open VSX marketplace, affecting 151 GitHub repositories. The campaign, known as GlassWorm, used a two-stage attack: first, establishing trust with legitimate-looking extensions, then delivering malware through dependency chains. Socket's research team identified the pattern after noticing unusual extension update behavior across multiple projects.
Timeline
January 31, 2026: Attackers begin uploading extensions to Open VSX that appear benign. Initial versions contain functional code with no obvious malicious behavior.
March 3-9, 2026: The attack enters its active phase. Attackers push updates to the 72 extensions, using extensionPack and extensionDependencies fields to pull in malicious payloads. During this six-day window, 151 GitHub repositories automatically pulled the poisoned updates.
March 9, 2026: Socket publishes findings after detecting the coordinated update pattern across multiple extensions.
Which Controls Failed
Dependency verification: The affected projects had no mechanism to verify the integrity of extension updates before installation. When the extensions pushed new versions, developer environments automatically pulled them.
Update monitoring: No alerting existed for dependency changes. The shift from benign to malicious happened in routine updates that triggered no review.
Blast radius containment: Extensions ran with full access to the development environment. Once compromised, they could read source code, exfiltrate credentials, and modify build artifacts.
Supply chain visibility: Teams lacked inventories of their extension dependencies. The extensionDependencies field created transitive dependencies that weren't tracked in any manifest or bill of materials.
Anomaly detection: The coordinated update pattern across 72 extensions should have triggered alerts, but no monitoring was in place to catch synchronized changes across unrelated packages.
What Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that bespoke and custom software be developed securely. This includes "security of development processes and tools." Your IDE extensions are part of your development toolchain. If you process payment data, those extensions fall under scope.
NIST 800-53 Rev 5 Control SA-12 addresses supply chain protection. It requires organizations to "employ integrity verification tools to detect unauthorized changes to software, firmware, and information." Extension updates are software changes. You need cryptographic verification before installation.
ISO/IEC 27001:2022 Control 8.31 (Security of information in use) requires protection of information during processing. Source code in your IDE is information in use. An extension that can read arbitrary files violates this control unless you've explicitly scoped and approved that access.
OWASP ASVS v4.0.3 Section 14.2 covers dependency management. Requirement 14.2.3 states: "Verify that all components are up to date with proper security configuration(s) and version(s)." But "up to date" doesn't mean "automatically pull latest." It means verified, reviewed updates.
Lessons and Action Items
Pin your extension versions. Stop using version ranges or "latest" tags. Lock to specific versions in your team's configuration. When an extension updates, someone should decide to upgrade, not have it happen automatically.
Create a .vscode/extensions.json or equivalent with exact versions:
{
"recommendations": [
"[email protected]"
]
}
Build an extension allowlist. Your team doesn't need access to the entire marketplace. Maintain a curated list of approved extensions, with specific versions, verified by your security team. Block installation of anything not on the list.
Implement extension signing verification. Before any extension runs in your environment, verify its signature against a known publisher key. If the signing key changes between versions, that's a red flag requiring manual review.
Monitor extension permissions. Extensions declare required permissions in their manifests. Track what each approved extension can access. If an update requests new permissions, treat it as a new security review, not a routine update.
Separate development environments by sensitivity. Your developers working on payment processing code shouldn't use the same IDE configuration as those building marketing websites. High-sensitivity projects need stricter extension policies and more aggressive monitoring.
Generate SBOMs that include toolchain dependencies. Your software bill of materials should list IDE extensions, build plugins, and CI/CD tools -- not just application dependencies. When an incident happens, you need to know which repositories were exposed to which versions of which extensions.
Set up extension update alerts. Create monitoring that flags when multiple extensions from different publishers update within a short time window. The GlassWorm campaign's six-day coordinated update window would have been detectable with basic correlation rules.
Review extension source code before approval. For any extension that can read your source code or access credentials, examine its source. Open VSX is open-source, so this is possible. Look for obfuscated code, network calls to unexpected domains, or filesystem access beyond what the extension's stated purpose requires.
Implement network egress controls for development environments. Extensions shouldn't be able to make arbitrary network connections. Use allowlists for outbound traffic. If an extension needs to phone home for telemetry, that destination should be documented and approved.
The GlassWorm attack succeeded because it exploited the gap between "trusted once" and "trusted forever." Your team approved an extension based on its initial behavior, then gave it permanent access to update itself without oversight. Close that gap. Every update is a new trust decision.
