Fix your know 94 vulnerabilities you selfish devs

[vndre]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

CVE-2025-7656 is one of the several vulnerabilities already public disclosed and patched in the latest version of Chromium, which is used by Electron, which is the engine that powers Cursor.

All Chromium versions prior to 138.x.x are vulnerables. Cursor is currently using version 132.x.

Steps to Reproduce

Ignorant users of this vulnerability could open a link that opens Cursor internal browser, prompting the IDE to execute potential malicious code locally on the user’s machine.

The BleepingComputer article (Cursor, Windsurf IDEs riddled with 94+ n-day Chromium vulnerabilities) mentions:

"Upon receiving the proof-of-concept exploit, Cursor dismissed the report by saying that self-inflicted DoS is out of scope.

But the researchers noted that this stance ignores the more severe exploitation potential of the flaw, including memory-corruption primitives, or even the broader set of unpatched CVEs in the Electron apps used.

“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,” explains Ox Security."

Expected Behavior

For Cursor devs to not look for lame excuses for not patching public disclosed vulnerabilities that can potentially harm their users because they are “out of scope” (the f that means?)

Screenshots / Screen Recordings

Operating System

Windows 10/11
MacOS
Linux

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.7.53
VSCode Version: 1.99.3
Commit: ab6b80c19b51fe71d58e69d8ed3802be587b3410
Date: 2025-10-20T19:15:58.572Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 25.0.0

Additional Information

Users working with Cursor in businesses should immediately stop using this IDE until devs publicly address and fix this vulnerabilities by simply upgrading to the latest patched version of Chromium.

Does this stop you from using Cursor

Yes - Cursor is unusable

[danperks]

Hey, here’s our official statement from our security team:

We’re aware of OX Security’s post noting that our current Electron/Chromium baseline lags upstream, which means we inherit publicly known Chromium n-day CVEs. OX’s vulnerability disclosure to us focused on a denial-of-service (DoS) condition triggered by CVE-2025-7656; because their report did not demonstrate exploitation beyond a crash, we responded that DoS is out of scope for our program. However, we take supply chain risk seriously and are focused on reducing inherited n-days by tightening our Chromium/Electron update cadence. We expect to ship fixes for the known vulnerabilities by the end of October.

We’ve reviewed the relevant CVEs to evaluate the immediate risk, found no zero-click path, and no exploitation has been demonstrated against Cursor. The cited proof-of-concept requires a user to follow a deep link to an attacker-controlled page, and in Cursor those actions are user-gated (e.g., deep-link MCP installs show a confirmation, and browser/tool actions require approval by default). In short, any realistic attack would require user interaction rather than silent compromise.

We’re actively evaluating tightening our timelines for dependency updates to reduce inherited n-days, while preserving stability and compatibility. In parallel, we will continue to harden our user-in-the-loop protections so unsafe actions remain visible and interruptible.

Given today’s known vulnerabilities and our guardrails, the practical risk is limited to scenarios that require user interaction for which we have user-in-the-loop protections to prevent unsafe actions. We’ll keep you updated as we improve our update cadence and continue shipping targeted hardening and fixes.

Any further queries, do let us know!

[vndre]

Thanks for taking the time to reply Dan.

Although a public acknowledgement of the still present vulnerabilities is a bit reassuring there are still statements in that reply that worry me:

because their report did not demonstrate exploitation beyond a crash, we responded that DoS is out of scope for our program.

I feel it should not be, OX in this case, the responsible to demonstrate all the potential harms and deeps of YOUR product’s vulnerabilities. that is your job, OX are just been kind to report you with no obligation to do so.

I feel you also should threat ALL vulnerabilities with the same level of seriousness, I’m not the one that should say this but that’s the meaning of a vulnerability: it’s a “weakness”, a “hole” in your system that you probably weren’t aware of, so if there is ONE thing you weren’t aware of there could be many more, I think you are aware of how creative hackers can be this days (the recent VS Code marketplace malware is pretty crazy), so maybe OX was just giving you an example of the who knows how many ways hackers can exploit this, you shouldn’t take any risk.

we take supply chain risk seriously

We expect to ship fixes for the known vulnerabilities by the end of October.

I find this two statements to be very contradictory: Are you aware that now that this information is public hackers know they have 8 days to exploit the hundred Chromium vulnerabilities? Does that sounds that you are really taking this seriously?

We’ve reviewed the relevant CVEs to evaluate the immediate risk, found no zero-click path, and no exploitation has been demonstrated against Cursor. The cited proof-of-concept requires a user to follow a deep link to an attacker-controlled page, and in Cursor those actions are user-gated (e.g., deep-link MCP installs show a confirmation, and browser/tool actions require approval by default).

That is awesome from your part, that you already evaluated this vulnerability and found it not so critical (at least just this 1 vulnerability from 94 known ones). but…

In short, any realistic attack would require user interaction rather than silent compromise.

This is the part that worries me. Your software is also used by non-professionals and “vibe coders” that may not be aware of the risks of their actions, I’ve seen it countless of times. That’s why I created this post, just to raise awareness in general.

We’re actively evaluating tightening our timelines for dependency updates to reduce inherited n-days, while preserving stability and compatibility. In parallel, we will continue to harden our user-in-the-loop protections so unsafe actions remain visible and interruptible.

I think OX conclusions are point-on:

• 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

[SkinnnyJay]

Thanks for raising this @vndre, They have a Security page that helps explain some of the challenges an how they respond.

As someone who has been obsessed with Cursors internals, with every update I first check Cursor → About and read the version info… When I read the blog post and saw Securities original response I was saddened. I appreciate @danperks helping to clarify and expand on the comment. I hope the security team learns from this interaction with the broader security community.

I completely agree that the scale of issues (94+ known vulnerabilities, plus supply-chain concerns like malicious npm packages and RCE vectors) This also doesn’t take into account the internal cursor dependencies tree. This demands more than “not in scope“ an “it’s on our roadmap” response.

Here’s why addressing these rigorously doesn’t just check a box - it gives Cursor a chance to elevate its standing among its peers and enterprise tools:

1. Enterprise expectations = proactive visibility

   Big organisations adopting developer tools expect transparency: an inventory of risks, clear ownership, patching metrics, and auditability. By publishing a dependency-vulnerability dashboard or internal audit summaries, Cursor would signal that they’re managing attack surface not leaving it to chance.

2. Leadership via security = competitive advantage

   Many IDEs/code-editors rely on community extensions, forks of VS Code, etc. That flexibility opens considerable risk. Cursor can distinguish itself by saying: we treat our editor + extension ecosystem + dependencies like our core product. That signals to InfoSec teams “we’ll meet your controls” rather than “we hope you waive them.”

3. Closing loops = building trust with high-stakes users

   In regulated or high-risk domains (finance, defence, IP-heavy SaaS, etc), a tool with 90+ known vulns will trigger procurement and risk teams’ red flags. By committing to a remediation cadence, publishing proof of fixes, and working through supply-chain exposures (malicious packages, RCE chains) Cursor moves from “nice to have” to “enterprise-ready.”

4. Security posture = future proofing

   As AI-driven code tools become mission-critical parts of dev-toolchains, security starts being a differentiator, not just a checkbox. The more proactive Cursor is now, the better positioned they’ll be as enterprises require SaaS/IDE vendors to deliver SOC 2, ISO 27001, SBOMs, transparent telemetry – and minimise exploitable surface. With the controls page showing things like annual penetration testing and vulnerability monitoring, the key question isn’t “do you have control” but “are you applying them effectively and fast enough” given the scale of known issues. Cursor SOC Trust Center

5. The optics matter

   Saying “we’re on it” is OK. Publishing what you’re doing, how fast, and how you’re verifying it is powerful. That transforms the narrative: from “tool with vulnerabilities” → “tool we trust because they show us how they manage them.”

Recommendations for Cursor (and for the community to ask for):

• Security team should publish a blog post, to the claims and what the team is doing to mitigate these widely known issues and engage with the security community. Some of this is disclosed in the Security page but could be better.

• Publish a prioritized list of known high-risk dependencies + age of last update + planned mitigation. While I understand that SOC 2 doesn’t specify fixed days, in practice many high-trust organisations commit to remediating critical dependencies within e.g. 7-15 days, high ones within 30 days. Seeing the ‘age’ for each known issue and the next-step plan would help us evaluate whether Cursor’s remediation cadence is aligned with enterprise expectations.

• Provide transparency in extension ecosystem: signed/verified extensions, blacklist of malicious/impersonated ones. VS Code signing for extensions

• Offer SBOM (Software Bill of Materials) and version-tracking so enterprise customers can trace dependencies.

• Conduct regular red-team and independent third-party security audits, and publicly publish executive-summary findings. It’s concerning that publicly noted vulnerabilities have persisted without triggering apparent SOC-level control failures.

I believe their engineers are up to the task. I’m invested in what Cursor is building since day one and believe they can set a new standard among AI-IDE tools. **The question now is how loudly they choose to signal it – by actions, not just words.

🅷 🆈 🆃 🅷 🅴 🅻

[Keko]

The company I am working for is currently prohibiting the usage of Cursor because of this response to security issues. I can’t imagine that we are the only company which is taking something like this very serious and you are probably loosing quite a lot of enterprise customers.

I checked the latest version of Cursor and saw that Chromium was updated to 138.0.7204.251, which is great but an official response and how you are going to approach security findings in the future would still help.