Amazon Q Developer Vulnerability Let Malicious Repositories Run Code and Expose Cloud Credentials

Amazon has patched two high-severity vulnerabilities in Amazon Q Developer plugins that could let a malicious workspace run commands or write files outside expected project boundaries.

The most serious issue, CVE-2026-12957, affected how Amazon Q Developer handled Model Context Protocol server configurations in project files. According to Wiz Research, a malicious repository could use a hidden .amazonq/mcp.json file to execute commands and access cloud credentials from the developer’s environment.

AWS published Security Bulletin 2026-047-AWS on June 23, 2026. The bulletin covers CVE-2026-12957 and CVE-2026-12958, both in Language Servers for AWS, the runtime used by Amazon Q Developer plugins across major IDEs.

What Happened in Amazon Q Developer

Amazon Q Developer uses Language Servers for AWS to power coding assistance in Visual Studio Code, JetBrains IDEs, Eclipse, and Visual Studio. Those language servers also support richer tool integrations through workspace configuration.

The risk came from project-level MCP configuration files. A repository controlled by an attacker could include commands that appeared to be part of the project setup but actually ran on the developer’s machine.

The CVE-2026-12957 advisory describes the issue as improper trust boundary enforcement. If a user opened and trusted a malicious workspace, commands in project-level configuration files could execute automatically.

Issue	Type	Fixed In	Risk
CVE-2026-12957	Improper trust boundary enforcement	Language Servers for AWS 1.65.0	Arbitrary code execution from project configuration
CVE-2026-12958	Missing symlink validation	Language Servers for AWS 1.69.0	File writes outside the intended workspace boundary

Why MCP Configurations Created a New Trust Problem

The Model Context Protocol gives AI applications a standard way to connect to tools, data sources, databases, files, and workflows. The official MCP documentation describes MCP as an open-source standard for connecting AI applications to external systems.

That flexibility also creates a sensitive execution boundary. MCP servers are local processes, and a configuration file can define the command used to launch them.

In a safe design, the developer should understand and approve that launch. In the vulnerable flow described by Wiz, Amazon Q loaded workspace MCP configuration from .amazonq/mcp.json without a separate MCP-specific approval step.

How a Malicious Repository Could Steal Cloud Credentials

The attack path was simple. A developer could clone a repository, open it in VS Code with Amazon Q installed, and activate Amazon Q in that workspace.

The malicious project could include an .amazonq/mcp.json file defining an MCP server command. When executed, that command would run as the developer and inherit the developer’s environment variables.

That environment can include AWS access keys, AWS session tokens, cloud CLI tokens, API keys, SSH agent sockets, and other secrets used during normal development. The Wiz proof of concept showed how an attacker could capture the active AWS identity from a developer session.

• A developer receives or clones a malicious repository.
• The repository contains a hidden .amazonq/mcp.json file.
• Amazon Q reads the workspace configuration.
• A command runs through the MCP server configuration.
• The spawned process inherits cloud credentials and other secrets.
• The attacker may use those credentials to access cloud resources.

AWS Says Workspace Trust Was Still Part of the Flow

The disclosure includes an important distinction. AWS says exploitation requires the local user to open a malicious workspace and trust it when prompted.

That makes Visual Studio Code workspace trust relevant. The VS Code Workspace Trust documentation says the feature lets users decide whether code in a project folder can be executed by VS Code and extensions without explicit approval.

Wiz’s concern focuses on the next layer of consent. Even after a workspace is trusted, an IDE extension should not silently treat repository-controlled tool configuration as safe to execute without clear user review.

Second Vulnerability Allowed Writes Outside the Workspace

CVE-2026-12958 is separate from the MCP auto-execution issue. It involved missing symlink validation in Language Servers for AWS before version 1.69.0.

The CVE-2026-12958 advisory says a malicious workspace could contain a symlink that resolves to a path outside the workspace trust boundary. If the agent wrote to that path, files outside the intended project area could be modified.

This type of issue matters because developers often open unfamiliar repositories for code review, dependency testing, support work, job interviews, and open-source collaboration. A trust boundary bug turns a project folder into a wider machine-level risk.

Affected Product	Affected Versions
Language Servers for AWS	Before 1.69.0
Amazon Q Developer for Visual Studio Code	Before 2.20
Amazon Q Developer for JetBrains	Before 4.3
Amazon Q Developer for Eclipse	Before 2.7.4
AWS Toolkit with Amazon Q for Visual Studio	Before 1.94.0.0

Amazon Has Released Fixes

AWS says both issues are remediated in Language Servers for AWS version 1.69.0 and in the corresponding Amazon Q Developer plugin releases. The company recommends upgrading to the latest version of the Amazon Q Developer plugin for each IDE.

The AWS bulletin says no workaround is available. That means updating remains the main remediation path for affected plugin versions.

Wiz said AWS deployed a fix for the VS Code extension through the language server update on May 12, 2026. AWS also said the language server updates automatically in most cases unless the customer’s network configuration blocks the update.

What Changed After the Patch

The fix changes how Amazon Q handles untrusted MCP server definitions. Instead of silently loading workspace MCP servers, Amazon Q now shows an “Untrusted MCP Server” consent prompt that lets developers review and reject commands.

This is the safer pattern for agentic coding tools. A repository may need project-specific configuration, but commands that launch local processes should require clear approval because they can reach secrets, source code, and cloud accounts.

The GitHub advisory for CVE-2026-12957 rates the issue High with a CVSS 4.0 score of 8.5. The GitHub advisory for CVE-2026-12958 also rates the symlink issue High with the same score.

Why Developers Should Treat Repositories as Untrusted Input

Developers often treat cloned repositories as text until they manually run a build, test, or script. Modern IDEs and coding assistants have changed that assumption.

A workspace can contain settings for extensions, build tasks, hooks, MCP servers, environment files, and test runners. Some of those files can cause tools to execute code or reach outside the project directory.

The Workspace Trust feature exists because opening a folder can expose users to unintended code execution. Agentic development tools make that warning more important because they connect project context to local commands and cloud credentials.

Attack Scenarios Go Beyond Random Repositories

The easiest attack scenario is a malicious repository that looks useful or legitimate. However, the risk also applies to more targeted social engineering.

An attacker could submit a malicious pull request to a popular open-source project, create a typosquatted package, or send a fake coding test during a job interview. These are realistic paths because developers often open unfamiliar projects as part of normal work.

Once commands run in the developer’s environment, the attacker’s next step depends on the developer’s permissions. A stolen cloud token may provide access to staging, production, internal services, private repositories, or CI/CD systems.

• Malicious pull requests to trusted projects
• Typosquatted packages with hidden workspace configuration
• Fake job interview repositories
• Compromised dependencies that add project-level config files
• Internal repositories modified after a lower-level account compromise

What Security Teams Should Check Now

Security teams should first confirm that Amazon Q Developer plugins are updated across all developer machines and IDEs. They should also verify that language server auto-updates are not blocked by endpoint or proxy rules.

Teams should scan codebases and developer workstations for unexpected .amazonq/ directories and mcp.json files, especially in repositories opened from external sources.

They should also look for abnormal cloud activity that follows repository review, extension activation, or IDE startup. Useful signals include new access keys, unusual sts:GetCallerIdentity calls, suspicious IAM changes, and outbound requests from developer endpoints to unknown collection servers.

Defensive Step	Why It Matters
Update Amazon Q Developer plugins	Applies the fixed Language Servers for AWS runtime
Review .amazonq/mcp.json files	Finds repository-defined MCP servers before approval
Limit secrets in environment variables	Reduces what child processes can inherit
Use short-lived cloud credentials	Limits attacker value if a token leaks
Monitor cloud actions after IDE activity	Helps detect credential misuse quickly

This Is Part of a Broader AI Coding Tool Risk

The Amazon Q issue fits a larger pattern across AI-assisted development tools. Agentic coding tools are powerful because they can inspect projects, call tools, run commands, and connect to services.

That same power creates a new supply chain problem when project-controlled files influence tool execution. Check Point Research disclosed related Claude Code issues involving project files, command execution, and API token exposure before trust confirmation.

The Model Context Protocol remains useful, but the security model must treat MCP server configuration as executable input. Tools should not auto-run repository-controlled commands without visible user consent and strong workspace boundaries.

How Developers Can Reduce Risk

Developers should update Amazon Q Developer plugins, reload their IDEs, and confirm they are using a patched language server. They should also inspect unfamiliar projects before activating coding assistants inside them.

Any prompt that asks to run an untrusted MCP server should be treated like a request to run a shell command. Developers should review the command, arguments, working directory, and environment access before approving it.

Check Point’s Claude Code research reached the same broader lesson: project files can become active execution paths when coding agents trust them too early. The safest default is to assume unfamiliar repositories are untrusted until reviewed.

• Update Amazon Q Developer plugins for VS Code, JetBrains, Eclipse, and Visual Studio.
• Reload the IDE so the latest language server is loaded.
• Review .amazonq/ directories in cloned repositories.
• Do not approve MCP server prompts unless the command is expected.
• Avoid opening unknown repositories while long-lived cloud credentials are active.
• Use least-privilege IAM roles and short-lived sessions for development.

FAQ