What Is NomShub?
Security firm Straiker has uncovered a multi-stage vulnerability chain in the Cursor AI coding editor that could allow threat actors to seize complete control of a developer's machine. The attack, named NomShub, combines an indirect prompt injection targeting coding agents with a command sandbox bypass. Together, these weaknesses enable an attacker to write arbitrary code to a victim's filesystem and abuse Cursor's own remote tunnel feature to obtain persistent shell access — all without requiring any user interaction beyond the act of opening a malicious repository inside the editor.
How the Attack Chain Works
The NomShub chain begins with a specially crafted repository whose README.md file contains hidden instructions aimed at Cursor's AI agent. When a developer opens the repository, the AI reads the README and, following the injected prompts, quietly carries out a series of malicious actions on the developer's behalf.
Sandbox Escape via Shell Builtins
At the heart of the exploit is a gap in how Cursor's protections handle shell commands. According to Straiker, Cursor's defenses against agent-executed shell commands did not account for commands executed within the shell itself — so-called shell builtins. This blind spot left the parser unable to detect working directory changes, manipulated environment variables, and altered shell execution contexts.
On macOS, the platform's seatbelt sandbox permits writes to a user's home directory. By exploiting shell builtins, an attacker can escape the sandbox and overwrite the .zshenv file — a configuration file executed by every new Zsh shell instance. This includes Terminal windows, application-spawned shells, scripts that invoke the shell, and the Cursor terminal itself. Once .zshenv is poisoned, the attacker's payload runs automatically in any subsequent shell session.
Abusing Cursor's Remote Tunnel
After escaping the sandbox, the injected instructions direct the AI agent to execute a tunnel exploitation script. Cursor includes a built-in remote tunnel feature based on a legitimate binary that is both signed and notarized — meaning it carries an air of authenticity that makes it difficult to flag as malicious.
To gain authenticated access through the tunnel, the agent is instructed to generate a device code and transmit it to the attacker's server. That code authorizes a GitHub session through the tunnel on behalf of the victim. As Straiker explains:
"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."
The result is persistent, remote access to the compromised machine. The attacker retains this foothold as long as the tunnel process continues running, the GitHub authorization remains active, and the tunnel registration has not been deleted.
Why Detection Is So Difficult
Straiker notes that detecting the NomShub attack at the network level is nearly impossible. All traffic generated by the tunnel passes through Microsoft Azure infrastructure, blending in with legitimate cloud communications. Combined with the fact that Cursor runs without sandbox restrictions on macOS and the abused binary is legitimately signed and notarized, the attack presents a remarkably low forensic footprint.
The consequences for a successfully compromised system are severe:
- Full filesystem read and write access
- Arbitrary command execution on macOS
- Persistent remote access via a legitimate, signed binary
- Network traffic indistinguishable from normal Azure usage
Scope and Affected Platforms
The attack is particularly impactful on macOS, where Cursor operates outside a sandbox environment. The use of a signed and notarized binary means security tools relying on code-signing checks would not raise an alert. Developers working with public or third-party repositories face the greatest risk, as simply opening a weaponized project is sufficient to trigger the chain.
Discovery, Disclosure, and Patch
Straiker discovered the NomShub attack chain in January and reported the findings to the Cursor team in early February. Cursor addressed the vulnerability chain in Cursor 3.0. Developers still running earlier versions of the editor are strongly encouraged to update immediately.
Broader Implications for AI-Assisted Development
The NomShub chain highlights a growing class of threats that specifically target the intersection of AI agents and development tooling. Indirect prompt injection — where malicious instructions are embedded in content the AI is expected to read, rather than delivered directly by a user — is an emerging attack vector that existing security models were not designed to handle.
As AI coding assistants become more capable and more deeply integrated into developer workflows, their ability to take autonomous actions — executing commands, reading files, making network requests — also enlarges the attack surface available to adversaries. The NomShub case demonstrates that a single poisoned repository, combined with the right sequence of exploits, can translate into full system compromise with no suspicious user behavior required.
Security teams supporting development environments should audit which AI-powered tools operate with elevated or unsandboxed privileges, review policies around the opening of untrusted repositories, and monitor for unexpected tunnel registrations or outbound connections to cloud infrastructure.
Source: SecurityWeek