Skip to main content

Command Palette

Search for a command to run...

Malicious IDE Extensions: How Attackers Are Weaponizing Developer Marketplaces

Attackers are weaponizing developer marketplaces with malicious IDE extensions. Learn how to identify compromised plugins and protect your development

Updated
•9 min read•View as Markdown
Malicious IDE Extensions: How Attackers Are Weaponizing Developer Marketplaces

While scanning my daily security feeds this morning, I noticed something troubling: another developer lost half a million dollars to a malicious IDE extension. Not from a zero-day exploit or sophisticated APT, but from installing what looked like a legitimate productivity tool from a trusted developer marketplace.

This isn't an isolated incident. I've seen a pattern across VS Code, Cursor AI, and Firefox that should concern every security team: attackers are systematically weaponizing developer marketplaces by uploading malicious extensions that compromise development environments. And they're getting better at it.

The Problem We're Not Talking About

Here's what keeps me up at night: we've spent years hardening our supply chains around npm packages and Docker images, but we've overlooked the productivity tools developers install every single day. Browser extensions. IDE plugins. Code formatters. These "helpful" add-ons sit at the intersection of code, credentials, and cryptocurrency wallets, making them perfect targets for financially motivated threat actors.

The attack surface is massive. Developers routinely install extensions from marketplaces to boost productivity, often without the same scrutiny they'd apply to production dependencies. And why wouldn't they? These tools come from "trusted" developer marketplaces run by Microsoft, Mozilla, and other major platforms.

That trust is being weaponized.

What Datadog Uncovered: Malicious Extensions Targeting Blockchain Developers

In May 2025, Datadog Security Labs discovered three malicious IDE extensions in the VS Code marketplace targeting blockchain developers: solaibot, among-eth, and blankebesxstnion. The targeting was deliberate. Solidity is the programming language for Ethereum smart contracts, meaning these developers have direct access to valuable cryptocurrency assets.

The technical execution showed sophistication I've come to expect from financially motivated actors. The malicious extensions ran obfuscated code, fetched multi-stage payloads via PowerShell, and ultimately dropped both a browser extension and Windows binaries designed to siphon credentials, with particular focus on crypto wallet data.

Microsoft removed them quickly. Total installs stayed under 50 before takedown. But here's what matters: the attackers weren't going for volume. They were hunting whales, developers with access to high-value blockchain assets.

This is the new threat model. Low-volume, high-impact attacks targeting technical users who control valuable infrastructure.

The Half-Million-Dollar Wake-Up Call

Between June and July 2025, Kaspersky documented a case that should alarm every CISO: a developer lost approximately $500,000 in cryptocurrency after installing what appeared to be a legitimate "Solidity Language" extension from the Cursor AI marketplace.

The malicious extension was a masterclass in persistence. It downloaded PowerShell scripts from attacker-controlled servers, installed ScreenConnect remote-access software, then deployed Quasar RAT alongside a custom data stealer. This toolkit systematically exfiltrated browser passwords, email credentials, and crypto wallet keys.

But what happened next reveals how sophisticated these marketplace attacks have become.

After the first fake extension was removed on July 2, the attackers uploaded a nearly identical copy using a look-alike publisher name: "juanbIanco" instead of the legitimate "juanblanco." Notice the difference? Capital "I" versus lowercase "l." In most fonts, they're visually identical.

This counterfeit version briefly outranked the real plugin in Cursor's search results because the marketplace algorithm favoured recently updated packages. The displayed "~2 million downloads" was likely manipulated to create false trust signals.

In my experience working with security teams, this kind of algorithm gaming combined with typosquatting represents an evolution in attack sophistication that most organisations aren't prepared to defend against when dealing with developer marketplaces.

GreedyBear: Weaponizing Browser Extensions at Industrial Scale

In August 2025, Koi Security unveiled a campaign code-named GreedyBear that demonstrated how attackers weaponize browser extension marketplaces at scale. Threat actors published over 150 malicious extensions to Firefox's marketplace, including convincing mimics of MetaMask, Exodus, and TronLink cryptocurrency wallets.

The technique, called "Extension Hollowing," should be in every threat model now:

  1. Upload safe, functional utilities to pass Mozilla's marketplace review

  2. Build trust through positive reviews and clean behaviour

  3. Push malicious updates that replace code while retaining reputation

  4. Harvest credentials before detection

The campaign drained over $1 million before Mozilla's mass removal. The scale suggests either highly organised actors or multiple groups sharing tactics and infrastructure for weaponizing extension marketplaces.

How Attackers Weaponize Developer Marketplaces

After two decades in cybersecurity, I can tell you this isn't a new threat category. Supply chain compromises through plugins and open-source packages have existed for years. What's different now is how attackers are systematically weaponizing the trust mechanisms built into developer marketplaces.

First, the convergence. Multiple marketplaces showing similar vulnerabilities. Same tactics across different platforms. This suggests either knowledge-sharing among threat actors or independent discovery of the same effective techniques for compromising marketplace trust.

Second, the precision targeting. These aren't broad, noisy attacks. They're surgical strikes against developers with access to valuable code repositories, production infrastructure, and financial assets.

Third, the adaptive behaviour. Kaspersky's analysis found that the malicious Cursor plugin's scripts closely matched earlier VS Code attacks from April-May 2025. Datadog observed attackers updating payloads after discovery. This is active, iterative operation by sophisticated actors who monitor security research and adjust their marketplace exploitation tactics accordingly.

The Attack Patterns Behind Malicious IDE Extensions

Let me break down the common patterns I'm seeing in these marketplace attacks:

The Benign-Then-Malicious Switcheroo

Both GreedyBear and the malicious IDE extension campaigns follow the same playbook for weaponizing developer marketplaces:

Attackers first uploaded safe utilities to build trust and positive reviews, then “hollowed out” these extensions (Extension Hollowing) replacing their code and assets with credential-stealing logic while retaining their good reputation

This exploits the gap between initial marketplace security review and ongoing monitoring. Even Mozilla's new risk-profiling system introduced in June 2025 struggles with this timing attack against their browser extension marketplace.

Typosquatting in Developer Marketplaces

The Cursor incident showed how attackers exploit marketplace discovery mechanisms. The fake "juanbIanco" publisher combined classic typosquatting with algorithmic manipulation. Recency-weighted search rankings pushed the malicious extension above the legitimate one in the marketplace search results.

Organisations might assume marketplace search results are trustworthy. They're not. Attackers understand these algorithms better than we do, and they're weaponizing that knowledge.

Network Behaviour of Malicious Extensions

In the VS Code malicious extensions, the code reached out to solidity[.]bot/version.json to trigger Windows-only PowerShell scripts. These pulled hidden payloads from unexpected locations, including image files on Internet Archive, and dropped executables like myau.exe and myaunet.exe.

In the Cursor marketplace attack, the malicious plugin fetched scripts from angelic[.]su and paste[.]ee, installed ScreenConnect from lmfao[.]su, and connected to 144.172.112[.]84 and relay.lmfao[.]su.

The use of paste services and suspicious domains should trigger immediate investigation in any mature security program monitoring developer tools and IDE extensions.

The Defenses That Are Actually Working Against Marketplace Attacks

Let me be clear: this cat-and-mouse game continues, but some defenses show real promise against malicious IDE extensions and weaponized marketplaces.

Microsoft's VS Code marketplace pulled the malicious extensions quickly. Their automated scanning works, but determined adversaries slip through with obfuscation and staged payloads.

Cursor AI made significant changes after responsible disclosure on July 16. Cursor v1.3 changed its trust model: any change to an approved MCP (Model Context Protocol) configuration now requires re-approval. This cuts off the "benign-then-swap" abuse route that attackers use to weaponize developer marketplaces, addressing CVE-2025-54136 ("MCPoison").

Mozilla introduced automated risk-profiling for wallet extensions in their marketplace in June 2025, creating a front-door tripwire before extensions gain traction. It's not perfect, but it's a step toward continuous validation of extension behaviour in browser marketplaces.

Red Flags: Identifying Malicious IDE Extensions

Based on what I'm seeing in the field, here are the practical indicators that should trigger investigation when dealing with developer marketplaces:

Look-Alike Publisher Names in Marketplaces

Don't rely on display names alone when browsing IDE extensions. That capital "I" versus lowercase "l" trick works because of font rendering. Always verify publishers are officially verified by the marketplace or cross-reference with known-good sources.

Suspicious Marketplace Search Results

If the top extension result is unverified, brand new, or updated yesterday, be skeptical. Malicious IDE extensions artificially padded with fake download counts can temporarily outrank trusted extensions in marketplace algorithms.

Extensions Requesting New Permissions After Updates

Monitor for extensions that pass marketplace review with minimal permissions, then request invasive access through updates. This is the "Extension Hollowing" pattern attackers use to weaponize previously-benign tools.

Network Connections from IDE Extensions

Any extension reaching out to paste services, newly registered domains, or suspicious IPs should trigger immediate review. Legitimate IDE extensions use stable, well-known APIs, not temporary hosting services.

What You Can Do Today to Protect Against Malicious Marketplaces

Here's my practical advice for security teams dealing with developer marketplace risks:

Implement extension approval workflows. Don't let developers install arbitrary IDE extensions from marketplaces, especially in environments with access to production systems or sensitive credentials.

Monitor extension updates continuously. The "good today, bad tomorrow" pattern means you need continuous validation of marketplace-installed tools, not point-in-time approval.

Use verified publishers only. Make this a hard requirement when installing from developer marketplaces. Unverified publishers with recently created accounts and suspicious update patterns should be blocked by default.

Deploy endpoint detection for IDE extension behaviour. Network connections to suspicious domains, unexpected PowerShell execution, and credential access patterns from installed extensions should all trigger alerts.

Educate developers on marketplace threats. That awareness training everyone ignores? Make it specific to malicious IDE extensions and weaponized browser marketplaces. Show real examples like "juanbIanco" versus "juanblanco."

The Uncomfortable Truth About Developer Marketplaces

After working with hundreds of security teams, I can tell you most organisations have blind spots around developer marketplace security. We've invested heavily in scanning production dependencies, but we've ignored the tools developers use to write those dependencies.

The incentives for attackers to weaponize marketplaces are too strong and the path is too repeatable: typosquat a trusted tool, ship benign code to pass checks, flip the switch later with malicious updates. Even with improved marketplace defenses, this remains an attractive attack vector.

According to Datadog's research, operators changed payloads after exposure, showing adaptive, professional operations. We should expect more surgical, financially motivated campaigns targeting developer marketplaces and IDE extensions used by high-value technical users.

Moving Forward: Securing Developer Marketplaces

The supply chain isn't just npm packages and Docker images anymore. It's every productivity tool, every helpful extension, every "makes your life easier" add-on that developers install from marketplaces without thinking twice.

When attackers weaponize developer marketplaces, turning trusted sources into distribution channels for malicious IDE extensions, the only defence is skepticism, verification, and continuous validation. The same principles we apply to production code need to extend to the tools we use to write that code.

How confident are you that your developers' IDE extensions from trusted marketplaces would pass security scrutiny? Because I guarantee attackers are counting on you not checking.


Key Takeaways

  • Validate before installing: Treat IDE extensions and browser add-ons from marketplaces with the same scrutiny as production dependencies

  • Monitor continuously: The "benign-then-malicious" pattern means point-in-time marketplace approval isn't enough

  • Verify publishers: Use only officially verified publishers in developer marketplaces and cross-reference against known-good sources

  • Watch for red flags: Look-alike names, suspicious marketplace rankings, new permission requests, and unexpected network behaviour should all trigger investigation

  • Implement controls: Extension approval workflows, endpoint monitoring for malicious IDE extensions, and developer education are your practical defenses


Sources & Further Reading