Cursor vulnerability enables stealthy RCE via indirect prompt injection

A vulnerability in the AI-powered Cursor integrated development environment (IDE) could have enabled an attacker to conduct stealthy remote code execution (RCE) attacks via indirect prompt injection, Pillar Security reported Wednesday.

The flaw, tracked as CVE-2026-22708, arose from implicit trust in certain shell built-ins including “export” and “typeset,” which would allow them to be executed without any notification of or approval from the user, even when the user’s allowlist was empty.

Pillar Security researchers found that an attacker could leverage these built-in commands in instructions from an indirect prompt injection to secretly execute malicious commands through syntax manipulation or by poisoning the shell execution environment Cursor operates in, leading to RCE in both “zero-click” and “one-click” scenarios.

For example, an attacker could chain (using &&) the redirection of an arbitrary here-string (<<<’…’) to the zsh shell startup script (>>~/.zshrc) with the execution of the “export” shell built-in command, which requires no user notification or approval to execute.

Related reading:

Malicious commands appended to .zshrc using this method are not sanitized nor directly executed by Cursor, due to initially being written as strings, but are ultimately executed at the start of every new shell session. The only user interactions required for this attack are the initial prompt that triggers the indirect prompt injection and the initiation of a new shell session to trigger execution.

In another proof-of-concept (PoC), Pillar Security researchers present how an attacker could abuse the zsh parameter expansion flag (e) to execute malicious commands during a parameter expansion while running the built-in “typeset” command.

By including the operator “:-“ to substitute a default value if the parameter is empty, intentionally leaving the parameter empty and then setting a malicious command as the default value, the malicious command can be executed via the expansion flag (e).

Cursor does not notify the user for approval in this scenario because the malicious command is initially supplied as a string and its execution occurs entirely within the shell’s expansion phase.

An additional PoC that requires more user interaction uses the export command to set a malicious command as the PAGER environment variable. Two commonly used commands, “git” and “man,” rely on the PAGER variable to determine how to display input, Pillar Security explains. Therefore, after the PAGER variable is quietly poisoned using the trusted export command, any future execution of git or man will trigger RCE.

While this requires the user to approve the use of the git or man commands, the user will be unaware of the poisoned variable when doing so; additionally, many users are likely to have allowlisted such commands due to their common use, Pillar Security noted.

Cursor released a fix for CVE-2026-22708 this month and now requires explicit user approval for any commands the server-side parser cannot classify. Additionally, Cursor’s security guidelines now discourage reliance on allowlists as a security barrier, as even trusted commands can be susceptible to environmental or syntax manipulation.

While Pillar Security notes that this fix addresses their specific PoC attacks, they emphasize the importance of isolation and sandboxing of command execution by AI coding agents. They recommend sandboxing environment variable modifications in addition to direct command executions and say users should consider isolating environment variables between agent sessions as well.

They note that environment variable manipulation attacks like those described by security researcher Luke Jahnke in his 2020 blog “Hacking with Environment Variables” are now more relevant with the dawn of AI coding agents, whereas such attacks would have previously required direct access to the victim’s machine and manual execution of each step.