AI Coding Tools Are Opening the Door to Malware and Data Exfiltration

Open-source marketplaces for coding extensions like “Open VSX Registry,” more commonly known as the “Extensions Marketplace,” are hotbeds for malware. The marketplace has hosted everything from data exfiltrators to crypto-stealing extensions.

While malware in third-party marketplaces isn’t new, malware in developer-focused marketplaces is especially risky because it typically operates with escalated privileges on the developer’s machine. Such malware can also pose a significant supply-chain risk.

To understand the risks posed by these third-party extension marketplaces, we need to dive into the difference between AI-native development tools and the more popular Visual Studio Code.

VS Code, AI-native tools, and third-party marketplaces

Visual Studio Code, more commonly referred to as VS Code, is the world’s most widely used Integrated Development Environment, or IDE.

An IDE is a tool developers use that integrates all necessary development tools into one, from a code editor to a compiler. VS Code supports all major languages and works on all major operating systems. Even after AI-native IDEs like Cursor came out, VS Code remains the most widely used IDE by far, used by over 75% of developers.

VS Code’s popularity is largely due to two factors:

1. It’s lightweight.
2. It’s massively extensible.

The lightweight nature means devs don’t need to deal with bloat for tools and languages they don’t use. Extensibility means you can have an IDE for whatever language you code in by simply installing a few extensions.

VS Code is also open source, allowing anyone to fork it and create their own version of VS Code. That’s what Cursor did. Windsurf, another AI-native IDE, did the same.

Despite all these tools being open-source, only VS Code uses Microsoft’s proprietary Visual Studio Marketplace.

Not to say that a proprietary marketplace is necessarily “better” than an open-source one, but the Open VSX Registry lacks certain checks that have historically made it more vulnerable to hosting malware. Microsoft’s multi-layered defenses are also more mature than the Open VSX Registry’s.

As a result, the registry has been home to its fair share of malicious extensions, including one that assisted in a $500-million crypto heist, and dozens of “evil twin” extensions that performed mass-scale organization reconnaissance within seconds of being installed.

While VS Code remains the most popular IDE on the market, Cursor and Windsurf combined have over 20% market share. Neither of these IDEs can access the official VS Code marketplace, meaning that organizations using them open themselves up to malicious extensions.

The $500,000 crypto heist

In 2021, a malicious extension targeting the Solidity coding language, the most popular language for crypto-related programming, made its way into the Open VSX Registry. After developers installed it, the extension immediately executed a PowerShell script designed to exfiltrate crypto.

Developers downloaded it more than 50,000 times before the Open VSX Registry finally removed it, but not before the extension swindled one developer out of $500,000 in cryptocurrency assets.

VS Code didn’t hesitate to brag that the same extension didn’t last “two seconds” on the Visual Studio Marketplace. In all fairness, they deserved to flex a little.

The “evil twin” reconnaissance extensions

More recently, 77 extensions impersonating real developer tools made it onto the Open VSX Registry, apparently with the intent of performing organizational reconnaissance. None of the extensions stole any credentials, which suggests that their use is part of a larger-scale plan for targeted attacks later on.

A security company discovered the malicious extensions between July 26 and August 1, 2026, according to BleepingComputer. All the extensions used names and descriptions that matched real VS Code extensions but provided none of the functionality of those extensions. Instead, each extension’s “extensions.js” file—the main file providing functionality in a marketplace extension—contained only code to perform the data exfiltration.

The extensions impersonated Azure, Salesforce, IOTA (a blockchain infra provider), LEGO Education, and “a U.S. government agency namespace.”

The extensions all communicated with the same shared server, providing info about the developer machine, email, Git remote hosts, and cloud development environments. They extracted this information within seconds of installation.

Even though the Open VSX Registry removed the extensions, developers would still need to manually remove them to be safe.

Extensions have the same privileges as the IDE

VS Code’s official documentation states that the extension runtime environment operates using the same privileges as VS Code itself. The same is true of forks, such as Windsurf and Cursor.

As a tool for software development, IDEs typically run with administrator privileges.

While Cursor did introduce some sandboxing features for agents, extensions still use the high-privilege model that VS Code uses.

Open-source marketplaces have a history with malware

Open-source marketplaces have historically contained far more malware and malicious software than official ones.

For example, a paper by USENIX, a non-profit organization for advancing computing, found that third-party Android marketplaces contain around ten times more malware than the official Play Store.

Third-party marketplaces for iOS apps, accessible only through jailbroken iPhones, have historically hosted several malware families. Cydia, a popular third-party marketplace for jailbroken iPhones, reportedly hosted spying tools, attack frameworks, and adware.

The problem isn’t limited to third-party tools, but to any marketplace that doesn’t police its extensions as rigorously as users expect. For example, the Chrome Web Store has repeatedly been caught out for allowing malware to live in the marketplace for months before detection. Extensions themselves can further download malware undetected.

While all of these issues are challenging for security professionals, they’re especially risky when dealing with IDEs because of their escalated privileges. AI agents only compound the problem.

AI agents running wild on an operating system.

In addition to third-party extensions, seemingly benign coding agents have repeatedly gone rogue, resulting in everything from deleted databases to exfiltrated data.

Stating that the agent “goes rogue” is somewhat inaccurate. AI agents don’t think. They operate within the parameters that their sandboxed (or not-sandboxed) environment allows them to. And therein lies the most significant problem: AI development agents are typically given carte blanche on a system, bypassing every security best practice developed in the last three decades.

Recently, when Anthropic’s models supposedly hacked three organizations, and when OpenAI’s models allegedly hacked HuggingFace, the consensus among security professionals was that this was a sandbox failure, not an achievement of some new level of agent autonomy. Operating within the proper constraints, those agents would never have been able to execute the code they did.

Unfortunately, sandboxing an IDE leads to frustration for developers, and therein lies the major conundrum: Using AI development tools immediately opens the door to potential exfiltration because of the escalated privileges expected in these tools.

For example, developers had a rude awakening when they discovered that Grok’s new CLI tool was secretly uploading entire repositories, including secrets, to a remote server. While xAI has committed to destroying all uploaded data and verifying the destruction through an independent third party, the incident serves as a wake-up call for what’s possible when you allow an AI agent through the front door.

The biggest problem with AI agents in any form is that they’re either not sandboxed or not sufficiently sandboxed. After installing them on a machine, they have access to the entire computer system, performing actions without user interaction. Before you know it, they’ve hacked your gym to get you a spot at the next pilates class.

The security professional conundrum, and how to solve it

From an organizational perspective, one part of this problem is easily solved: Security professionals should prevent AI-coding IDEs that use third-party marketplaces until better safeguards are in place. This doesn’t mean developers can’t use AI coding tools. It means they should use CLI-based tools instead of IDEs, and stick with an IDE that uses more secure marketplaces—at least for now. 

As for the second part of the problem, the AI agents themselves, this requires more forethought. Minimally, any endpoints using agents in an organization need to be relatively locked down, with no access to live environments. This is cumbersome to set up but not impossible. The risk that these agents go rogue and exfiltrate massive quantities of data is too real to ignore.

The other crucial point is the need to avoid complacency more than ever about your organization’s security posture. AI agents aren’t some “new intelligence” we can’t fight. They’re merely a highly sophisticated tool that fails when faced with already-existing security best practices. The difference is the speed with which they operate, which puts many organizations under pressure to invest heavily to close any gaps.

That’s where a managed security service provider (MSSP) such as SolCyber comes in. We offer continuous, 24/7 monitoring and response for endpoints and identity systems, and visibility across devices and user activity, at a fraction of the cost of doing it all in-house. Instead of taking over your security team, we augment it.

To learn more about SolCyber’s services that help protect your organization from AI-driven attacks, reach out to us for a no-obligation chat.

Photo by Daniil Komov on Unsplash