Is Cursor 3.29.15 exposed to the Chrome 0-day and VS Code MCP CVEs?

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Questions

  1. Are these two vulnerabilities actually exploitable in Cursor, given how Cursor uses Chromium and handles MCP notifications?
  2. If Cursor is affected, roughly when can we expect a patched build?

Vulnerabilities

CVE-2026-125350 – High-severity use-after-free in XML in Chromium. Google states that “an exploit for CVE-2026-125350 exists in the wild,” and CISA added it to the KEV catalog on November 10. Fixed in Chrome 157.0.8103.50/.51 and Extended Stable 156.0.8078.96.

CVE-2026-120779 / GHSA-66hq-jw93-462h – VS Code code injection (NVD CVSS 9.6). A malicious MCP server can craft an elicitation fallback notification whose text is rendered as a command link; clicking it can run a VS Code command. Affects VS Code < 1.145.3, fixed in 1.145.3 (released November 10).

My environment

Version: 3.29.15 (system setup)
VS Code Extension API: 1.128.0
Commit: 86776fcb52ca505783155631089b65d646f9b030
Date: 2026-11-08T21:35:59.668Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 43.8.4
Chromium: 150.0.7871.250
Node.js: 24.22.1
V8: 15.0.245.31-electron.0
OS: Windows_NT x64 10.0.26200

What I’d like to understand

On CVE-2026-125350 (Chromium)

  • Chromium 150.0.7871.250 is below both fixed versions. Does Cursor ever load untrusted or remote web content in a way that could reach the vulnerable XML code path (e.g. built-in browser/preview, docs, extension webviews, Markdown preview), or is the exposure limited?
  • As far as I can see, the first stable Electron with the fixed Chromium is 45.3.0 (Chromium 156.0.8078.96, released November 10 UTC); Electron 43.8.8 is still on Chromium 150. Is Cursor planning to move to Electron 45.3.0+, or to backport the fix to its current Electron line? Is there an expected timeline?

On CVE-2026-120779 (VS Code MCP elicitation)

  • Cursor is based on VS Code 1.128.0. Does Cursor use the upstream MCP elicitation fallback notification, or does it have its own MCP UI that isn’t affected?
  • If it is affected, when will the fix be backported or the VS Code base be updated?

Interim guidance

  • Until a patched build ships, are there recommended mitigations (e.g. avoiding untrusted MCP servers, not clicking links in MCP notifications, disabling the built-in browser)?

References

No exploit reproduction was attempted. Thanks!

Steps to Reproduce

  1. Open Cursor 3.29.15 (Stable, Windows x64) and go to Help > About.
  2. Check the bundled versions: Electron 43.8.4, Chromium 150.0.7871.250, VS Code Extension API 1.128.0.
  3. Compare them with the fixed versions:
    • CVE-2026-125350: Chromium 156.0.8078.96 (Extended Stable) or 157.0.8103.50+
    • CVE-2026-120779: VS Code 1.145.3+
  4. Both bundled versions are below the fixed versions, and the release notes don’t mention a backport.

Note: This is a version-based report only. No exploit reproduction was attempted.

Operating System

Windows 10/11

Version Information

Version: 3.29.15 (system setup)
VS Code Extension API: 1.128.0
Commit: 86776fcb52ca505783155631089b65d646f9b030
Date: 2026-11-08T21:35:59.668Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 43.8.4
Chromium: 150.0.7871.250
Node.js: 24.22.1
V8: 15.0.245.31-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

I can’t say whether Cursor’s build is affected; only Cursor staff can. Some facts that may help while you wait.

The VS Code advisory says the bug is “in the fallback notification path for MCP elicitation requests”, and “An attacker would need to control a connected MCP server and convince the user to click the malicious link in the resulting notification.” The fix was “rendering elicitation messages as literal text and validating the request payload before displaying it.”

I checked upstream VS Code at tag 1.128.0, the base your build reports. src/vs/workbench/contrib/mcp/browser/mcpElicitationService.ts has the fallback branch (no chat session, notification plus quickpick) that passes elicitation.message to the notification service. So the path exists in that base. Whether Cursor ships or reaches it is the question for staff, since Cursor’s MCP docs list Elicitation as supported.

Until then, the advisory’s own workaround: “Only connect to trusted MCP servers, and do not activate links in notifications produced by an untrusted server.”

On severity, GHSA lists High 8.3 and NVD lists 9.6, so both numbers are real. For the Chromium bug, NVD’s CVE-2026-125350 entry says it affects Chrome “before 157.0.8103.50”, and Chromium 150 is below that.