[EDIT: See the response by a Cursor dev below — looks like it was not authorized by them]
Sounds to me like Cursor internally has a private NPM registry with those packages. Because of how NPM works, it's quite easy to trick it to fetch the packages from the public registry instead, which could be used by an attacker [0].
Assumably, this Snyk employee either found or suspected that some part of Cursor's build is misconfigured as above, and uploaded those packages as a POC. (Given the package description "for Cursor", I'd think they were hired for this purpose.)
If that's the case, then there's not much to see here. The security researcher couldn't have used a private NPM registry to perform the POC if the point is to demonstrate a misconfiguration which skips the private registry.
I need to get serious about doing all development inside a virtual machine. One project per VM. There are just too many insidious ways in which I can ignorantly slip up such that I compromise my security. My only solace is that I am a nobody without secrets or a fortune to steal.
IDEs, plugins, development utilities, language libraries, OS packages, etc. So much code that I take on blind faith.
The only part of the article I disagree with is this line:
> But in general, it’s a good idea not to install NPM packages blindly. If you know what to look for, there are definite signals that these packages are dodgy. All of these packages have just two files: package.json and index.js (or main.js). This is one of several flags that you can use to determine if a package is legit or not.
This works -- maybe OK for top-level packages. But for transitive dependencies it's nearly impossible to vet every transitive dependency.
They also mark projects as "abandoned" if they move to any other forge that isn't github. And they stay abandoned even if new releases appear on npm/pypi :D
Their competence isn't as big as their fame, in my opinion.
Also one of their sales people insulted me over email, because apparently not being interested in buying their product means you're an incompetent developer who can only write software filled with vulnerabilities.
Without more context, this doesn't look great for Snyk either way: either they have an employee using NPM to live test their own services, or they have insufficient controls/processes for performing a legitimate audit of Cursor without using public resources.
Looks like NPM is generating jobs for those in the security field. It’s an unfixable mess, I really hope some competition like JSR will put enough pressure on the organization.
OT: Has anyone ever gotten (proper) SBOMs for Snyks own tools and services? Asking because they want to sell my employee their solution (which does SBOMs).
Snyk Research Labs regularly contributes back to the community with testing and research of common software packages. This particular research into Cursor was not intended to be malicious and included Snyk Research Labs and the contact information of the researcher. We were very specifically looking at dependency confusion in some VS Code extensions. The packages would not be installed directly by a developer.
Snyk does follow a responsible disclosure policy and while no one picked this package up, had anyone done so, we would have immediately followed up with them.
Why, after all these years, are we still doing this stupid thing of using a global namespace for packages? If you are a company with an internal package registry just publish all your packages as @companyname/mylib and then no one can squat the name on a public registry. I thought we collectively learned this 4 years ago when dependency confusion attacks were first disclosed.
In the Java world, you need to prove ownership of a given namespace (group id), e.g. via a TXT record for that domain. Isn't there a similar concept for NPM? The package is named sn4k-s3c/call-home, how will a victim be tricked into referencing that namespace sn4k-s3c (which I suppose is owned by the attacker, not Cursor)? I feel like I'm missing part of the picture here.
NPM packages are the most bloated and unreadable pieces of code I've encountered. The creator of Node apparently hates all software and yet Google gave him the captain's hat and we're left with the absolute crap shoot that is web development. I feel guilty with an additional 1KB of code or 500 bytes of RAM but this is seen as an outsider opinion. I hope big tech rots and this is just a symptom.
https://news.ycombinator.com/item?id=3055154
Hopefully this makes the Cursor team reconsider security (which doesn't seem very good really).
Stopped using it for serious stuff after I noticed their LLMs grabs your whole .env files and sends them to their server... even after you add them to their .cursorignore file. Bizarre stuff.
Now imagine a bad actor exploiting this... recipe for disaster.
> All of these packages have just two files: package.json and index.js (or main.js). This is one of several flags that you can use to determine if a package is legit or not.
Wouldn't a lot of small packages consist of just these two files, meaning seeing just these two files in a package may raise an eyebrow but hardly be a smoking gun?
Behind hundreds of builds Snyk has been a challenging integration that ultimately creates very low value. I recommend using a decent team that goes in for flow weaknesses as these are most responsible for significant findings...
The TL;DR is that our security research team routinely hunts for various vulnerabilities in tools developers use. In this particular case, we looked at a potential dependency confusion attack in Cursor, but found no vulnerabilities.
There's no malicious intent or action here, but I can certainly understand how it appears when there's not a ton of information and things like this occur! As a sidenote, I use Cursor all the time and love it <3
Snyk security researcher deploys malicious NPM packages targeting cursor.com
(sourcecodered.com)569 points by arkadiyt 13 January 2025 | 311 comments
Comments
Sounds to me like Cursor internally has a private NPM registry with those packages. Because of how NPM works, it's quite easy to trick it to fetch the packages from the public registry instead, which could be used by an attacker [0].
Assumably, this Snyk employee either found or suspected that some part of Cursor's build is misconfigured as above, and uploaded those packages as a POC. (Given the package description "for Cursor", I'd think they were hired for this purpose.)
If that's the case, then there's not much to see here. The security researcher couldn't have used a private NPM registry to perform the POC if the point is to demonstrate a misconfiguration which skips the private registry.
.
[0] In particular, many proxies will choose the public over the private registry if the latest package version is higher: https://snyk.io/blog/detect-prevent-dependency-confusion-att...
I hope there is no foul play.
IDEs, plugins, development utilities, language libraries, OS packages, etc. So much code that I take on blind faith.
> But in general, it’s a good idea not to install NPM packages blindly. If you know what to look for, there are definite signals that these packages are dodgy. All of these packages have just two files: package.json and index.js (or main.js). This is one of several flags that you can use to determine if a package is legit or not.
This works -- maybe OK for top-level packages. But for transitive dependencies it's nearly impossible to vet every transitive dependency.
If you're pulling in a package that has 400 dependencies, how the heck would you even competently check 10% of that surface area? https://gist.github.com/anvaka/8e8fa57c7ee1350e3491#top-1000...
They also mark projects as "abandoned" if they move to any other forge that isn't github. And they stay abandoned even if new releases appear on npm/pypi :D
Their competence isn't as big as their fame, in my opinion.
Also one of their sales people insulted me over email, because apparently not being interested in buying their product means you're an incompetent developer who can only write software filled with vulnerabilities.
They should be running a private npm repo for tests (not difficult to override locally) and also their own collaborator server.
Snyk does follow a responsible disclosure policy and while no one picked this package up, had anyone done so, we would have immediately followed up with them.
Stopped using it for serious stuff after I noticed their LLMs grabs your whole .env files and sends them to their server... even after you add them to their .cursorignore file. Bizarre stuff.
Now imagine a bad actor exploiting this... recipe for disaster.
Wouldn't a lot of small packages consist of just these two files, meaning seeing just these two files in a package may raise an eyebrow but hardly be a smoking gun?
Helps in cases like this.
[1] https://www.githax.com/
The TL;DR is that our security research team routinely hunts for various vulnerabilities in tools developers use. In this particular case, we looked at a potential dependency confusion attack in Cursor, but found no vulnerabilities.
There's no malicious intent or action here, but I can certainly understand how it appears when there's not a ton of information and things like this occur! As a sidenote, I use Cursor all the time and love it <3
Yes, but also impractical.
Think xz-utils but even much less sophisticated exploits.
I don't see any systematic protection against this?
https://en.wikipedia.org/wiki/Snyk
I was dismayed to learn about their choice of brand, and think it might cause confusion. :(