Patch the browser you code in
- Komodo Research_maya933
- 7d
- 3 min read
Updated: 1d

AI IDEs such as Cursor and Windsurf include their own browser engine. If that engine is not up to date, it carries known vulnerabilities. This week’s signals show Cursor 2.0 released on Oct 29, 2025 without a stated browser upgrade in the Cursor 2.0 changelog. Users also posted About screenshots that still show older builds. Windsurf’s October notes list a newer baseline in the Windsurf changelog. Treat these tools like browsers: verify versions, reduce risky paths, upgrade when available.
What changed this week
Oct 29, 2025: Cursor published 2.0. The notes focus on features. No Chromium or Electron version is listed. See the Cursor 2.0 changelog and the product post Introducing Cursor 2.0 and Composer.
Oct 28–30, 2025: Forum About screenshots still show older engine builds in 2.0.x. Example: 2.0.34 About.
Oct 17–22, 2025: Windsurf notes a newer dependency baseline. See the Windsurf changelog.
How this happens in practice
An IDE can look fully updated, yet the browser engine inside it may not be. Many desktop apps bundle a fixed Chromium build through Electron. Until the vendor releases a new build, that embedded engine can remain months behind Chrome or Edge, which receive frequent security patches.
Why this matters
Developers open readme files, links, and extensions inside the IDE. If the embedded browser is behind on patches, those routine actions can expose the workstation. A developer machine often has credentials, source code, and CI access. One compromise can move downstream fast, especially in regulated environments.
Who is affected
Teams running Cursor or Windsurf on laptops, VDI, or helper hosts
Teams that preview Markdown or open external links inside the IDE
Teams with many extensions or loose extension policies
What to do in the next 72 hours
Inventory, day 1
List all machines with Cursor or Windsurf.
Record the app version. If the About dialog shows the browser engine version, note it.
If the version is unclear, treat the machine as higher risk until confirmed.
Reduce exposure, day 1–2
Open logins and vendor portals in the system browser, not inside the IDE. Make this a rule.
Limit outbound traffic for IDE processes on developer machines. Start with egress controls.
Pause new extensions. Keep a short allowlist of required ones.
Upgrade or contain, day 2–3
Windsurf: move to the latest build listed in the Windsurf changelog. Validate after.
Cursor: monitor the Cursor changelog. When a browser engine update appears, plan a fast upgrade. Until then, keep the restrictions above.
If no update is available, consider a temporary shift to a tool that patches its engine on a predictable schedule.
Detection starter, Microsoft Sentinel
This query helps build a quick inventory from Defender for Endpoint.
DeviceTvmSoftwareInventory
| where SoftwareName in~ ("Cursor","Windsurf")
| summarize arg_max(LastSeen, *) by DeviceName, SoftwareName
| project DeviceName, SoftwareName, SoftwareVersion, LastSeenValidate the change
Export a before and after inventory of Cursor and Windsurf versions.
Attempt to open a link from inside the IDE and confirm it opens in the system browser. Capture a screenshot.
Re-run the inventory the next day to check for drift or machines that missed the change.
Compliance note
Keep the inventory export, the egress policy change record, and the change ticket with validation notes. Retain for 90 days, or per your policy. These artifacts support common asks under SOC 2, ISO 27001, and NIS2 programs.
Enhance security with Komodosec.
Book a 45 minute IDE risk check with Komodosec



Comments