Full Report
Eclipse Foundation, which maintains the open-source Open VSX project, said it has taken steps to revoke a small number of tokens that were leaked within Visual Studio Code (VS Code) extensions published in the marketplace. The action comes following a report from cloud security company Wiz earlier this month, which found several extensions from both Microsoft's VS Code Marketplace and Open VSX
Analysis Summary
# Incident Report: Leaked VS Code Extension Tokens in Open VSX
## Executive Summary
The Eclipse Foundation initiated an emergency response after cloud security firm Wiz discovered that access tokens had been inadvertently leaked within several Visual Studio Code (VS Code) extensions published on both the Microsoft VS Code Marketplace and the Open VSX registry. These exposed tokens posed a high risk of supply chain compromise, potentially allowing unauthorized actors to modify or publish malicious extensions. The foundation contained the threat by immediately revoking the compromised tokens.
## Incident Details
- Discovery Date: Early October 2025 (Reported by Wiz)
- Incident Date: Ongoing leaks prior to discovery date
- Affected Organization: Eclipse Foundation (maintainers of Open VSX), affected extension publishers.
- Sector: Software Development / Open Source Infrastructure
- Geography: Global (Internet-facing registries)
## Timeline of Events
### Initial Access (Exposure)
- Date/Time: Prior to early October 2025
- Vector: Developer mistake/Error in secure practice
- Details: Developers inadvertently included their access tokens within the codebase of VS Code extensions published to public repositories. The tokens were subsequently found in public repositories, including those supporting the Open VSX marketplace.
### Lateral Movement (Potential)
- Date/Time: N/A (No confirmed lateral movement prior to revocation)
- Vector: Potential Abuse of Leaked Tokens
- Details: If successfully exploited, an attacker with a leaked token could gain sufficient privileges to modify existing extensions or publish new malicious packages, effectively poisoning the software supply chain.
### Data Exfiltration/Impact (Potential)
- Date/Time: N/A
- Vector: Unauthorized Modification/Publication
- Details: Potential for malware distribution via compromised extensions. Note: Although the "GlassWorm" campaign was mentioned, the malware itself was not described as self-replicating and required stolen credentials, differing from a direct token abuse scenario.
### Detection & Response
- Date/Time: Early October 2025
- Vector: Third-party security investigation (Wiz)
- Details: Wiz identified numerous extensions in both marketplaces that had exposed access tokens. The Eclipse Foundation confirmed the leak, identified the affected tokens, and initiated revocation procedures. They also addressed extensions flagged by Koi Security related to the "GlassWorm" campaign.
## Attack Methodology
The incident was characterized by accidental **Exposure** rather than active exploitation of infrastructure vulnerabilities.
- Initial Access: **Accidental Token Leak** (Developer error leading to source code exposure).
- Persistence: N/A (Focus was on revoking privileges associated with the leaked credentials).
- Privilege Escalation: N/A
- Defense Evasion: N/A
- Credential Access: **Direct Exposure** (Tokens were publicly readable in code repositories).
- Discovery: Reconnaissance by Wiz identifying exposed secrets within public extension repositories.
- Lateral Movement: Potential modification/publication rights within the extension registry.
- Collection: N/A
- Exfiltration: N/A
- Impact: Potential supply chain compromise and distribution of malicious software.
## Impact Assessment
- Financial: Not detailed, but revocation costs and potential remediation costs for compromised publishers are implied.
- Data Breach: Exposure of access tokens associated with extension publishing rights (authorization data). No specific user data breach was reported.
- Operational: Minimal direct operational disruption, but significant risk to the integrity of the Open VSX ecosystem.
- Reputational: Negative impact due to exposure of security vulnerabilities in the developer workflow.
## Indicators of Compromise
- File indicators: Tokens found within published extension source code or metadata.
- Behavioral indicators: Unauthorized extension modification attempts (if any occurred before revocation).
- Network indicators: **Defanged Prefix Implementation:** Introduction of token prefix format `ovsxp_` for easier scanning of future leaks.
## Response Actions
- Containment measures: **Revocation of the small number of confirmed leaked tokens.**
- Eradication steps: Identification and removal of extensions recently flagged by Koi Security related to the "GlassWorm" campaign.
- Recovery actions: Implementation of enhanced security measures across the registry infrastructure.
## Lessons Learned
- Supply chain security is a **shared responsibility** between token publishers (developers) and registry maintainers.
- Developer training and automated secret scanning in Continuous Integration/Continuous Delivery (CI/CD) pipelines are critical to prevent accidental token exposure.
- The ecosystem requires better mechanisms for rapid detection and automated response to exposed secrets.
## Recommendations
- **Publishers:** Implement mandatory client-side/pre-commit hooks or tooling to automatically scan code for secrets before publishing extensions.
- **Open VSX/Registries:**
1. Reduce default token lifetime limits significantly.
2. Enhance automated scanning of extensions upon publication/update to check for embedded secrets or malicious patterns.
3. Formalize and enforce the introduction of the new token prefix format (`ovsxp_`) for easier detection.
4. Streamline the process for publishers to report and receive rapid token revocation notifications.