What Happened
In December 2024, security researchers disclosed a vulnerability in Cursor, an AI-powered code editor, that allows automatic execution of malicious code when a developer opens a compromised repository. The flaw remains unpatched. When you clone a compromised repo and open it in Cursor, the IDE's AI features can trigger embedded malicious code without any user interaction beyond opening the project.
This is not a theoretical attack. The vulnerability was reported through proper channels and ignored. Any developer using Cursor to review unfamiliar code, clone a suspicious repository, or open a project from a contractor is now exposed.
Timeline
December 2024: Researchers report the auto-execution vulnerability to Cursor through their security disclosure process.
December 2024 - Present: Cursor does not patch the vulnerability or acknowledge the report publicly. The flaw remains exploitable in production versions of the IDE.
Current Status: The vulnerability is now public knowledge while remaining unpatched, creating a window where attackers know the exploit exists and users remain vulnerable.
Which Controls Failed
Vulnerability Management Process: Cursor failed to triage and respond to a reported security flaw affecting their core product. This represents a breakdown of vulnerability intake and response.
Secure Development Lifecycle: The vulnerability exists because Cursor's AI features interact with repository contents in ways that can trigger code execution. This suggests inadequate threat modeling during feature development.
User Protection Mechanisms: The IDE lacks controls to prevent automatic code execution when opening untrusted repositories. There's no sandbox, no permission prompt, and no warning that AI features might execute project code.
Security Communication: Even after the disclosure period elapsed, Cursor has not warned users about the risk or provided workarounds. Your security team has no official guidance to share with developers.
What Standards Require
ISO/IEC 27001:2022 Control 5.22 requires you to monitor security in supplier relationships. When your development toolchain includes a vendor that ignores vulnerability reports, you're failing this control. You need a process to evaluate whether Cursor remains acceptable for your risk profile.
NIST 800-53 Rev 5 Control SI-2 applies to your entire technology stack, including development tools. The control requires you to install security-relevant software updates within organization-defined time periods. When a vendor won't patch, you must either accept the risk formally or find an alternative tool.
PCI DSS v4.0.1 Requirement 6.3.2 states that security vulnerabilities are identified using industry-recognized sources and new threats are assigned a risk ranking. If you're building payment applications in Cursor, you need to document this vulnerability, assess its risk to cardholder data, and justify continued use or plan migration.
OWASP ASVS v4.0.3 Section V14.2 requires verification that all components are free from known vulnerabilities. Your IDE is a component in your development environment. You can't verify Cursor is free from known vulnerabilities because the vendor acknowledges none while researchers report them.
SOC 2 Type II CC7.1 requires you to detect and respond to security incidents. When a tool in your development pipeline has a known vulnerability that enables code execution, that's an incident requiring response. Your response can't be "wait for the vendor" indefinitely.
Lessons and Action Items
Assess your exposure immediately. Survey which teams use Cursor and for what purposes. Developers reviewing external code, auditing open source projects, or working with contractor-submitted repositories face the highest risk. You need to know the scope before you can manage it.
Implement repository review controls. Until Cursor patches this or you migrate away, treat every repository opened in Cursor as potentially hostile. Create a review process: clone repos to an isolated VM, scan for suspicious files before opening in Cursor, or switch to a different editor for untrusted code review. This is temporary friction that prevents persistent compromise.
Document the vendor failure. Write up this incident for your vendor risk register. Note the disclosure date, the lack of response, and your temporary mitigations. When auditors ask about your vendor management process, you need evidence that you tracked this issue and made a conscious decision about continued use.
Establish vendor response SLAs. This incident reveals a gap in your vendor management: you probably don't have defined expectations for how quickly security vendors should respond to vulnerability reports. Add this to your vendor contracts. Require acknowledgment within 5 business days and a fix or public advisory within 90 days for high-severity issues.
Review your AI tool inventory. Cursor isn't the only AI coding assistant in your environment. GitHub Copilot, Tabnine, Amazon CodeWhisperer, and others all have access to your code and execution context. Map which AI tools your developers use, what permissions they have, and what your plan is if one of them has a similar vulnerability.
Test your incident communication. When this vulnerability became public, did your security team hear about it before your developers? Do you have a process to push urgent security updates about development tools to engineering teams? If not, create one. Your developers need to hear "stop using Cursor for external code review" from you, not from social media.
Plan for vendor non-response. You need a decision tree: if a critical vendor doesn't patch a reported vulnerability within X days, what's your escalation path? Do you disable the tool? Do you accept the risk formally? Do you migrate to an alternative? Make this decision now, in policy form, so you're not scrambling next time a vendor goes silent.
The Cursor vulnerability remains unpatched because the vendor chose not to act. Your job isn't to wait for them to change their mind. Your job is to protect your development environment despite vendor failures. That means knowing your exposure, implementing temporary controls, and having a plan for when vendors don't hold up their end of the security relationship.
