AI helpers now execute commands for you—and for attackers
AI coding assistant vulnerabilities are security flaws in tools that help write or understand code, where their growing ability to read project configuration, execute terminal commands, and connect to external services can be abused by attackers to run arbitrary code, steal credentials, or escape sandboxes without any explicit approval from the developer. Today’s AI coding assistants no longer suggest code in isolation; they spin up tools, query APIs, and run commands on your laptop. That convenience now comes with a sharp edge: the same features that automate builds and migrations can silently turn a cloned project or harmless-looking prompt into a command execution exploit. In short, your editor is becoming a programmable remote shell—and every repo and context source it touches becomes potential attacker input.
Amazon Q: From git clone to cloud compromise
The Amazon Q Developer flaw shows how thin the line is between convenience and compromise. A high-severity bug, tracked as CVE-2026-12957 (CVSS 8.5), let a malicious repository run commands and steal a developer’s cloud credentials. The issue sat in how Q handled Model Context Protocol (MCP) servers: it automatically read .amazonq/mcp.json from the workspace and launched whatever processes the file defined, with no prompt or consent. Those processes inherited the developer’s full environment, including AWS keys and other secrets. Put together, a single config file dropped in a repo was enough to go from git clone to cloud compromise.
Opening the wrong Git repository could allow an attacker to execute code on a developer’s machine and potentially hand them the keys to the cloud environment. This was not limited to one editor: the flaw lived in Language Servers for AWS, which powers Amazon Q across VS Code, JetBrains, Eclipse, and Visual Studio, and all four plugins were exposed when they bundled vulnerable versions. Amazon has patched the issue; it is fixed in Language Servers for AWS 1.65.0, and customers are told to move to 1.69.0. Minimum safe plugin versions are VS Code 2.20, JetBrains 4.3, Eclipse 2.7.4, and Visual Studio toolkit 1.94.0.0 or later.
Cursor’s DuneSlide: prompt injection as a zero-click shell
Cursor’s DuneSlide bugs prove that even sandboxes are brittle when automation is wired to untrusted input. Two flaws in Cursor, tracked as CVE-2026-50548 and CVE-2026-50549, could let a single ordinary-looking prompt break out of the editor’s safety sandbox and run any command on a developer’s computer. Both scored 9.8 out of 10 (9.3 under CVSS 4.0). The entry point was prompt injection: attackers never type into your editor; they hide instructions in MCP-connected services or web pages your agent reads for you. You ask a normal question, the hidden instructions ride along, and the attack needs no click or approval—zero-click.
Both vulnerabilities abused how Cursor’s sandbox allowed writes. In one case, the agent used the working_directory parameter of run_terminal_cmd to point at sensitive paths, overwriting the sandbox helper or startup files. In the other, it abused a shortcut (symlink) check so that failures caused Cursor to trust an in-project path that actually pointed outside the project. Once the sandbox is neutralized, the next command runs as the developer, granting control of the machine and any signed-in cloud or SaaS workspaces. Both bugs are patched in Cursor 3.0, released April 2, and every version before 3.0 is affected; more than half the Fortune 500 use Cursor, so if you run it, update now.
This is an ecosystem problem, not a one-off bug
Treating Amazon Q and Cursor as isolated mistakes misses the point. Security researchers argue the bug in Amazon Q is less an Amazon problem than an industry one: more and more AI coding assistants are adopting MCP to connect models to local tools and services, allowing them to execute commands on developers’ machines. The convenience of letting a project folder configure an AI agent is also the attack surface: repo-carried config is untrusted input, and turning it into a running process should require an explicit yes. Amazon Q is not the first assistant to trip over MCP trust; Claude Code (CVE-2025-59536) and Cursor (CVE-2025-54136) also had project-level MCP config that led to command execution.
The pattern is repeating elsewhere. Malicious Git repositories can be weaponized so that opening them in vulnerable AI tools runs arbitrary code with live cloud sessions attached. Cato’s research on DuneSlide states it is disclosing similar flaws in other coding agents and argues the problem is structural rather than a string of one-offs. In other words, whenever an AI agent auto-runs commands based on project configuration or unvetted context, you should assume there is an attack path from malicious repository attack to full compromise. As long as assistants are treated as trusted automation instead of untrusted code execution layers, this class of AI coding assistant vulnerabilities will keep surfacing.
What developers must do now: patch, verify, and distrust configs
Developers can no longer afford to treat AI assistants as harmless IDE plugins. First, update aggressively. CVE-2026-12957 is fixed in Language Servers for AWS 1.65.0, but users are told to move to 1.69.0. Ensure you are on at least Amazon Q’s safe plugin baselines—VS Code 2.20, JetBrains 4.3, Eclipse 2.7.4, Visual Studio toolkit 1.94.0.0 or later—and confirm the language server has auto-updated. For Cursor, anything before 3.0 is unsafe; both DuneSlide bugs are patched in Cursor 3.0, and if you run it, you should update now.
Second, audit your projects like an attacker would. Repo-carried config is untrusted input. Search for directories such as .amazonq and other assistant-specific folders, MCP definitions, and hidden config files that can spin up servers or adjust sandbox settings. Treat unknown configs in cloned repos as potential command execution exploit carriers, not convenience files. Finally, change collaboration habits: do not auto-trust workspaces, and be suspicious when AI agents propose actions based on content pulled from MCP services or the web, since that is a live prompt injection sandbox escape vector. The conclusion is uncomfortable but clear: if you do not actively manage how your AI tools execute commands, attackers will.
