Vulnerability in Popular macOS App Cursor Allows Malware to Bypass Privacy Protections, Exposing User Data

A critical security vulnerability has been discovered in Cursor, a popular AI-powered code editor for macOS, that enables malicious software to circumvent Apple’s built-in privacy protections and access sensitive user data without proper authorization.

The vulnerability exploits a misconfiguration in the application’s Electron framework, specifically the enabling of the RunAsNode fuse, which allows attackers to execute arbitrary code with the application’s existing privacy permissions.

The security flaw poses a significant threat to the Transparency, Consent, and Control (TCC) framework that Apple implemented to protect user privacy on macOS systems.

TCC serves as a crucial gatekeeper that controls application access to sensitive resources including files in protected directories like Documents, Downloads, and Desktop folders, as well as hardware components such as cameras and microphones.

TCC-protected directories (Source – Afine)

Under normal circumstances, applications must explicitly request user permission through system prompts before accessing these protected assets.

Afine security researchers identified this vulnerability during their ongoing research into TCC bypass techniques affecting third-party macOS applications.

The researchers noted that despite responsible disclosure to Cursor’s development team, the vulnerability remains unpatched as developers stated the issue “falls outside their threat model” and indicated no plans to address it.

This dismissive response has prompted the public disclosure to ensure users can make informed security decisions about continued use of the application.

The vulnerability’s impact extends beyond simple data access, as it effectively undermines one of macOS’s fundamental security barriers.

When malware successfully exploits this flaw, it can silently inherit Cursor’s TCC permissions, potentially accessing sensitive documents, capturing screenshots, recording audio through microphones, or even activating cameras without triggering the standard privacy consent mechanisms that users rely upon for protection.

The exploitation scenarios range from completely silent attacks requiring no user interaction to sophisticated social engineering attempts that disguise malicious permission requests as legitimate application functions.

What makes this vulnerability particularly concerning is Cursor’s growing popularity among developers and its integration with AI-powered development workflows, making it an attractive target for attackers seeking to compromise development environments and potentially inject malicious code into software projects.

Technical Exploitation Mechanism

The vulnerability stems from Cursor’s configuration as an Electron application with the RunAsNode fuse enabled, a setting that allows the application to be executed as a generic Node.js process.

Security analysis reveals that this configuration can be verified through the command npx @electron/fuses read --app "/Applications/Cursor.app/Contents/MacOS/Cursor", which shows “RunAsNode is Enabled” in the application’s fuse settings.

Attackers can exploit this misconfiguration by creating malicious Launch Agent configurations that leverage the ELECTRON_RUN_AS_NODE environment variable.

A typical exploitation involves planting a specially crafted plist file in the user’s ~/Library/LaunchAgents/ directory that executes arbitrary JavaScript code through Cursor’s binary.

For example, malware can use the following approach to access protected Documents folder: the Launch Agent executes /Applications/Cursor.app/Contents/MacOS/Cursor with the -e parameter followed by malicious JavaScript code such as require('child_process').execSync('ls -la $HOME/Documents > /tmp/Documents.txt 2>&1').

This technique effectively transforms Cursor into an unwitting proxy for malicious operations, as the system perceives these actions as originating from the legitimate application rather than external malware.

The exploitation can occur through two primary scenarios: a vanilla attack that requires no user interaction when Cursor already has necessary permissions, and a spoofing scenario that presents fraudulent permission requests appearing to originate from Cursor itself, thereby increasing the likelihood of user approval.

Posted in Cybersecurity