When it comes to “vibe coding,” automation is king. Tools like Cursor (an AI-based code editor rapidly gaining popularity among developers) promise faster workflows, smarter completions, and agentic autonomy with minimal human oversight.
But speed comes with risk.
Cursor’s flagship feature, auto-run, is designed to let its AI agents act on your behalf, reading, writing, and executing commands without your intervention. To keep things “safe,” it uses a denylist: you list dangerous commands, and the agent won’t run them unless you explicitly allow it.
In theory, this should stop rogue commands in their tracks. In practice, it doesn’t.
A False Sense of Control
When Backslash Research began testing Cursor’s denylist, they expected constraints to hold up under scrutiny. They didn’t. What appeared to be a reasonable safeguard turned out to be a sieve.
“We found no fewer than four ways for a compromised agent to bypass the Cursor denylist and execute unauthorized commands,” they said.
The Cursor team acknowledged the issues and confirmed that the denylist will be officially deprecated in version 1.3. But that doesn’t undo the implications for current users.
Let’s walk through what went wrong.
Method 1: Obfuscation
The simplest way to get around Cursor’s denylist? Hide the command.
Obfuscation techniques like Base64 encoding allow malicious commands to slip past string-matching filters undetected. Even with curl explicitly denied, a Base64-encoded curl google.com executed without hesitation.
Method 2: Subshells
Commands wrapped in subshell syntax (like $(…) or backticks) bypass the denylist entirely. Cursor doesn’t parse the subshell contents; it just executes them.
Method 3: Scripts
Cursor also fails to block commands when they’re embedded in shell scripts. That means an agent can write a forbidden command to a file, mark it executable, and run it, without setting off any alarms.
“Whether you understand this exception as a feature or a bug it has undesirable consequences. An AI agent could write any blocked command to a new executable file, and then simply execute it, bypassing the denylist,” they added.
The Blame Game
When researchers Mustafa Naamneh and Micah Gold flagged these issues, Cursor’s initial response was to push responsibility back onto the user.
“Cursor, for their part, made this very argument when we first reported our results. If the user had just taken more care to disable bash,zsh and other shells, obfuscation and subshell bypasses would be impossible. If the user had disabled chmod, executing unauthorized scripts would be more difficult. If the user had reviewed the denylist carefully and spent the requisite hours typing up their commands they had nothing to worry about.”
That argument doesn’t hold up.
“Cursor’s design gives users a false sense of security. The platform encourages users to rely on denylist-based controls, then blames them when those controls inevitably fail.”
Security design shouldn’t hinge on superhuman vigilance.
“Blaming the user for not constructing a perfect denylist is like blaming someone for forgetting to lock one of 500 doors in a building advertised as ‘secure by default.’ The problem isn’t their vigilance. It’s the design of the building.”
Method 4: The Quoting Catastrophe
The final method exposes the flaw at its core.
Thanks to how Bash interprets double quotes, malefactors can reconstruct forbidden commands character by character, like so:
CopyEdit
“e”cho bypassed
“”e””cho bypassed
“””e”””cho bypassed
And on and on.
“With a little inductive reasoning we can derive the following theorem,” the researchers explained.
“For every command in a Cursor denylist, there are infinite commands not present in the denylist which, when executed, have the same behavior.”
This single insight destroys the premise of denylist security in Cursor’s current implementation.
Real-World Consequences
Consider a simple, plausible scenario:
A developer downloads a Cursor rules.mdc file from GitHub without reviewing its contents. Hidden within is a Base64-encoded script. The moment auto-run kicks in, it:
- Installs malware or a backdoor
- Exfiltrates SSH keys
- Bypasses file protections and deletes sensitive data
“The ability to execute arbitrary commands also renders Cursor’s other safety settings to defend auto-run (including external-final protection, file-deletion prevention, and dot-file protection) worthless.”
Recommendations
Until Cursor deprecates the denylist in its next release, users should:
- Disable auto-run where possible
- Switch to allowlist mode, which restricts execution to explicitly permitted commands
- Use external security tools, like Backslash Security’s extension, to detect hidden payloads and block prompt injection
“This, of course, is just one additional guardrail layer – necessary but not sufficient to secure your AI coding agent,” they said.
Cursor is moving fast, and that’s both its power and its problem. As agentic AI becomes more capable, its threat surface grows in tandem. Tools built for speed and autonomy must meet a higher standard of security, particularly when they can execute shell commands on your machine.
The Bigger Picture
Cursor is far from the only platform rushing to ship agentic features. But its denylist fiasco is a warning to the entire AI development ecosystem: Don’t confuse constraints with control.
“In the ever-accelerating rush to enable vibe coding, mistakes will be made. The onus is on end-user organizations to ensure agentic systems are equipped with proper guardrails,” the researchers said.
Security cannot be an afterthought. Guardrails need to be grounded in how systems actually behave, not how we hope they do.
Information Security Buzz News Editor
Kirsten Doyle has been in the technology journalism and editing space for nearly 24 years, during which time she has developed a great love for all aspects of technology, as well as words themselves. Her experience spans B2B tech, with a lot of focus on cybersecurity, cloud, enterprise, digital transformation, and data centre. Her specialties are in news, thought leadership, features, white papers, and PR writing, and she is an experienced editor for both print and online publications.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.