Open VSX token rotation after GlassWorm: an IR playbook for hunting malicious VS Code–compatible extensions
On November 2, 2025, Open VSX said it rotated leaked access tokens after attackers abused exposed secrets to publish malicious VS Code-compatible extensions in a supply-chain incident tied to the “GlassWorm” campaign. The Eclipse Foundation removed the malicious packages, and reported the incident contained by October 21 with additional controls coming (shorter token lifetimes, faster revocation workflows, and automated scans) source source.
Intrusion Flow
- Initial access to publishers: Researchers cataloged over 550 validated secrets inside VS Code and Open VSX extensions, including more than 100 VS Code Marketplace PATs and 30+ Open VSX tokens-enough to let an attacker push trojanized updates to projects with an install base around 150k in aggregate source source.
- Weaponization and publish: Some leaked Open VSX tokens were subsequently abused to publish malicious extensions associated with the GlassWorm campaign source.
- Payload concealment: Koi Security reported the use of invisible Unicode characters to hide JavaScript payloads (Unicode steganography) in extension code, hindering human review; claims included credential theft and targeting of crypto-wallet data in dozens of extensions source source. The Eclipse Foundation clarified GlassWorm did steal developer credentials but was not self-replicating as a worm on endpoints source.
- Distribution surface: Open VSX is the Eclipse-run registry for VS Code-compatible extensions and is widely used by VS Code forks that can’t use Microsoft’s Marketplace (for example Cursor and Windsurf), increasing reach beyond Microsoft’s VS Code desktop source source.
- Amplification factors: VS Code auto-updates extensions by default; a compromised publisher token can silently fan out malicious updates to enrolled developer machines source source.
Key Artifacts to Pull
- Extension inventory and binaries
- Enumerate installed extensions and lock versions:
- File system paths for extensions:
- Collect extension directories, their
package.json, and any.vsixpackages found on disk (portable mode keeps all data under the appdatafolder) source.
- VS Code state and logs
- Global state DB:
%APPDATA%\Code\User\globalStorage\state.vscdb(or~/.config/Code/User/globalStorage/state.vscdb) contains extension enable/disable state; also check workspaceworkspaceStorage/*/state.vscdbsource. - Export extension logs via Developer: Open Extension Logs Folder (also exposed by GitHub Codespaces docs) source.
- Global state DB:
- Indicators specific to GlassWorm
- Review Koi’s rolling IoCs for compromised extension IDs/versions and infrastructure (IPs, Solana wallet, Google Calendar dead-drops) to guide triage source.
Detection Notes
- Hunt for invisible Unicode control/steganography markers in extensions and project code
- Background: Unicode bidi controls and zero-width/variation selectors can render code differently than it executes (the “Trojan Source” class of issues) source source.
- Practical scans (target extension folders and recent repos):
- Detect bidi controls (U+061C; U+200E-U+200F; U+202A-U+202E; U+2066-U+2069) with PCRE2/Perl one-liners as documented by the community:
- Detect zero-width and variation selectors often used for invisibility/steganography (e.g., U+200B-U+200D; U+FE00-U+FE0F):
- Focus on files executed on activation (e.g.,
extension.js,out/*.js,dist/*.js) andpackage.jsonactivation events.
- Look for outbound C2 patterns noted in public write-ups (Solana transaction lookups, Google Calendar shortlinks) and the specific HTTP hosts and paths in Koi’s IoCs source.
- Prioritize forks using Open VSX (e.g., Cursor and Windsurf) since their marketplaces are independent of Microsoft’s and were in GlassWorm’s blast radius; Cursor publicly documented its transition to Open VSX source source.
Response Guidance
- Containment on developer endpoints
- Freeze extension churn: set
"extensions.autoUpdate": falsetemporarily while you investigate source. - Snapshot and remove: export
code --list-extensions --show-versions, then uninstall suspicious or listed IoC extensions; optionally pin safe versions via--install-extension publisher.ext@versionsource. - Inspect and neutralize Unicode-hidden payloads: if scans hit invisible characters in executable code, treat the extension as compromised; preserve copies, then disable/uninstall.
- Freeze extension churn: set
- Credential hygiene
- Rotate developer credentials targeted by reports (GitHub PATs, npm tokens, Open VSX access tokens) and invalidate saved tokens on endpoints. Open VSX documents token management and revocation in its publishing guide; tokens remain valid until deleted-revoke any that could be exposed in CI or builds source source.
- Enterprise marketplace governance
- Prefer allow-lists of publishers and pre-approved extensions for Open VSX-backed IDEs (Cursor/Windsurf). Where possible, pre-stage vetted
.vsixand install via CLI to reduce live marketplace risk source. - Monitor Open VSX and vendor advisories; Eclipse’s post-incident measures include shorter token lifetimes, faster revocations, and automated publication-time scans-incorporate those changes into your risk model source.
- Prefer allow-lists of publishers and pre-approved extensions for Open VSX-backed IDEs (Cursor/Windsurf). Where possible, pre-stage vetted
- Scope verification
Takeaways
- Inventory and lock VS Code-compatible extensions now; disable auto-updates during triage and remove any listed by IoCs source source.
- Hunt for Unicode control characters in extension code and recent repos; treat any invisible-character hits in executable files as suspicious until proven benign source source.
- Rotate exposed tokens across Open VSX, GitHub, and npm; re-issue per-environment tokens and revoke unused ones source.
- Track Open VSX advisories and Koi/Aikido updates; BleepingComputer confirms Eclipse removed the packages, rotated tokens, and is tightening controls, while Aikido reports the threat activity pivoting to GitHub with the same Unicode technique source source.