When Your IDE Becomes a RCE Endpoint | by Berk ALBAYRAK | Trendyol Tech | Jun, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

Trendyol Tech

Trendyol Tech Team

When Your IDE Becomes a RCE Endpoint

Berk ALBAYRAK

21 min read·<br>1 hour ago

Listen

Share

Press enter or click to view image in full size

Trendyol CSOC and Application Security research on a live supply-chain technique abusing Cursor and other VS Code-derived editors through the OpenVSX registry.<br>TOC<br>How we found ourselves looking at this<br>Measuring the blast radius<br>How Cursor decides what to install<br>What changed in June 2025<br>Walking through an attack, step by step<br>Indicators you can track<br>Hunting for it<br>What you should do this week<br>Where this goes next

If your developers run Cursor , VSCodium , Windsurf , or any other fork of VS Code that pulls its extensions from OpenVSX , attacker controlled code is one editor launch away from executing on their machines. None of this is hypothetical, and the underlying idea is not even new. It is the same dependency confusion problem the npm world ran into in 2021, moved down a layer into the IDE’s extension system. We have spent the past month chasing it across our own developer fleet, watching OpenVSX namespace activity, and detonating samples in the lab. What follows is what we found, what we have done about it, and what we think every organisation should be doing this week.<br>TL;DR. Because Microsoft’s Marketplace and OpenVSX are separate trust roots, an attacker can register an abandoned or never claimed publisher.extension namespace on OpenVSX and have every Cursor, Windsurf, or other VS Code fork that resolves the same identifier silently install and run their code as the developer. The fixes that actually work are an organization wide extension allowlist, an auto update cooldown, and the detection logic at the end of this post.

We did not stop at the theory. Our team snapshotted both registries in full and compared all 129,000 Microsoft Marketplace extensions against the 14,194 published on OpenVSX, one identifier at a time. What came back is a map of how much of the ecosystem is already exposed:<br>104,456 Marketplace extensions have no entry on OpenVSX at all, which leaves every one of those names as a free, squat ready namespace on the registry the forks resolve against.<br>1,078 extensions resolve to a different publisher on OpenVSX than the one that legitimately owns the name on Microsoft’s Marketplace.<br>924 carry the same name but are already pulled from a different GitHub repository than the original.<br>126 are exact-ID hijacks: the identical publisher.extension exists on both registries, but the OpenVSX copy is wired to a different repository or account. This is the most dangerous band, and it includes names with millions of installs such as sumneko.lua, rust-lang.rust, and msazurermtools.azurerm-vscode-tools, where a developer typing the exact trusted identifier can still be handed code that is not the original.<br>The attack surface on OpenVSX is wider than most people assume, and the last few months have made that hard to ignore: GlassWorm , tracked by Socket’s researchers, is a cluster of extensions that go up looking harmless, sit as sleepers, then flip into malware through hijacked publisher accounts, even hiding their command-and-control in WebAssembly and Solana transaction memos. The namespace squatting we mapped is just one more door into the same building.<br>How we found ourselves looking at this<br>Our hunting team was reviewing developer telemetry as part of a routine sweep when we noticed something unusual in the process tree under Cursor. Cursor populates two environment variables on every process descended from an extension activation:<br>CURSOR_SPAWNED_BY_EXTENSION_ID=.<br>CURSOR_SPAWN_CHAIN=.Those variables turned out to be the cleanest anchor we have ever had for “find me everything an extension did”. Once we built that pivot, we saw classic recon and exfil verbs: whoami, hostname, id, environment dumps, git remote enumeration, and HTTPS POSTs to webhook listeners, all spawning from Cursor Helper (Plugin) , all attributable to a specific publisher.extension we did not recognise.<br>We pulled the VSIX off the mirror, opened it in a contained environment, and watched it do exactly what the telemetry implied. Then we mapped the publisher namespace back to public repositories that referenced it, and back to its registration history on OpenVSX . The pattern was unambiguous. The identifier had been referenced in third-party templates and devcontainers for years, the original publisher account had lapsed, and somebody had registered a fresh account under the same name and shipped a new high-version VSIX. Every Cursor instance that resolved that identifier got the new payload.<br>To be explicit: nothing in our environment was compromised. The detonations happened in instrumented research workstations under Application Security control, and the namespace...