Skip to main content
Emerging Threats

Amazon Q Developer Flaw Lets Malicious Repos Run Code via MCP Configs

Developer workstation with IDE open, laptop screen showing code, and terminal in background.

CVE-2026-12957 (CVSS 8.5) describes a high-severity flaw that let a malicious repository run commands and steal a developer’s cloud credentials simply by being opened in an IDE running Amazon Q.

How the MCP configuration turned into command execution

The vulnerability lived in how Amazon Q — via the Language Servers for AWS runtime — read a Model Context Protocol (MCP) configuration file, .amazonq/mcp.json, from an open workspace and launched the servers it defined. MCP servers are local processes an AI assistant can spawn to reach databases, APIs, or build tools; starting one means running commands on the developer’s machine. Because those spawned processes inherited the developer’s full environment, they gained access to AWS keys, cloud CLI tokens, API secrets, and SSH agent sockets that were present in the session.

Wiz Research demonstrated a short, straightforward path from git clone to cloud compromise: a single config file in a cloned repo caused Amazon Q to start an MCP server that executed aws sts get-caller-identity and exfiltrated the result to an attacker server, capturing the active AWS session. What an attacker could do next depends on that developer’s cloud permissions — for example, backdoor an IAM user for persistence, reach internal services, or pivot toward production.

What the vendor and finder say about consent and user interaction

AWS’s advisory frames the attack with a required consent step: the user must “trust the workspace” when prompted. The CVSS entry for CVE-2026-12957 rates the user interaction as passive. Wiz, the researcher that found and reported the flaw, said there was no separate consent step for the MCP servers themselves prior to the patch. Amazon’s update changes that behavior: untrusted MCP servers are now flagged and the developer can reject the command before it runs.

Scope: affected runtimes, IDE plugins, and update guidance

The flaw sat in Language Servers for AWS, the runtime that powers Amazon Q across VS Code, JetBrains, Eclipse, and Visual Studio. All four plugins bundle that language server, so versions that shipped an older copy were exposed. AWS’s bulletin identifies fixed builds and minimum patched plugin versions:

  • Language Servers for AWS: CVE-2026-12957 fixed in 1.65.0; customers are told to move to 1.69.0 (which also fixes CVE-2026-12958, a missing symlink check that could allow arbitrary file writes outside the workspace trust boundary).
  • Patched plugin minimums — VS Code: 2.20 or later; JetBrains: 4.3 or later; Eclipse: 2.7.4 or later; Visual Studio toolkit: 1.94.0.0 or later.
  • The language server auto-updates unless the network blocks it, and reloading the IDE pulls the latest build.

There is no known public exploitation; CISA’s ADP entry for CVE-2026-12957 lists the exploitation status as none. Wiz reported the flaw on April 20 and coordinated with Amazon; Amazon issued a fix on May 12 before the June 26 public write-up.

A pattern that repeats across coding assistants

This bug is the latest example of the same root problem: project-level configuration becomes executable behavior and trust checks around that handoff fail. The record shows similar incidents in other coding assistants — Claude Code (CVE-2025-59536) and Cursor (CVE-2025-54136) each had project-level MCP config that led to command execution, and Windsurf (CVE-2026-30615) achieved the same outcome by attacker-controlled content rewriting the local MCP config to register a malicious server. 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.

What this means for developers, security teams, and adversaries

  • Developers and security teams: Update the Language Servers for AWS and IDE plugins to the patched minimums (or the recommended 1.69.0 build), reload the IDE to pull the latest build, and treat repo-carried MCP configs as untrusted input until explicit consent controls are confirmed in your environment.
  • Affected enterprises and procurement leaders: Ensure deployed IDE toolchains meet the patched minimums; verify auto-update behavior is not blocked by network policy, since blocking updates prevents the language server from pulling the patched build.
  • Adversaries and threat actors: The proof-of-concept demonstrates that a single config file can capture an active AWS session; with the credentials obtained, an attacker could backdoor an IAM user for persistence, reach internal services, or pivot toward production depending on the captured session’s permissions.

Amazon has patched CVE-2026-12957 and closed a related symlink weakness (CVE-2026-12958), but the sequence that produced this bug — repo config to spawned local process to environment inheritance — has repeated across multiple assistants. The fix reduces risk by requiring explicit handling of untrusted MCP servers, but it leaves a practical choice for engineers: convenience versus a stricter, explicit trust model for project-supplied agent configuration. For now, the immediate technical imperative is simple and concrete: update the language server and IDE plugins and verify auto-updates are functioning.

Original story