A new VS Code exploit can rewrite AI agents across all code repositories, an application security specialist demonstrated Thursday.

On Wednesday, the SANS Technology Institute reported on new zero-click exploit that only requires developers open the folder in affected editors. The VS Code exploit involves a malicious tasks.json file that silently runs inside code editors. It was originally identified by Oasis, along with a recommended mitigation developers could apply.

Within 24 hours, Isaac Lewis showed how theexploit can be used to rewrite AI agents created within the AI-native code editor Cursor. In Cursor, the Oasis remediations disable the AI features, Lewis said when contacted via Bluesky.

Cursor is a fork of the open source VS Code and has been used by 31% of companies in the last year, according to an October survey conducted by Sonar.

Lewis warned, however, that the VS Code exploit could be used on other code editors.

“That got me thinking: Could I use this to reprogram a developer’s AI agents and get them to do what I want? Even worse — could I do this to all their code repositories?” he wrote. “Turns out: Hell yes.”

He added that while many developers are using AI tools to help write code, these code editors come with “a lot of new vulnerabilities.”

“If the tools are given malicious instructions, they could sabotage your code in subtle ways that are hard to detect,” he stated. “It is quite easy to get these genAI tools to exfiltrate sensitive developer information like keys, secrets, certificates, and passwords — so, if an attacker can manipulate the way your genAI tools behave, they can create a persistent threat in your codebase.”

The exploit creates the possibility of a “distributed persistent threat,” implanting itself in a developer’s codebase and then spreading to the codebases of all the developers on a team, according to Lewis.

In his proof-of-concept, which requires no user interaction, he changed the natural-language Cursor prompts to modify the AI agent’s behavior so that it could only speak Spanish. He was able to keep the cause invisible to the developer, he added.

“The first thing I wanted to write was the mechanism for finding .cursor folders. I limited myself to macOS to simplify things — I wanted something that was quick, quiet, and found folders that would already be given permission by the operating system so that Cursor wouldn’t suspiciously ask for new permissions,” he wrote.

He realized, though, that it would be quicker to look for .cursor directories in neighboring repositories to the one he was in. After finding the cursor folders, he added the full payload.

Then he hid the rule files from the developer.

“By telling it to run on folderOpen, this [malicious] task will run whenever Cursor navigates to this folder, regardless of where that folder is,” he wrote. “Then if we tell it to never reveal, it won’t give the developer any indication this task is running.”

In addition to his detailed blog about the exploit, he published a GitHub repository for the exploit.

Lewis told The New Stack via Bluesky that the only fix is to enable Workspace Trust and thoroughly reading the tasks.json file outside of VSCode and Cursor.

Lewis is a senior software developer and application security specialist at SIGN Fracture Care International, a humanitarian aid organization focusing on orthopedic trauma care. He contributes to OWASP Application Security Vulnerability Standard (ASVS) and has spoken at a number of conferences, including IntroSecCon.

For more on the security challenges created by coding with AI, check out The New Stack Senior Editor Darryl Taft’s article, “Vibe coding could cause catastrophic ‘explosions’ in 2026.”

Editor’s Note: Story updated at 8:40 a.m. to reflect that Oasis identified the exploit and to include comments from Lewis sent via Bluesky.

TRENDING STORIES