4 ms·
> The vulnerability was first identified by Mindgard on December 15, 2025. We reported it the same day and multiple times since. More than six months and 197+ n
by wxw 3mo ago
> The vulnerability was first identified by Mindgard on December 15, 2025. We reported it the same day and multiple times since. More than six months and 197+ new versions later, the issue remains present in the latest tested version of Cursor.
> The report was initially closed as Informative and out of scope. After we challenged that determination, HackerOne reopened the report, reproduced the issue, and confirmed that the details had been delivered to Cursor. And then everything stopped. Requests for updates went unanswered, additional follow-ups received no response, escalation through HackerOne produced no meaningful engagement, and direct outreach to Cursor leadership yielded the same result: no response.
Really unfortunate. I don't understand why there's such a lack of response on the Cursor side.
- sofixa 3mo ago> Really unfortunate. I don't understand why there's such a lack of response on the Cursor side. It's hard to vibe code security.
- koolba 3mo agoIs it though? Cause you can have an agent analyze the reports to filter out the wheat from the chaff.
- thayne 3mo agoI suspect that is exactly what cursor did, and the agent (incorrectly) categorized this as chaff.
- iainmerrick 3mo agoIdeally, they’ll be able to look back through the logs and find the original analysis from when the bug was submitted, figure out why it was incorrectly filtered, and use that to improve their automation. The general idea of a few layers of automated triage by increasingly powerful LLMs, before finally escalating to a human engineer, seems like a reasonable way to handle a deluge of submissions. It just has to be implemented well and continuously calibrated.
- petesergeant 3mo ago> It's hard to vibe code security. Conversely, running human or LLM-generated code through multiple LLMs to look for security holes is a fantastic way to increase security.
- buran77 3mo ago> I don't understand why there's such a lack of response on the Cursor side. Too busy being acquired by SpaceX?
- app13 3mo agoThe CVE process itself is broken. HackerOne and company VDPs are inundated with new reports of varying quality thanks to the advancements (I think) in agentic AI. It's allowed for both an increase in trash-tier low quality AND legitimately high quality reports. Since the same AI's are writing both, its almost impossible to distinguish between the two at a surface level. In response, companies just aren't responding like they used to. I spoke at a cybersecurity conference In June and the overwhelming "vibe" on the floor and in the talks was that responsible disclosure was dead or dying, and public disclosure is the way forward. The Microsoft and Nightmare Eclipse situation was oft cited.
- demosthanos 3mo agoAs someone on the company response side of the HackerOne brokenness, I can confirm that this effect is real but would also note that the difficulty of distinguishing is not as severe as all that, because the companies have access to the source code which the researchers do not typically have access to. This means that the token cost of verifying any given HackerOne report is dramatically lower than the token cost of producing a report in the first place. Automated triage systems should be possible, and realistically it's well within the capabilities of most companies to go further and actually automate the Red Team side of it and catch issues before they surface in the black box research. From what I've seen doing so should cost dramatically less in tokens than the bounty payouts do. The problem is that security is woefully underfunded in most companies, so even an infosec organization that saw the deluge approaching from a distance may well not have had the resources to prep for it even if they knew exactly what actions they would take if they had the capacity.
- deleted 3mo ago[deleted]
- QuadmasterXLII 3mo agoThe token cost of a report is lower bounded by the number of tokens in the report * price per token of the cheapest model. The token cost of a good report is much higher, but sifting out the good reports is the entire problem.
- _AzMoo 3mo agoIt screams intentional to me.
- deleted 3mo ago[deleted]
- khurs 3mo agoPerhaps its a intentional back door? NSA/FBI puts a git.exe in GitHub for a target. Target pulls the repo and it executes the payload. As Cursor is/was based on VS Code, does it happen in VS Code too?
- oceansweep 3mo agoIt’s a thing in VSCode as well/has been a thing or things similar to it : https://www.threatlocker.com/blog/malicious-vs-code-tasks-json-abuse-enables-multi-stage-infostealer-deployment https://www.threatlocker.com/blog/malicious-vs-code-tasks-js... (2026) https://www.reddit.com/r/programming/comments/zes1co/visual_studio_code_remote_code_execution_advisory/ https://www.reddit.com/r/programming/comments/zes1co/visual_... (2022)
- ivirshup 3mo agoI think those are both different in that they require the user to say they trust this code. Additionally the first is arguably not a bug (the code in tasks.json will indeed run if you say you trust the project) and the second was reported and fixed within two months.
- oceansweep 3mo agoYes, my point was more so the underlying behavior of automatic execution of binaries associated with/inside of a git project exists already within vscode as a pattern, and so seeing cursor doing the same wouldn't be surprising.
- solid_fuel 3mo ago[flagged]
- manacit 3mo ago...that's Anthropic?