- Security teams uncovered 12 malicious VSCode extensions; four remain available and risky.
- Threats range from code exfiltration and credential theft to reverse shells and persistent RCE.
- Open VSX saw a RAT dubbed SleepyDuck using Ethereum contracts for resilient C2.
- Research suggests 5.6% of 52,880 extensions show suspicious behavior, totaling 613M installs.

Developers are increasingly facing extension-borne risks inside the editor they use every day, and Visual Studio Code (VSCode) is at the center of the latest alarms. Investigations have tied a cluster of marketplace listings to aggressive data collection, credential theft, and even covert remote access on machines used for software projects.
What makes the situation more delicate is that several packages remain downloadable as of the latest reports, which means the problem isn’t theoretical. The activity spans the official marketplace and Open VSX, highlighting how IDE extension ecosystems have become a high-value target for supply chain attacks.
What researchers found in the VS Code ecosystems

Multiple teams, including HelixGuard and other security researchers, documented at least a dozen malicious uploads on the Microsoft VSCode Marketplace and Open VSX. Crucially, four of them are reportedly still live: Christine-devops1234.scraper, Kodease.fyp-23-s2-08, GuyNachshon.cxcx123, and sahil92552.CBE-456.
These packages reach far beyond harmless telemetry. Analysts observed theft of machine identifiers, project names, full source files, search history inside the editor, AI chat prompts, selected code fragments, clipboard contents, and even screenshots captured during daily work.
One frequently cited data point frames the wider risk: an academic look at the ecosystem estimated that about 5.6% of 52,880 examined VSCode extensions exhibit suspicious behavior patterns — and those potentially risky entries collectively account for more than 613 million installs.
How the exfiltration actually happens
The behaviors vary by package, but the goal is consistent: get sensitive data out without tipping off the user. For instance, analysts say Christine-devops1234.scraper funnels a broad set of user and project details — including entire file contents and in-IDE queries — to attacker infrastructure at 35.164.75.62:8080.
Meanwhile, Kodease.fyp-23-s2-08 routes stolen snippets via Ngrok, disguising exfiltration as a feature for AI-style comment generation. The code examined normalizes content (e.g., stripping whitespace) and sends it in HTTPS POST requests so the traffic blends in as a legitimate assistive function.
Beyond code theft, surveillance-style plugins are in the mix. A plugin identified as BX-Dev.Blackstone-DLP was seen capturing screenshots and monitoring the clipboard, a combination that can quietly siphon credentials, tokens, and sensitive fragments of proprietary logic.
Researchers also flagged an extension named VKTeam.ru that selectively targets corporate contexts. It checks for VK.com domain membership and, when conditions match, harvests Windows domain data such as usernames, hostnames, and system details — a tailored environment reconnaissance step.
From spying to full machine compromise
Several entries aim far past data collection and move into command execution. The package teste123444212.teste123444212 reportedly maintains a persistent connection to attacker-controlled AWS resources, effectively providing a channel for remote command execution on the developer’s host.
Another example, ToToRoManComp.diff-tool-vsc, deploys a Base64-encoded Perl reverse shell that reaches out to 89.104.69.35 on port 445, handing over interactive access once it connects. That sort of payload grants an adversary comprehensive control beyond the editor itself.
The malicious activity tied to Deriv-AI.deriv-ai escalates further by fetching and launching a trojan dubbed “nightpaw,” enabling deeper reconnaissance and durable remote access on compromised systems.
Open VSX case: SleepyDuck hides behind a Solidity tool
On the community-driven Open VSX registry, investigators tracked a remote access trojan nicknamed SleepyDuck masquerading as a Solidity extension named juan-bianco.solidity-vlang. It drew more than 53,000 downloads and remained visible with a platform warning; critically, it started out benign upon submission and gained its malicious component in a subsequent update.
SleepyDuck’s standout trick is resilience: it leverages an Ethereum smart contract to store and update its command-and-control details. If the default C2 at sleepyduckxyz disappears, the malware can query the blockchain for fresh instructions, including a new server address and revised polling intervals.
Activation paths are tuned for developer workflows. The extension kicks in at editor startup, on opening a Solidity file, or when the Solidity compile command is invoked. It drops a lock file to ensure it runs once per host and calls a sham webpack.init() from its extension script to blend in, then loads the malicious payload.
Upon initialization, analysts observed the malware collecting basic system identifiers (host/user names, MAC, and timezone) and preparing a sandbox for command execution. It locates a fast Ethereum RPC endpoint, reads the smart contract for current config, and enters a polling loop that posts host data and checks for tasks to execute.
A separate incident targeting Solidity developers
Earlier in the year, researchers also reported a distinct fake package branded as a “Solidity Language” helper on Open VSX. That one allegedly ran a PowerShell script, dropped a remote access tool, and siphoned crypto-wallet passphrases; one developer publicly claimed losses of roughly US $500,000. The listing amassed tens of thousands of downloads before removal and reportedly reappeared under new names soon after.
The repeated targeting of smart-contract developers is not accidental. These users often hold wallet access and interact with financial infrastructure, making them high-value targets for attackers looking to monetize quickly.
The bigger picture: scale and incentives
The numbers paint a sobering picture: research suggests that around 5.6% of 52,880 reviewed extensions show signs of policy violations or risky traits — and the aggregate installations for such entries exceed 613 million. With VSCode’s huge footprint and the rise of AI-assisted tooling, threat actors are incentivized to hide inside the add-ons developers already trust.
Another factor is privilege. Extensions operate with the same capabilities as the editor — reading files, spawning processes, and making network calls — which expands the blast radius. By hiding exfiltration within features like code suggestions or comment generation, attackers make malicious traffic look like normal development activity.
What teams should do right now
Security leaders and individual developers can reduce exposure with a few disciplined steps, prioritizing visibility and strong defaults that curb risky installs while keeping productivity intact. A practical mix of governance and monitoring makes the biggest difference.
- Audit installed extensions on a schedule; remove anything unknown, newly created, or low-reputation. Consider an allowlist for approved plugins.
- Monitor egress from developer endpoints for unusual destinations (e.g., known C2 IPs, unexpected tunnels such as Ngrok).
- Review extension source when possible, especially those touching secrets or sensitive code paths; pin versions if you must use them.
- Be cautious with auto-updates; track changelogs and publisher changes to avoid surprise supply-chain pivots.
- Harden endpoints with EDR/AV, local firewalls, and least privilege; isolate build secrets and use token-scoped credentials.
- Train developers on extension risks, publisher verification, and quick reporting/escalation of suspicious editor behavior.
Marketplace responses and ongoing improvements
Open VSX, increasingly popular with AI-enabled IDEs like Cursor and Windsurf, has announced security upgrades: shorter token lifetimes, faster revocation of leaked credentials, more automated scanning, and improved information sharing with the VS Code team on emerging threats.
Even with those steps, ecosystem safety is a moving target. Attackers iterate quickly; they rebrand packages, push harmful updates to previously harmless projects, and camouflage traffic under the guise of developer conveniences. Community vigilance and rapid takedowns remain essential.
Across both marketplaces, recent cases show how exfiltration can be made to look like legitimate features and how backdoors can persist through clever use of blockchain-based C2, reverse shells, and cloud relays. Treat every extension as code in your supply chain, and validate it with the same rigor you apply to dependencies.
These findings point to a simple but non-negotiable posture: treat the editor as part of your security boundary. With several malicious VSCode extensions still accessible, reports of Ethereum-backed C2 in the wild, and evidence that a measurable slice of the ecosystem may be risky, teams that implement audits, allowlists, network monitoring, and developer education will be best positioned to keep source code and credentials out of an attacker’s hands.
