VS Code Is Being Used in Active Cyberattacks

This one is uncomfortable precisely because it’s so ordinary. Visual Studio Code, one of the most trusted developer tools on the planet, is now showing up in active cyberattacks. Not because VS Code is broken. Not because Microsoft shipped something reckless. But because attackers are getting smarter about blending in.

Security teams have been documenting incidents where VS Code is used as part of post-compromise activity. Once attackers are already inside a system, they’re leaning on tools that look normal, behave normally, and raise fewer eyebrows. VS Code fits that bill a little too well.

What’s Actually Happening

In these cases, VS Code isn’t the entry point. The break-in usually happens elsewhere: stolen credentials, exposed services, misconfigured cloud resources, the usual suspects. Once access is established, attackers deploy VS Code or use existing installations to run extensions, manage files, execute scripts, and quietly move around the environment.

From a defender’s point of view, this is tricky. VS Code launches all the time in real environments. Developers use it. Data teams use it. Ops teams use it. Seeing it run doesn’t automatically trigger alarms the way an unknown binary would.

Why VS Code Specifically

VS Code sits in a sweet spot for attackers. It’s powerful, script-friendly, extensible, and already trusted by default on many machines. Extensions can execute code. Integrated terminals can run commands. Remote development features can interact with servers and containers. None of this is a vulnerability by itself. It’s just a very capable tool.

This is part of a broader shift. Attackers increasingly prefer living-off-the-land techniques, where they use tools that are already present instead of dropping obvious malware. VS Code joins a long list that includes PowerShell, remote admin tools, and legitimate system utilities.

A Bit of Context

A decade ago, attacks often stood out because they introduced foreign software. Today, that’s less common. Modern environments are full of powerful tools by design. The security challenge has moved from blocking unknown software to understanding how known software is being used.

Developer tools becoming part of attack chains isn’t new, but it’s becoming more visible as organizations expand remote work, cloud development, and shared environments. VS Code just happens to be everywhere.

What This Means for Organizations

This isn’t a call to ban VS Code or panic about developer tooling. It’s a reminder that trust should be contextual. When a tool is powerful enough to build production systems, it’s powerful enough to be misused after a breach.

• Monitor how developer tools are used, not just whether they’re installed.
• Pay attention to unusual extension installs or unexpected remote connections.
• Separate development environments from sensitive production systems where possible.
• Treat developer machines as high-value assets, not casual endpoints.
• Assume legitimate tools can be part of an attack chain once access is gained.

The takeaway is subtle but important: the line between “safe software” and “risky behavior” is thinner than it used to be. VS Code isn’t the problem. The environment it runs in, and what it’s allowed to touch, is where the real decisions live.