A vulnerability chain in Cursor AI could have allowed attackers to hijack developer machines via prompts hidden in malicious repositories, Straiker discovered.
Dubbed NomShub, the attack chain exploits an indirect prompt injection in coding agents and a command sandbox bypass to write code to the user’s machine and abuse Cursor’s remote tunnel feature to gain shell access.
According to Straiker, mounting an attack does not require any user interaction beyond opening a malicious repository in Cursor.
Furthermore, because the exploited feature is a legitimate binary signed and notarized, an attacker can exploit Cursor to gain full file system access and command execution capabilities on macOS systems, where the coding editor runs without sandbox restrictions.
Detecting the attack at the network level, Straiker says, is nearly impossible, as all the traffic goes through Microsoft Azure infrastructure.
The issue, the cybersecurity firm explains, was that Cursor’s protections against agent-executed shell commands did not cover those executed within the shell (shell builtins), leaving the parser blind to working directory changes, manipulated environment variables, and altered shell execution context.
Because the macOS seatbelt sandbox allows writes to the home directory, builtins could be used to escape the sandbox and overwrite the .zshenv file, which is executed by every new Zsh shell instance, including Terminal windows, application-spawned shells, invoking scripts, and the Cursor terminal.
An attacker could inject prompts in a repository’s README.md file and trick the user into opening the repository in Cursor. When the AI reads the README, it follows the injected instructions, executes the sandbox escape, and runs a tunnel exploitation script.
To abuse Cursor’s built-in tunnel and gain remote access to the victim’s system, the attacker also instructs the agent to generate a device code and send it to the attacker’s server. The code is necessary to authorize an authenticated GitHub session through the tunnel.
“The attacker’s GitHub account is now authorized to access the victim’s tunnel. Combined with the tunnel registration data (tunnel ID, cluster), the attacker can connect at any time,” Straiker says.
As long as the process remains running, the GitHub authorization is not revoked, and the tunnel registration is not deleted, the attacker has persistent access to the machine.
Straiker discovered the attack chain in January and reported it to Cursor in early February. A fix was included in Cursor 3.0.
Related: By Design’ Flaw in MCP Could Enable Widespread AI Supply Chain Attacks
Related: Can We Trust AI? No – But Eventually We Must
Related: Google DeepMind Researchers Map Web Attacks Against AI Agents
Related: Why Agentic AI Systems Need Better Governance – Lessons from OpenClaw
