Trojanized OpenVSX Extension Spreads GlassWorm Across VS Code, Cursor, and Windsurf

In Cybersecurity News - Original News Source is cybersecuritynews.com by Blog Writer

A fake developer extension published on the OpenVSX marketplace is silently spreading a known malware strain called GlassWorm to every code editor installed on a developer’s machine.

The malicious package disguises itself as a legitimate productivity tool and uses a compiled native binary to quietly infect VS Code, Cursor, Windsurf, and several other editors all at once.​

GlassWorm is not a new threat. It was first spotted in March 2025, hiding malicious payloads inside invisible Unicode characters embedded in npm packages.

Over the past year, the campaign grew steadily, hitting hundreds of projects on GitHub, npm, and VS Code.

Before this latest wave, its most damaging move was deploying a persistent Remote Access Trojan through a fake Chrome extension that logged keystrokes and stole session cookies from victims.​

Aikido security analysts, who have been tracking the GlassWorm campaign for over a year, identified this latest technique in April 2026.

The attack was found hidden inside an OpenVSX extension called code-wakatime-activity-tracker, published under the specstudio account.

On the surface, the extension is nearly identical to the real WakaTime productivity tool — it shows the same command options, the same API key prompts, and the same status bar icons that developers are familiar with.​

What separates this attack from earlier GlassWorm versions is the use of Zig-compiled native binaries. On Windows, the extension ships a file called win.node, a PE32+ DLL.

On macOS, it includes mac.node, a universal Mach-O binary that runs on both Intel and Apple Silicon hardware. These files load directly into Node.js’s runtime and operate with full access to the operating system, outside the reach of standard sandbox protections.​

The attack does not stop at a single editor. Once the binary runs, it scans the machine for every IDE that supports VS Code’s extension format — including VS Code, VS Code Insiders, Cursor, Windsurf, VSCodium, and Positron — and silently installs a malicious extension into each one.

A developer running Cursor with VS Code also installed would find both environments quietly compromised with no visible warning.​

How the Multi-IDE Infection Works

The infection begins the moment a developer installs code-wakatime-activity-tracker. The extension’s activate() function, which is supposed to start up the WakaTime tool, has been quietly altered by the attacker.

Before any legitimate WakaTime code gets a chance to run, the function loads either win.node or mac.node from the extension’s bundled ./bin/ directory and immediately calls install(). That single call triggers everything that follows.​

The native binary then contacts a GitHub Releases page controlled by the attacker and downloads a malicious .vsix file named autoimport-2.7.9.

This package is designed to look like steoates.autoimport, a popular VS Code extension used by millions of developers. Once downloaded, the file is silently force-installed into every IDE found on the machine using each editor’s own command-line installer.

After the installation completes, the downloaded file is deleted to remove any trace of it.​

Second-Stage Extension (Source – Aikido)

The second-stage extension is the same GlassWorm dropper that Aikido has been analyzing throughout the campaign’s history. It avoids executing on machines that use Russian system settings, pointing to a deliberate choice by its authors.

Once active, it beacons to a command-and-control server that operates through the Solana blockchain, making it more difficult for security teams to block or monitor.

The malware then quietly exfiltrates data from the infected machine and installs a persistent RAT alongside a malicious Chrome extension.​

Developers should check their IDE extension lists immediately for specstudio/code-wakatime-activity-tracker and floktokbok.autoimport.

If either appears in any installed editor, the machine should be treated as fully compromised. All credentials, API keys, and stored secrets accessible from that environment should be rotated right away.

Any code repositories connected to the affected machine should also be reviewed for signs of tampering, as the attacker had full system access during the infection window.​

Follow us on Google News, LinkedIn, and X to Get More Instant UpdatesSet CSN as a Preferred Source in Google.