New Webinar: Lessons for Security Leaders From Anthropic’s MCP Failure
Cursor & Windsurf

Forked and Forgotten: 94 Vulnerabilities in Cursor and Windsurf Put 1.8M Developers at Risk

image2

TL;DR

We successfully weaponized CVE-2025-7656 – a patched Chromium vulnerability – against the latest versions of Cursor and Windsurf, affecting 1.8 million developers. This is just 1 of 94+ known vulnerabilities these IDEs are exposed to due to their legacy Chromium builds. Developers are increasingly targeted for supply chain attacks, having highly sensitive company data on their devices.

The Flow

image

What We Discovered

We took a published Chromium vulnerability (CVE-2025-7656) – already patched in Chromium – and successfully exploited it against the latest releases of Cursor and Windsurf. The attack works because both IDEs are built on outdated versions of VS Code, which in turn bundle old Electron releases. Since Electron embeds Chromium and V8, this means the IDEs rely on outdated Chromium and V8 engines, exposing them to vulnerabilities that have already been patched in newer versions.

The real problem: Since their last Chromium update on 2025-03-21 for version 0.47.9 since chromium 132.0.6834.210 was out, at least 94 known CVEs have been published. We’ve weaponized just one. The attack surface is massive.

This is a classic supply chain attack waiting to happen. We’ve demonstrated exploitation of one vulnerability, but 93 more are sitting there, publicly documented, many with existing proof-of-concepts – sitting there, waiting for a threat actor to weaponize them.

Cursor and Windsurf must prioritize upstream security updates. Until they do, 1.8 million developers remain exposed to attacks that could compromise not just their machines, but the entire software supply chain they’re part of.

Developer Machines Are Supply Chain Gold

Compromising a developer’s IDE isn’t just about one person:

  • Developers have access to production systems, databases, and cloud infrastructure
  • Their machines contain source code, API keys, credentials, and trade secrets
  • A compromised IDE can inject backdoors into every project they touch
  • Malicious code from trusted developers bypasses most security controls

The Numbers

  • 1.8 million users exposed (Cursor + Windsurf combined)
  • 94+ exploitable vulnerabilities in their current Chromium builds
  • 1 vulnerability weaponized in this research (1% of the attack surface)

Technical Details: CVE-2025-7656

The Vulnerability

A flaw in V8’s Maglev JIT compiler can be triggered by creating JavaScript functions with extremely large argument lists (~40,000 arguments). This causes integer overflow in the compiler’s 32-bit register calculations during optimization.

The Exploit

// Step 1: Generate massive argument list
var num_args = 40000;
var argsList = "";
for (var i = 0; i < num_args; i++) argsList += "a" + i + ",";
argsList = argsList.slice(0, -1);

// Step 2: Create the vulnerable function
var body = "return arguments.length + 1;";
var bigArgFunc = new Function(argsList, body);

// Step 3: Trigger optimization and crash
for (var i = 0; i < 1e5; i++) bigArgFunc(0);

Repeated invocations force On-Stack Replacement (OSR) optimization, triggering the overflow and causing a crash.

What This Enables

  • Renderer crashes (denial-of-service) – demonstrated in our PoC
  • Code execution – memory corruption can be leveraged for arbitrary code execution
  • Data exfiltration – stealing source code, credentials, API keys
  • Supply chain attacks – injecting malicious code into developer projects

Proof of Concept

Our proof-of-concept begins when a victim clicks a deeplink. According to Cursor’s documentation, deeplinks “allow you to share prompts and commands with others…”. When opened, the deeplink causes Cursor to execute a prompt that directs the Simple Browser to visit a remote site hosting the payload. Because the payload is served remotely (and not embedded in the prompt), it cannot be detected by scanning the prompt itself. Moreover, there are 94+ known vulnerabilities in the underlying components that could be weaponized to achieve remote code execution – attacks that likewise would not be detectable by prompt-scanning. By exploiting an outdated Chromium version that Cursor depends on and weaponizing a Chromium vulnerability, the payload triggers a crash in the assembler during Maglev code generation – illustrating the serious consequences of relying on unpatched third-party components.


We validated this was due to outdated Chromium by confirming:

  • The exploit works on old VS Code versions with vulnerable Chromium
  • The exploit fails on current VS Code (which updates Chromium regularly)
  • The exploit succeeds on latest Cursor and Windsurf

Attack Scenarios: How could this be exploited in the wild?

  1. Malicious extensions – Packages that trigger the exploit when loaded
  2. Compromised documentation – Exploit code injected into dev docs or tutorials
  3. Poisoned repositories – Malicious code in README files rendered in IDE preview
  4. Targeted phishing – “Interesting code samples” that execute exploits when opened

What Can Be Done?

For Users

Unfortunately, nothing. This is a vendor-level problem. Users cannot patch or mitigate this risk directly.

For Cursor and Windsurf

  • Update Chromium/Electron aggressively – establish a patch SLA for critical CVEs
  • Automate security updates – don’t rely on manual update cycles
  • Treat this as critical – 94 known vulnerabilities is unacceptable

For Security Teams

  • Monitor IDE versions across your developer fleet
  • Implement network controls to limit potential data exfiltration
  • Classify this as supply chain risk – developer environment security is infrastructure security

Research Context: This concludes our three-part investigation into Chromium vulnerabilities in AI-powered IDEs. See our previous posts on Chromium vulnerability exploration and Cursor/Windsurf update lag analysis.

Responsible Disclosure: We reached out to both Windsurf and Cursor on October 12, 2025. 

Windsurf has yet to respond. 

Cursor responded: “Thank you for the report. We consider self-DOS to be out of scope.” 

Note: While our PoC demonstrates a crash (DoS), the underlying memory corruption primitive enables arbitrary code execution. Dismissing this as “self-DOS” ignores the broader security implications and the 93 other unpatched CVEs in their Chromium build.

post banner image

Run Every Security Test Your Code Needs

Pinpoint, investigate and eliminate code-level issues across the entire SDLC.

Start Free
Group 1261153044

It’s time to secure your code the way software is built

Learn how VibeSec makes security part of your product creation from code to runtime