Amazon Q Developer Flaw Could Let Malicious Repos Run Code via MCP Configs

# Amazon Q Developer Flaw Lets Malicious Repos Execute Code With Cloud Credentials

## The Threat

A high-severity vulnerability in Amazon Q Developer could allow an attacker to execute arbitrary commands on a developer's machine and exfiltrate cloud credentials through a malicious repository configuration. Tracked as CVE-2026-12957 with a CVSS score of 8.5, the flaw stems from how Amazon's AI coding assistant handles Model Context Protocol (MCP) servers—local processes that extend the assistant's capabilities to interact with databases, APIs, build tools, and other services.

The attack path is deceptively simple: a developer clones a repository containing a malicious .amazonq/mcp.json configuration file and trusts the workspace when prompted. Amazon Q then automatically launches the MCP servers defined in that configuration file, executing arbitrary commands in the process. Because these processes inherit the developer's full environment—including active AWS credentials, CLI tokens, API secrets, and SSH agent sockets—an attacker gains immediate access to the developer's cloud session with no additional authentication required.

Wiz Research, the security firm that discovered and reported the vulnerability, demonstrated a proof-of-concept exploit where the malicious MCP configuration executed aws sts get-caller-identity and exfiltrated the developer's AWS session credentials to an attacker-controlled server. From that point, the potential for damage depends entirely on the compromised developer's cloud permissions: establishing persistence through IAM backdoors, accessing internal services, or pivoting toward production infrastructure.

## Severity and Impact

| Field | Value |

|-----------|-----------|

| CVE ID | CVE-2026-12957 |

| CVSS Score | 8.5 (High) |

| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N |

| Attack Complexity | Low |

| Privileges Required | None |

| User Interaction | Required (workspace trust prompt) |

| CWE | CWE-94: Improper Control of Generation of Code ('Code Injection') |

| Attack Vector | Network |

| Status | Fixed (May 12, 2026) |

| Public Disclosure | June 26, 2026 |

The vulnerability also led to the discovery of a second related flaw, CVE-2026-12958, which involves a missing symlink check that could allow arbitrary file writes outside the workspace trust boundary. Both issues affect the Language Servers for AWS runtime component, which powers Amazon Q integrations across multiple development environments.

## Affected Products

The following IDEs and tools running Language Servers for AWS are affected by CVE-2026-12957 and CVE-2026-12958:

Visual Studio Code

JetBrains IDEs (IntelliJ, PyCharm, WebStorm, etc.)

Eclipse IDE

Visual Studio

The vulnerability affects any developer using these IDEs with the Amazon Q extension enabled and with auto-update disabled or delayed. While the Language Servers for AWS component typically auto-updates, network restrictions or manual update deferrals leave systems exposed.

## Mitigations

Immediate Actions

Organizations should prioritize updating all affected Amazon Q installations to the patched versions as soon as possible. AWS recommends moving to Language Servers for AWS 1.69.0 or later, which addresses both CVE-2026-12957 and CVE-2026-12958.

Minimum Supported Versions:

For most users, reloading the IDE after updating will pull the latest Language Servers for AWS build. Developers whose networks block auto-updates should manually force the update and verify their extension version in the IDE's extension marketplace or plugin settings.

Defense in Depth

Beyond patching, organizations should consider implementing or enforcing the following practices:

## References

## HackWire Analysis

This is not Amazon Q's first stumble with configuration trust. In fact, it's part of a troubling pattern that spans the entire AI code assistant ecosystem. Within the past 18 months, we've documented similar vulnerabilities in Claude Code (CVE-2025-59536), Cursor (CVE-2025-54136), and Windsurf (CVE-2026-30615). The mechanics vary slightly—some abuse MCP configuration directly, others achieve code execution through symlink checks or config rewriting—but the root cause remains identical: project configuration files carry untrusted input, yet developers and tools treat them as trusted after a single "open workspace" prompt.

The convenience argument is seductive. Letting a project folder ship its own configuration—including which local processes an AI assistant should spawn—removes friction from developer onboarding. Clone a repo, open it in your IDE, hit "trust," and everything just works. But in security, convenience and trust verification are often at odds. A single checkbox that enables all downstream automation is a classic trust boundary failure. The better pattern is to treat repo-carried configuration as untrusted input, full stop. Yes, it requires an extra yes-or-no per MCP server. But that friction is the point—it forces intention.

The risk scales with access. A typical developer's machine carries AWS credentials, GitHub tokens, Slack API keys, SSH agent sockets, and kubectl access to production clusters. An attacker doesn't need to break into your Kubernetes cluster; they just need a developer to git clone their malicious repo. And the social engineering is trivial: "Check out this cool open-source library" or "Here's a patch we're reviewing—can you pull this branch and review it in your IDE?" Both are routine for working developers.

AWS gets credit for patching quickly (April 20 disclosure, May 12 fix, minimal delay to public writeup). But this is the third major AI assistant to make the same mistake in 18 months. The industry needs a learning moment. If every tool vendor rediscovers this vulnerability independently, we're going to be patching the same class of bug for years. — *HackWire Editorial.*

## Related Coverage