Snyk security researcher deploys malicious NPM packages targeting cursor.com(sourcecodered.com) |
Snyk security researcher deploys malicious NPM packages targeting cursor.com(sourcecodered.com) |
Think xz-utils but even much less sophisticated exploits.
I don't see any systematic protection against this?
Your criticism sounds to me like "just a reminder that this armed bodyguard service comprises Navy SEALs and Army Rangers". Uh, great!
Most companies where I've worked as a security researcher, you get some time as part of your job to hack on random stuff to be able to generate interesting talks / research. This feels like that.
This isn't a special cyber spooky practice, most pentesting companies do this to generate IP (rarely, lol), buzz (reasonably often) and keep the staff happy (this is really the main thing).
It's rare for management to be fully across the scope of this.
It has less to do with whether it malicious intent from the start of building an organization for explicit intent of capturing core infra. It has more to do with how the Government of Israel operates and the legal requests they can make of their citizens and/or veterans.
Perhaps concern over Israeli products should be probably higher than for China as Israel more well known incidents of exploits as a State actor like with Stuxnet, Pegasus or more recently with pagers etc.
China no doubt has their own share of operations but they either have not used them as publicly in a large scale overt operation or been more discreet about it.
Point is the concern is valid just as it would be valid for China.
In other words, it's staffed by Israeli kids who made the choice most of us would have made under the circumstances. It seems a bit unfair to hold that against them more than 10 years later, no?
You could say the same about the guy in a call center in India trying to pull a tech support scam on you over the phone. Yes, he's probably making the best choice he can for his own livelihood, probably the same thing you would do in his position. No, that doesn't mean you should trust him.
Just as you have to treat all Chinese companies as under control of the PRC government and all Australian companies as compromised by their security services, you have to treat all Israeli citizens as under the control of the Israeli military. Any adult can be conscripted and they have a history of disguising military operations as civilian ones. Someone might tell you they left the Israeli military 10 years ago and they're probably telling the truth, but if you make a habit of believing that statement you're going to get burned.
Did Cursor made claims to this effect and invited public to hack them?
Or are you equating someone saying they "take security seriously" to "it's an open season, please attack our systems."?
I was dismayed to learn about their choice of brand, and think it might cause confusion. :(
There is no equivalence intelligence gathering or gaining the capability for sabotage (which everyone does) versus actual active sabotage which today only Israel executes like with Stuxnet or with the pagers.
No, you can't, because the scammer in the call center is choosing that over thousands of other options. Are they choosing to maximize their pay? Maybe. But for every scammer there are thousands of Indians who show a different option.
Choosing to dodge or resist the draft is totally different—very few people do it, and those who do get prison terms. If you sincerely believe that you'd have chosen to go to prison rather than be drafted, more power to you, but I and most others would aim to minimize the likelihood of ourselves dying and minimize the number of people I'd have to kill. For me that would have meant signing up for cyberwarfare, which in Israel would have meant Unit 8200.
The rest of your comment is totally irrational fear-based speculation. Anti-Israel sentiment may not be antisemitic, but it sure shares the same tendency towards irrational fear and aggression.
No, they're the people who don't have other options (because they lack the skills and/or qualifications and/or are discriminated against). It's not malice, it's just desperation to get money to live on (or, often, to provide for people who depend on them). But of course the end result is the same.
> The rest of your comment is totally irrational fear-based speculation.
Entirely rational given the historical pattern of behaviour shown by the Israeli military, and the fact that they have no reason to change (quite the opposite).
Got it , and are now all American companies suspect because they are managed behind the scenes by Musk and Trump?
if you're born there, you have little choice in the matter.
Given that unless you are in Israel you're most likely to be meeting Israeli expats or at the very least people who travel, that's hardly surprising and not great evidence for anything.
> In fact, the Snyk founder lives in London now
So you're acknowledging that you're going to hold their country of origin against them even after they've moved. Got it.
I'm a US Navy veteran. Would you also stay away from my employers because they have veterans on staff?
Seriously, I get what you're trying to say, but I don't understand the broader point you're trying to make. So Snyk has some ex-IDF employees. Find a high-profile infosec firm that doesn't. They military service they were compelled to has a reputation at being really, really good at infosec. I see no reason why companies shouldn't want to hire them afterward.
The claim was that Snyk was founded by Unit 8200 members.
Not that it had a few Israeli veterens, almost all Israeli's serve in the IDF after all.
https://en.wikipedia.org/wiki/Unit_8200
To be fair I have a former Unit 8200 member in my larger extended family who left and has since been vocal in opposition to Netanyahu so membership in an elite Cyber Unit alone doesn't define a person.
That aside, most Governments would keep an eye on a company started by, say, former NSA employees and watch for covert activity under any overt actions.
It was very widely reported across the globe.
People can't help where they're born, and you're wrong to hold that against them. You're welcome to work through that cognitive dissonance however you like, but in the meantime I will continue to advocate for treating individuals as individuals.
You “denouncing” people who make a rational calculation isn’t really helping to market the firms you are supporting.
If you don't criticise this, you are a terrible human being.
Genocide is bad also if you do it on dark skinned people, FYI.
Dresden was a war crime and played no part in winning the war. Same with the atomic bombs.
That said, this obviously isn't going anywhere, so have a nice day.
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...
we did not hire snyk, but we reached out to them after seeing this and they apologized. we did not get any confirmation of what exactly they were trying to do here (but i think your explanation that someone there suspected a dependency confusion vulnerability is plausible. though it's pretty irresponsible imo to do that on public npm and actually sending up the env variables)
Wouldn't it be more like "pretty illegal"? They could have simply used body: JSON.stringify("worked"), i.e. not sent target machines’ actual environment variables, including keys.
They could have demonstrated the POC without sending data about the installing host, including all your environment variables, upstream. That seems like crossing the line
Allowing someone full access to the contents of your environment (i.e. output of env command) is a big deal to most, I suspect.
What's the justification for taking all of the environment variables? This post tries to paper over that particular problem. If your goal was to see if you could attack the dependency chain the first steps of user+hostname would have been sufficient to prove your case.
Taking the environment variables is about taking the secrets, and kind of moves this from PoC to opposition supply chain attack. Not to mention it's not only Cursor devs that would be affected by this, it could have (if your plan worked) attacked anyone using the extensions.
It's also a tough buy given the note about the Snyk cofounder moving to compete directly with Cursor (courtesy @tankster): https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50...
Assuming truly innocent motivations, you guys still need to give your heads a shake and rethink your approaches here.
Who did the GDPR review before extracting env vars from systems that were not under your control? How did actively extracting potentially private data from the environment not get flagged as Unauthorized Access?
If this "experiment" (which happened to be against a competitor, mind) was reviewed and approved internally, that is a great demonstration of Snyk's approach to (ir)responsible data collection and disclosure.
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.
You're not supposed to leave public artifacts or test on public services during an assessment.
It's possible Cursor asked them to do so, but there's no public indication of this either. That's why I qualified my original comment. However, even if they did ask them to, it's typically not appropriate to use a separate unrelated public service (NPM) to perform the demo.
Source: I've done a handful of security assessments of public packaging indices.
They should be running a private npm repo for tests (not difficult to override locally) and also their own collaborator server.
I think what we're more likely to see is that leglislation like DORA and NSIS increasinly require that you audit third party packages. This enforcing a different way of doing development in critical industries. I also think you're going to see a lot less usage of external packages in the age of LLM's. Because why would you pull an external package to generate something like your OpenAPI specification when any LLM can write a cli script that does it for you in an hour or two of configuring it to your needs? Similarily, you don't need to use LLM's directly to auto-generate "boring" parts of your code, you can have them build cli tools which does it. That way you're not relying on outside factors, and while I can almost guarantee that these cli tools will be horrible cowboy code, their output will be what you refine the tools to make.
With languages like Go pushing everything you need in their standard packages, you're looking at a world where you can do a lot of things with nothing but the standard library very easily.
I wouldn't install it if you paid me to, because it feels a lot like Unit 8200 pumps out entrepreneurs and funds them so that (like the NSA) they have their foot already in the door.
It's the equivalent of observing that SFBA startups tend to have a lot of Stanford grads at the helm.
(I don't have any particular love for Snyk as a product suite. I think most supply chain security products are severely over-hyped.)
For example, if you're using a multi-protocol networking library, and it says that the version you have installed is has a vulnerability in its SMTP handling, but you don't use the SMTP functionality, is that a FP?
I'd argue that it's irrelevant, but not a false positive.
I never had it get the version of a library wrong.
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.
In response, you suggest that you'll send a letter of apology to the funeral home of anyone that got hit. Compromising their credentials, even if you have "good intentions", still puts them into a compromised position and they have to react the same as they would for any other malevolent attacker.
This is so close to "malicious" that it's hard to perceive a difference.
edit: Let's also remind everyone that a Snyk stakeholder is currently attempting to launch a Cursor competitor, so assuming good intentions is even MORE of a stretch.
But all of that is why they get popular. Lazy, crappy, easy things are more popular than intentional, complex, harder things. Shitty popular tech wins.
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.
If you want secure LLM you can use Mistral, which comes with all the EU limitations, good and bad.
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?
You have any idea how easy it is to fake it?
Also, snyk doesn't scan code that isn't on github, because they are under the impression that all the code in the world is on github, so things like gnome.org, debian salsa or codeberg are completely ignored.
So you won't get reliable data from snyk.
edit: snyk doesn't scan code at all, they rely on unrelated "metrics" to give a rating that is not very useful.
Helps in cases like this.
So any third party code changes end up in git commits and are easily visible and reviweable.
So running npm update/upgrade includes the code that changed in the dependencies in the commit.
seems to be either a tool that isnt out yet or perhaps not available for free or the public.
Yes, but also impractical.
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
And exfiltration was needed to confirm a vulnerability why exactly?
I love how completely unaware you guys are.
Ethically, your work was even lower than that of those who test their AI tools on FOSS code, send in bogus reports and thus waste maintainer's time. Experimenting on unwitting humans and ecosystems is not okay.
I'm fairly concerned about the state of Python packages. It's not every week, but I frequently stumble upon packages that are not what they appear to be. Sometimes not maliciously, sometimes the author just got overly ambitious and failed to deliver, other times, someone is clearly typo-squatting or attempting to get you to install the wrong thing.
Several years ago I worked somewhere that prohibited web browsers and development tools on laptops. If you needed to use a browser, you’d have to use one over Citrix. If you needed to code, you’d use a VDI or run the tools in a VM.
At the time I thought their approach was clinically insane, but I’m slowly starting to appreciate it.
Unlike with Terraform/OpenBao, I know of no community effort effort to keep the open-source version of this project alive. The latest open source version is still available on the Ubuntu repo, but who knows who long it will work until somefor of bit rot occurs.
Except the vm is some old windows version without any tools on it. no shell access.
can't actually do anything useful on there at all.
VDI systems could work if implemented properly. but that's the last thing a security team actually wants to do.
A newer project fires up VMs from a Python script that calls an adapter for EC2 (with the boto library) when run on AWs and for VirtualBox (by calling VBoxManage) when running locally. That allows us to simulate EC2 locally: it's a project that has to deal with many long jobs so we start VMs for them and terminate the VMs when the jobs are done. That also runs better on our mix of development systems. WSL2 helped to ease the pains of developing on Windows. We call the native Windows VirtualBox, not the one we could have installed inside WSL2, but we keep most of the code that runs on Linux.
None of my jobs since have had any semblance of a better way to set up a local dev environment easily.
It was just way easier to encapsulate services or other things in a quickly reproducible state.
I digress..
Let’s be clear, it’s still clinically insane, even if marginally rationalized.
A hybrid(?) alternative is enroot, which is pretty neat IMO, it converts a docker container into a squashfs file that can be mounted rw or used in an ephemeral way. https://github.com/NVIDIA/enroot
nvidia gates it's virtualized GPU offerings behind their enterprise cards, so we're left with ineffective command translation.
IMO: I can tolerate just about every other type of VM overhead, but choppy/unresponsive GUIs have a surprisingly bad ergonomic effect (and somehow leak into the performance of everything else).
If we could get that fixed, at least amongst Linux-on-Linux virtualization, I think virtualizing everything would be a much more tenable option.
If you can't do that because it's for company/corporate purposes then I can sympathise with not wanting to pay Nvidia's prices.
Specifically I'm transitioning my Go and Zig development environments from an old mac to an M1 with Asahi Linux and getting a bit lost even finding replacements for Truecrypt and Little Snitch. Do these VM tools support encrypted VM's with firewall rules? I saw Vagrant mentioned here and that sounds like it might cover the network isolation, but what else would you suggest?
LXD, unlike Docker, doesn't play fast-and-loose with security. It runs rootless by default, and I don't allow non-root access to the LXD socket on host. Each container is a full userspace, so it's much more convenient to configure and use than Dockerfiles.
SSH from a container to a remote works transparently because I forward my SSH Agent. This is secure because my agent confirms each signing request with a GUI popup (on host).
These days I work in JavaScript and rarely have issues with project environments interfering with each other. I've gotten lazy and don't use VMs anymore.
In theory docker type setups could work but they just seem so much effort to learn and setup.
The VM might protect me, but it will not protect the users of the software I am producing. How can I ship a product to the customer and expect them to safely use it without protection when I myself only touch it when in a hazmat suit?
No, that is not the environment I want.
My current solution is to be super picky with my dependencies. More specifically I hold the opinion that we should neither trust projects nor companies but only people. This is not easy to do, but I do not see a better alternative as for now.
i've got a simple per-project dot file that describes the file system binds. while i'm working on a project, new terminals i open are automatically isolated to that project based on that dot file. it has very low (cognitive) overhead and integrates pretty much seamlessly. i suspect many developers have similar scripts. i looked for projects that did this some time ago, but couldn't find it. either because it's too simple to make a project about, or because i don't know how others would describe it. if anyone has pointers...
i don't limit network access (though i did experiment with logging all traffic, and automatically setting up a mitm proxy for all traffic; it wasn't convenient enough to use as regular user). there is still a whole kernel attack surface of course. though i'm mostly concerned about files being read/destroyed.
If you ran a key logger on my machine you would never get into any major site with mfa. You couldn't watch me log on to the azure console with passkey and do much with it. But if you scrape a saved key with publish abilities bad things happen.
I did not start doing this because of security, but just to get something more or less self managed without any possibility to break different projects. I am tired of my team spending too much time on extensions, versions, packages, ...
Docker compose files have saved our team many hours, even if it's extremely wasteful to have multiple vscode instances running alongside each other
For work use I use a work machine and if it gets compromised it's not really my own problem.
Is that really a good mindset for a organization?
It doesn't fully sort out the trust issue though, even if everything is sandboxed in some fashion.
Also, many people here work on multiple projects for different customers. Having a security breach for one affecting the other is not something you'd be happy with.
This would be where different security advice would apply: don't pull in a package that has 400 dependencies.
im not sure what has to change in UX to make these approaches more palatable, but if you have to frequently allow 'good' behaviors, my experience is it never takes off.
It's almost trite at this point to comment on the obsession that Node has created with developers to reduce functionality to the smallest possible reusable parts, even trivial things, and publish them as packages, then to import and use those dependencies. The idea, in and of itself, is not terrible, but it's been taken to a logical extreme which is very much the definition of terrible.
Going through that list... they all look like personal projects, with no dependents, and a single release by a single person.
Then because there is no standard library, many reinventions of similar but incompatible utilities. etc.
It's very much based on reality. The npm ecosystem is just absolutely fucked.
At my place of work we use this great security too called Snyk. Definitely check it out
/s
Completely backwards software that corpos only seem to buy because their insurers force them to check off some security list box.
edit: or microsoft outlook sucks… I tried to sort in reverse my inbox to see what's the oldest email there and "the request cannot be satisfied"
Codeberg looks interesting, and there are self-hosted ones like Forejo that also look great if you're okay with the maintenance.
It has CI, pull requests, issues and whatnot. It also doesn't force you to use 2fa if you don't want :D
If you do corporate open source though, you're stuck on github because snyk, openssf, pypi and whatnot only interface with github.
For actual libre software codeberg is very good.
Keep in mind that debian salsa is open to everyone as well. The only annoyance is that non debian developers have a "-guest" suffix. But it's ok to use for projects that aren't debian specific.
Well theres a sign of a good team.. /s
That's actually an interesting take, I haven't heard too much about them except that they do have an ego.
https://snyk.io/blog/snyk-security-labs-testing-update-curso...
Npm doesn't really do namespaces. There's just no ownership to prove as most packages are published like "call-home" with no namespace required. This gives exciting opportunities for you to register cal-home to trap users who miss type, or caII-home to innocuously add to your own or open source projects or whatever. Fun isn't it?
In this case the call home package is namespaced, but the real attack is the packages like "cursor-always-local" which has no namespace. Which can sometimes (?) take precedence over a private package with the same name.
It's not a pretty picture, you were better off missing it really.
Yes it really does. npm has namespaces (called scoped packages) and even explicitly encourages their use for private packages to avoid this sort of attack. From the npm docs: "A variant of this attack is when a public package is registered with the same name of a private package that an organization is using. We strongly encourage using scoped packages to ensure that a private package isn’t being substituted with one from the public registry." [1]
> This gives exciting opportunities for you to register cal-home to trap users who miss type, or caII-home to innocuously add to your own or open source projects or whatever. Fun isn't it?
npm actively blocks typo-squatting attacks during the publishing process: "Attackers may attempt to trick others into installing a malicious package by registering a package with a similar name to a popular package, in hopes that people will mistype or otherwise confuse the two. npm is able to detect typosquat attacks and block the publishing of these packages." [1]
This thread is full of people demonstrating the concept of confirmation bias.
The license change is irrelevant - from the licensing page:
> All non-production uses are permitted.
Devs who use Vagrant in a development environment can do it as they used to do it before.
> The latest open source version is still available on the Ubuntu repo, but who knows who long it will work until somefor of bit rot occurs.
Hashicorp products have always been intended to be downloaded from the website, since they're statically linked binaries (I don't like that they're huge, but matter of factually, they make distribution trivial).
There's also a thread for Zed about a path to implementing it there [0]. Hopefully it'll become a bit more common over 2025.
Works well with Homebrew, and copies all the config files that devs often don't set up.
> Using Remote-SSH opens a connection between your local machine and the remote. Only use Remote-SSH to connect to secure remote machines that you trust and that are owned by a party whom you trust. A compromised remote could use the VS Code Remote connection to execute code on your local machine.
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
If you're worried about extensions there's also:
> When a user installs an extension, VS Code automatically installs it to the correct location based on its kind. If an extension can run as either kind, VS Code will attempt to choose the optimal one for the situation;
https://code.visualstudio.com/api/advanced-topics/remote-ext...
On our laptops, there are still some flows that avoid the vpn etc..
Basically I put a Vagrantfile in src folder, then run docker compose with db, caddy, app server and other services inside it - then I forward ports 80 and 443 from vm and use localhost.whateverdomain.igot with self-signed cert on caddy (since https is just enough different than http that I otherwise get bitten by bugs every so often).
When I start a new project I can usually just copy the Vagrantfile with minimal changes.
It's not up to me to decide what policy to use, and if it was I couldn't just do whatever I wanted, I'd have to justify its cost. And every company does the same…
I can decide the policy at my home :)
All the stuff using Android intents, out-proc COM extensions in Windows, XPS in macOS, are other relevant set of examples.
I assume you are kind of new to the computing world, OS IPC is how we extended applications almost 40 years before shared libraries became common feature across all major operating systems.
Naturally with them being around, shared memory in-process was much easier, and less resource intensive. IPC calls require processes, which take more kernel resources, and context switch.
Microservices isn't a new concept, rather re-branding.
Sun had as marketing quote, "The network is the computer", exactly because of how it used to be.
... more than Gmail and Google
When I’m back on my computer I may look at the source and confirm my suspicion that none of those are required for the carousel functionality lol
You would `npm install` and then `git commit`. That's why npm didn't have a lock file back then. Git was the lock file.
another rather simple solution is a git mirror of each package, then point npm to a git url
In cases like that it helps to do npm install on the CI and make sure you end up with identical code. Decent trade-off.
Part of the appeals of VMs is that they were built with security as a primary objective. I probably have to do something stupid to break that isolation. A custom ad hoc configuration makes me a bit nervous that I will unknowingly punch a Docker sized hole through my firewall and have less security than if I ran a stock workflow.
If you go this route, create a container template that has everything you want in every instance. And then spin out new containers whenever you need one.
So before running any code you'd hash it and ask your peers: "what do we think this does?"
If it does something surprising, you roll back its effects (or maybe it was in a sandbox in the first place) and you update your peers so that next time they're not surprised.
I keep saying "you" but this would just be part of calling a function, handled by a tool and only surfaced to the user when they ask or when the surprising thing happens.
It could be a useful dataset both for maintainers and for people who want to better understand how to use the thing.
This is super powerful to implement exactly that, but for whatever reason IMO it's constantly been half-assed on the UI front, because the best version of it isn't "detailed policy confinements for system software" but detailed confinements for user data (which was the original idea that conceived it at the NSA - the data model ultimately looks a lot like how classified data works).
AFAIK the biggest problem is that you can't really do an ACL like configuration for it though - i.e. if I categorize all my SSH keys as type ssh_private_key_t, I'm not able to add an additional tag on that to grant targeted access to a specific program (which both does, and does not make sense - i.e. if I'm handing a program one private key but I think it might leak it...why am I doing that? Conversely in the real world we're bounding risk, so I should be able to do that - I don't think Multi-Category Security fixes this?).
Basically "empirical consensus" is an SELinux policy, in fact you can generate one that way - run in permissive mode for an application type, collect the actions as policy, publish for that specific hash...you know I'm honestly wondering if this is just something we need to start doing as an open source service?
Ideally this sort of thing would work just as well on bits for which there was no clear maintainer. Like if SETI turned up a signal which we can chmod +x and run, we could use it to crowd source an understanding of what it does.
A way to hash a file and ask:
> What is known about these bits?
If it's a popular program and yet none of your peers have seen that hash, maybe you should subject it to more scrutiny than if there's widespread consensus about it (it may have been tampered with).
How else am I to validate that your house is secure?
Then test the behaviour.
Of course not. We do the fun parts, and write tickets to make the dev team do the boring parts that we will later complain are not implemented to the quality standard we would have reached, had we done the work. That's the deal.
I literally just finished up writing up something that does supply chain provenance checking across 9 languages and still have a lot of edge cases to handle. It's not fun, but it's honest work.
Or you can exploit it and say here's the PoC, this many people at your company fell for it, and this is some of the valuable data I got, including some tokens you'll have to rotate. This puts you into actual bug bounty territory. Certainly the PR side of things alone will incentivize them to pay you so you don't make too much of a noise about how Cursor leaked a bunch of credentials due to a misconfiguration that surely every good programmer knows about and defends against (like so many vulnerabilities seem so dumb in hindsight).
The same incentive to show impact applies even without a paid bounty.
Shouldn't this alone be considered criminal negligence at this point? Cursor isn't some random open source project. It's a company that has funding, and subscriptions. Hell, I pay Cursor for a monthly subscription. Pretty incredible that they have no bounty program.
Kind of like a lot of exploit PoCs just "pop a calc" (AKA open the Calculator app), not because opening the calculator is valuable to an attacker, but because if you can open calculator, you can do anything.
Alternatively, you could hash it and say “Look, it’s a sha of your database password hyphen “yougotpwnd””
look we had access to your Aws tokens, we could take over your account but we didn't steal actual token, we just got proof that we could access it
I don't actually think that is a bad thing.
The TSA screening at airports would be vastly better if TSA maintained a "red team" that regularly tried smuggling guns (or water bottles or whatever) into airports. The agents would be more attentive if the number of incidents they dealt with was large enough that they could practice more often. The system could improve if it had actual feedback on how accurate and effective it was. And instead of agents overreacting or underreacting they could tune their responses to an appropriate level.
The same applies to supply chain attacks. The REAL ones are rare, dangerous, and performed by experts; having a chance to practice catching them, to assess our detection rates, and to adjust our reactions is healthy.
what they did was absolutely wrong and frankly likely illegal
Not when the dissidents put their name to paper.
We, veterans of Unit 8200, reserve soldiers both past and present, declare that we refuse to take part in actions against Palestinians and refuse to continue serving as tools in deepening the military control over the Occupied Territories.
It is commonly thought that the service in military intelligence is free of moral dilemmas and solely contributes to the reduction of violence and harm to innocent people. However, our military service has taught us that intelligence is an integral part of Israel's military occupation over the territories.
The Palestinian population under military rule is completely exposed to espionage and surveillance by Israeli intelligence. While there are severe limitations on the surveillance of Israeli citizens, the Palestinians are not afforded this protection.
There's no distinction between Palestinians who are, and are not, involved in violence. Information that is collected and stored harms innocent people. It is used for political persecution and to create divisions within Palestinian society by recruiting collaborators and driving parts of Palestinian society against itself. In many cases, intelligence prevents defendants from receiving a fair trial in military courts, as the evidence against them is not revealed.
Intelligence allows for the continued control over millions of people through thorough and intrusive supervision and invasion of most areas of life. This does not allow for people to lead normal lives, and fuels more violence further distancing us from the end of the conflict.
There weren't many Oskar Schindlers either.
It is not some conspiracy either, success as founder has strong network effects and positive feedback loops, right mentorship, access to talent pool, or access to funding and people who can open doors all becomes easier when your network already has some success. Similar reason second time founders have it easier they can tap into their personal version of a network.
It is not unusual to Israel/8200, the valley itself benefits from this effect heavily after all.
"Benefits" from whose perspective? For instance, the Brazilians (the State apparatus, specifically) are also benefiting [0], but are their citizens [1]?
[0] https://www.jstor.org/stable/48595312
[1] https://idanlandau-com.translate.goog/2016/02/04/technologie...
Who in turn benefits from that in terms wealth, power, influence is whole different topic for which i have no expertise, i was only talking about frequency of successes in startup clusters.
They actually do have this. TSA seem to still suck at their job:
https://www.forbes.com/sites/michaelgoldstein/2017/11/09/tsa...