Outdated VSCode Extensions May Contain Known CVEs

[MilesCranmer]

Hey all,

Loving cursor. I wanted to encourage the development team to please keep up-to-date with the upstream VSCode repo, as otherwise there can be major security risks in user extensions which are not automatically updated due to version incompatibility.

For example: there is a known high-severity CVE for the main Python extension: NVD - CVE-2024-49050. This was patched by v2024.20.0.

However, the current version of Cursor is stuck on an old version of the Python extension - version v2024.13.0 (or earlier) - which appears to have the CVE:

This means all Cursor clients that use the Python extension may still be affected by a high-severity CVE until this is patched – and might have been since this CVE was published (and immediately patched) on November 12, 2024.

I think this particular issue (which itself should be patched ASAP) demonstrates a broader problem of out-of-date extensions potentially having known CVEs and not getting patches, which results in publicly documented attack vectors that anybody could look up and exploit. I strongly recommend that the Cursor team prioritise keeping Cursor as up-to-date with the VSCode fork as possible.

I note that I am posting this publicly as this has been a known CVE since November. Attackers wishing to exploit this could have utilised this exploit since then. So this should not be new information.

Love cursor and hoping that this class of issue can be improved.
Thanks!

[jiun]

Despite numerous bug reports and discussions about outdated Python extensions (Python debugger, Python, Pylance) on both the forum and GitHub for quite a while now, the Cursor team still hasn’t come up with a proper response. Honestly, it’s hard to understand this kind of response for a language that’s so widely used by many users for various purposes.

I don’t think this issue is impossibly difficult to solve. In fact, another company has already demonstrated a viable solution path by providing up-to-date Python extensions and developing their own language server extension as an alternative to Pylance. I hope the Cursor team can prepare and announce a proper response and solution soon.

Here are the recent related bug report links for reference:

`FixtureFunction` spam when there's unknown types

[image] I used to see this in VSCode, and it was fixed in some specific Pyright version - it seems Cursor’s isn’t there yet?

Issues With Python Testing

I’m observing inconsistencies between python testing in VS Code and Cursor. I’m specifically running Django unittests. One issue is that Cursor is unable to discover all of my tests, but they show in VS Code. See example below showing a missing test_admin.py file. Example: Cursor on left, VS Code on right [cursor_v_vs_code] Another issue I’ve seen is inconsistent test results. Tests will fail occasionally in Cursor but will always work when running in VS Code or directly from the terminal. …

[Adam]

This is … troubling.

It may not be so easily resolved.

So, I got curious after seeing this. My work is largely centered around researching different threats and sometimes exploits, so for a while, I have been wondering what kind of security is even in place for VS Code itself, since frankly, I am just waiting on someone to really do some damage via the extensions marketplace, somehow. It seems like a really easy target (not that I am inviting anyone to try).

But, my own gloom and doom aside, I just tried a bunch of different ways to install the official Pylance/Python extension from VS Code, directly into Cursor.

Let me say: Yeah, don’t try that lol. Pretty sure I broke some stuff which I will be fixing momentarily heh. In the meantime, I wanted to share this here. And thanks for posting this, by the way - I actually was not even aware of this issue, so it’s good information to have.

It looks like there might not even be the option of such an update, at least not for Pylance? According to Microsoft, not even Code OSS can install the extension. After I had tried to copy files over from VS Code directly, I found my way to the Pylance Releases on GitHub, and basically there are .zips available but they are not much, and certainly not a proper .vsix package.

Inside, though, there’s a Markdown doc that has this statement.

So, at least for the official Python extension - it seems like this would not be possible. Full disclosure I am barely awake at the moment so I may just be stating the obvious, but anyway…

Edit: Just to ask - would I be correct in understanding that this is something that could actually be pulled in from the upstream VS Code repo, rather than just the extension itself? I would not have expected that, but reading the post here again, I waanted to ask this.

[Adam]

So, this deserves a bump. I was actually surprised that there were not more replies, or any kind of attention on this post when I returned after over a month later. Anybody know anything more specific about the CVE? I am not opposed to proof of concept’ing it and writing a post or something, if it would get the appropriate attention doing so.

[MilesCranmer]

Just checked again today – the high-severity CVE is still present in Cursor. Can the Cursor team please provide an update on when this critical security issue will be resolved? It’s really hard to understand why this hasn’t been patched yet.

[MilesCranmer]

Tagging some Cursor team members to make sure this gets attention: @ericzakariasson @danperks

I also want to emphasise I genuinely love Cursor and just want to see this resolved soon.

Thanks

[MilesCranmer]

@Adam

Edit: Just to ask - would I be correct in understanding that this is something that could actually be pulled in from the upstream VS Code repo, rather than just the extension itself? I would not have expected that, but reading the post here again, I waanted to ask this.

As far as I understand, the newer version of the ms-python.python extension (the one that has the exploit fix) isn’t compatible with older VS Code versions. Since Cursor currently uses an older VS Code fork, users are simply unable to use the patched extension.

Possible solutions seem to be:

1. Cursor team pulls changes from the upstream VS Code repo to move the latest version, allowing compatibility with patched extensions.
   • I think this is the best option. Perhaps there are technical reasons this is challenging though (?). But there are probably other extensions that have or will have similar exploits that are publicly documented at the time of fixing.
2. Cursor maintains its own fork of ms-python.python to backport the security patch. I think this is a lower effort fix that could be done quickly, but would still address the issue.

We could also consider asking Microsoft for a compatibility patch for older VS Code versions – though realistically, they might just advise us to use the latest VS Code rather than patch security issues on behalf of a competing product.

@Adam

Anybody know anything more specific about the CVE?

I read through it a bit out of curiosity. It’s a remote code execution exploit. It can be triggered remotely without authentication (hence the high severity rating), though it requires user interaction. More details here: Security Update Guide - Microsoft Security Response Center.

They don’t have a full example, but my guess is that it’s basically just: an attacker convinces a user to just open a malicious Python file for editing in Cursor, and the extension activating on that file would immediately execute the code with the user’s own privileges, without them hitting “run”. And with that they can potentially read or modify the user’s files, install malware, or otherwise compromise anything the user has access to.

A realistic attack scenario might look like this:

1. Attacker creates a malicious Python file that triggers the exploit.
2. Attacker submits that file (possibly disguised to look harmless) via a pull request to the victim’s GitHub repository.
3. The victim, looking to review the PR, checks it out and opens the workspace in Cursor, triggering the exploit through the outdated Python extension. At this point, the attacker gains full control at the user’s privilege level.

The CVE was published on November 12th 2024 and at that time it was listed with “No publicly available exploit code is available.” So at the time of publication there wasn’t a working demo of this – it was fixed before anybody could do that. But since it is now fully documented in the open, it’s likely just a matter of time before someone develops and exploits the vulnerability if they haven’t already. So it goes without saying it is really important the Cursor team addresses this ASAP.

[danperks]

Hey, I’ll raise this with the team, but the best thing to do would be to report this as a security issue here, and the right people internally with investigate and respond:

Build software better, together

[MilesCranmer]

Hi Dan,

Thanks.

I am happy to do this. But I would like to note that this is an already-published high-severity vulnerability in an upstream dependency. In other words, this should already be on the security team’s radar, I should not need to re-publish it in other mediums. There are various services for monitoring CVEs.

Best wishes,
Miles