Emerging security research reveals that the AI-powered development tools Cursor and Windsurf are built on outdated versions of the Chromium browser engine — leaving them exposed to at least 94 known and patched vulnerabilities, including critical sandbox escapes and remote code-execution flaws. According to a detailed analysis by cybersecurity firm Ox Security, both editors ship with Electron runtimes that incorporate legacy Chromium and V8 engine versions far behind current releases. One proof-of‐concept attack showed that a deep link could trigger the flaw CVE-2025-7656 and crash the IDE, while further modifications could escalate into full code execution. The user base for these tools is estimated at around 1.8 million developers, many of whom run unpatched versions and so face significant risks in their development environments. The vendors responded either by dismissing the issue as “out of scope” or not responding at all, despite notifications dating back to early October. Meanwhile, separate disclosures identified more issues: one research blog found that Cursor runs with Workspace Trust disabled by default, enabling malicious tasks in a cloned repository to auto-execute; yet another exposed two vulnerabilities in Cursor (CVE-2025-54135 and CVE-2025-54136) related to its Model Context Protocol servers allowing arbitrary code execution, though patches have been issued. Developers relying on these tools are being cautioned to update, apply mitigation steps, and treat their IDEs as part of the threat surface.
Sources: Bleeping Computer, Hacker News
Key Takeaways
– The foundational risk: by using outdated Chromium/V8 engines in forks of VS Code (Cursor and Windsurf), developers are exposed to a wide range of almost‐100 known vulnerabilities—most of which have been fixed upstream but not applied downstream.
– The entry vectors are real and varied: from malicious repository files auto-executing tasks when folders are opened (due to disabled Workspace Trust) to deep-links crashing/rendering the IDE to full arbitrary code execution via Model Context Protocol servers.
– Developers and teams must treat their IDEs like any other endpoint: update immediately, audit extensions/repositories, enable security configurations, and recognise that “AI editors” are not magically secure — they may increase the attack surface if maintained poorly.
In-Depth
In the rush to integrate artificial-intelligence features into development workflows, productivity sometimes trumps security—and the vulnerabilities discovered in tools like Cursor and Windsurf bear this out glaringly. These AI-powered code editors are increasingly popular: Cursor, developed by Anysphere and used by many in the Fortune 500, and Windsurf, a newer competitor, both promise to accelerate coding with built-in large-language-model logic layered into familiar editor environments. However, many of these tools rely on the open-source codebase of Visual Studio Code and the Electron framework—which in turn depend on Chromium and the V8 JavaScript engine. When the underlying browser engine is outdated and no longer receives patches, the software inherits all the downstream bugs—and that’s exactly what researchers found.
According to a recent BleepingComputer article, the latest releases of Cursor and Windsurf are vulnerable to more than 94 known and patched security issues in Chromium and V8. The researchers from Ox Security pointed out that the apps embed a version of Chromium many major iterations behind the current build. Because Electron packages its own Chromium and V8 engine, the applications stay stuck on the older code unless the vendor updates it. One demonstration saw CVE-2025-7656, a Maglev JIT integer overflow in V8, exploited via deep link to crash the IDE and possibly escalate privileges. Cursor’s vendor responded by calling the issue “out of scope,” which prompted further concern. Meanwhile, the user base for these two IDEs is estimated at 1.8 million developers—meaning a large number of people may still be running vulnerable versions.
The situation gets worse when you consider that the vulnerabilities are not just theoretical. Another recent disclosure highlighted that Cursor, by default, ships with “Workspace Trust” disabled—meaning that when a developer opens a folder (for instance, from a repository clone) the editor may auto-run tasks defined in .vscode/tasks.json. If an attacker crafts a malicious repository containing such a task, just opening the folder could silently execute code under the user’s privileges. This is a textbook supply-chain or repository-poisoning attack, and it hits the development tool (which often has elevated privileges and access to source code, build scripts, credentials, etc.). The fact that developers treat IDEs as “safe” is a dangerous assumption—especially when the editor auto-executes tasks without explicit trust.
Furthermore, in August 2025, additional vulnerabilities were disclosed in Cursor’s Model Context Protocol (MCP) servers—CVE-2025-54135 (“CurXecute”) and CVE-2025-54136 (“MCPoison”)—which allowed arbitrary code execution via malicious configuration changes to the MCP server. While patches for these were issued in Cursor version 1.3.9 (for CurXecute) and 1.3 (for MCPoison), these disclosures underscore that the risk isn’t just in the underlying browser engine but in the AI-specific layers and integrations built on top of it.
From a right-leaning, conservative perspective, the story underscores a broader lesson about technological reliance and stewardship: high-productivity tools are not automatically safe; when commercial incentives push rapidly to ship features, security clean-up often lags. The developers of these AI-enabled editors are essentially running a business model of rapid growth and feature hype, but the security burdens fall on the users—developers, teams, enterprises—who are expected to catch up and patch after the fact. It’s a market dynamic: tools get adopted quickly, trust builds, but the maintenance burden is deferred. That matters when those tools sit at the heart of software development pipelines, which are mission-critical for many companies.
So, what should developers and teams do today? First: update—install the latest versions of Cursor or Windsurf (or other forks) that patch the known vulnerabilities. If no update is available, consider disabling the IDE temporarily or switching to a better-maintained alternative (for example, traditional VS Code with timely updates). Second: audit your extensions and task configurations—treat them like endpoints. Just because a repository is public or a task file is standard doesn’t mean it’s benign. Enable workspace trust, require confirmation before tasks run, and limit extension usage to trusted sources. Third: recognise your tools as part of your attack surface. Developer machines often have access to credentials, production YAML files, docker images, build servers—so a compromised IDE is not a low-risk event; it can lead to supply-chain compromise, code theft, build sabotage, production backdoors. Fourth: organisations should establish policies around IDE security, updates, and extension/plug-in governance—this is often overlooked but essential.
In short: the promise of AI-boosted coding productivity is real, but the risks are real too—and mostly avoidable with proper vigilance. The case of Cursor and Windsurf is a cautionary tale that popularity and hype aren’t enough; software must be maintained, dependencies updated, and trust assumptions challenged. If you build software for a living or rely on it in your organisation, treat your IDE like you treat any other critical infrastructure—because it is.