Amazon Q executed code from any repo you opened, and it is not the only one

Wiz Research has disclosed a high-severity vulnerability in the Amazon Q Developer extension for Visual Studio Code that allowed arbitrary code execution and cloud credential theft simply because a developer opened a malicious repository ^[1]. Amazon has remediated it in language server version 1.65.0 ^[2], but Wiz frames the finding as part of a broader pattern across AI coding tools, with OX Security and Check Point publishing similar findings around the same time ^[3].

The mechanism is unglamorous, which is the point. According to Wiz, the extension loaded `.amazonq/mcp.json` from the workspace root immediately on opening the folder, with no approval dialog and no workspace trust check ^[4]. The second half of the problem is that the processes it spawned inherited the user's complete environment ^[5]. The Model Context Protocol exists precisely so assistants can spawn local processes and reach external services ^[6], and its security model assumes the user configured those servers on purpose ^[7]. A file that arrives with a `git clone` is not that.

Wiz's proof of concept is four steps: the victim clones a repository, perhaps a typosquatted package or a malicious pull request, opens the folder in VS Code with Amazon Q installed, activates Amazon Q, and the extension loads and executes the attacker's MCP configuration without prompting ^[8]. In testing, `aws sts get-caller-identity` captured the developer's active AWS session, escalating local execution into cloud compromise ^[9]. The only human actions required were opening the folder and activating the assistant ^[10].

The underlying issue is a trust boundary that developers have been trained to ignore. Wiz notes that opening a project folder already means implicitly trusting dozens of configuration files, including `package.json`, `.vscode/settings.json` and `.eslintrc`, most of which are declarative and do not execute code themselves ^[11]. Extensions blur that line when they read workspace-specific configs and act on them automatically ^[12]. Malicious config then runs before the developer has reviewed a single line of code ^[13].

Treat this as an audit task rather than a patch. Confirm the Amazon Q language server version deployed on developer machines is at or above the remediated 1.65.0 ^[2]; extension version numbers are not the same thing as the language server version that carries the fix. Then enumerate, for every AI assistant your engineers have installed, which per-repository paths it reads and whether any of them can start a process. The dangerous property is not MCP itself but the combination Wiz identified: repo-supplied configuration plus automatic startup plus inherited environment ^[1][5]. Any one of those alone is survivable.

Two things worth watching. First, whether vendors move MCP server startup behind VS Code's workspace trust model, since Wiz specifically records the absence of a trust check as one of the two root causes ^[4]. Second, whether assistants stop passing the full parent environment to spawned servers, because as long as they do, every credential in a developer's shell is in scope for anything the repo can start ^[5]. Given that three separate research teams landed on the same class of defect at roughly the same time ^[3], the remaining question is how many shipped assistants have not yet been looked at.