ZeroHour
The Hacker Newspublished ()ingested @TheHackersNews

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

Vulnerabilities mentionedAll →

CVEVulnerabilityCVSSEPSSFlagsAffectedExposurePublished
CVE-2025-54136
Trusted MCP Config Swap Enables RCE in Cursor AI Code Editor ≤1.2.4

CVE-2025-54136 is a command-injection flaw (CWE-78) in the Cursor AI code editor, versions 1.2.4 and below, in which changes to a previously trusted Model Context Protocol (MCP) configuration are not re-validated, letting a trusted command be silently swapped for an attacker-controlled one. The issue is triggered when an attacker with write permissions on the user's active branches of a source repository containing already-approved MCP servers — or with arbitrary local file-write on the victim's machine — modifies the trusted MCP configuration file; after the user accepts an innocuous MCP entry, the attacker can replace it with a malicious command without any warning or re-prompt. Successful exploitation yields remote and persistent arbitrary code execution on the developer's machine because the established MCP trust bypasses the prompts that would normally expose the change. Only Cursor 1.2.4 or earlier is affected; practical exposure additionally requires the user to have previously approved MCP servers whose configuration is attacker-writable. No public proof-of-concept or confirmed in-the-wild exploitation is known, though EPSS assigns a 27.1% probability of exploitation within 30 days (98th percentile) and CISA has not added it to the KEV catalog.

Do: Upgrade Cursor to version 1.3 or later. Until then, closely review and version-control MCP configuration files in shared repositories (require pull-request review for changes to approved MCP entries) and audit currently approved MCP server commands for unexpected edits, since swaps to already-trusted entries occur with no warning or re-prompt. Treat the fix as urgent given the high EPSS probability of near-term exploitation.

8.827%
  • anysphere cursor 1.2.4 and below; fixed in 1.3
mass≈1M developer installs (reported user base of the Cursor editor; only users with previously approved MCP servers in shared repositories or locally writable…
CVE-2025-59536
Code Injection in Anthropic Claude Code Startup Trust Dialog (pre-1.0.111)

Anthropic's Claude Code, an agentic coding tool, contained a code injection flaw (CWE-94) caused by a bug in its startup trust dialog implementation, so all versions before 1.0.111 are affected. An attacker who controls the contents of a project directory — for example a malicious or compromised repository — can get Claude Code to execute code contained in that project before the user has accepted the startup trust dialog, bypassing the prompt meant to gate execution. The trigger is simply a user starting Claude Code in an untrusted directory (user interaction is required, per the CVSS 4.0 vector scored 8.7 High), and a successful attack yields arbitrary code execution with the developer's local privileges, potentially exposing source code and credentials accessible to that account. Users on the standard auto-update channel have already received the fix automatically, while manually updated or version-pinned installations remain exposed until upgraded to 1.0.111 or later. No public proof-of-concept or CISA KEV listing is known, but EPSS assigns a 26.4% probability of exploitation within 30 days (98th percentile), and related research on Claude Code code execution and a similar Amazon Q Developer flaw indicates active researcher and attacker interest in this attack surface.

Do: Update Claude Code to version 1.0.111 or later; auto-update users should already be patched but should verify the installed version on each workstation, while manually updated or pinned installs must be upgraded explicitly. Until patched, avoid starting Claude Code in untrusted or freshly cloned project directories, and treat trust-dialog prompts on unpatched versions as not yet protective.

8.726%
  • Anthropic Claude Code All versions before 1.0.111; fixed in 1.0.111
largeon the order of hundreds of thousands of developer installations (local CLI; auto-update users already patched)
CVE-2026-12957
Improper trust boundary enforcement in Language Servers for AWS before version 1.65.0 on all supported platforms may allow a for arbitrary code execution.

Improper trust boundary enforcement in Language Servers for AWS before version 1.65.0 on all supported platforms may allow a for arbitrary code execution. If a local user opens a maliciously crafted workspace, any commands within the project configuration files may be automatically executed. This issue requires the user to trust the workspace when prompted. To remediate this issue, users should upgrade to Language Servers for AWS version 1.65.0 or higher.

NVD description · AI analysis pending
8.5<1%
CVE-2026-12958
Missing symlink validation in Language Servers for AWS may allow an arbitrary file write outside of the workspace trust boundary.

Missing symlink validation in Language Servers for AWS may allow an arbitrary file write outside of the workspace trust boundary. This may occur when a local user opens a workspace with a maliciously crafted symlink that resolves to a file path outside the workspace trust boundary. To remediate this issue, users should upgrade to version 1.69.0 or higher.

NVD description · AI analysis pending
8.5<1%
CVE-2026-30615
A prompt injection vulnerability in Windsurf 1.9544.26 allows remote attackers to execute arbitrary commands on a victim system.

A prompt injection vulnerability in Windsurf 1.9544.26 allows remote attackers to execute arbitrary commands on a victim system. When Windsurf processes attacker-controlled HTML content, malicious instructions can cause unauthorized modification of the local MCP configuration and automatic registration of a malicious MCP STDIO server, resulting in execution of arbitrary commands without further user interaction. Successful exploitation may allow attackers to execute commands on behalf of the user, persist malicious MCP configuration changes, and access sensitive information exposed through the application.

NVD description · AI analysis pending
8.0<1%
Full article618 words · extracted from thehackernews.com · click to collapse

Swati KhandelwalJun 26, 2026AI Security / Vulnerability

A high-severity flaw in Amazon Q Developer let a malicious repository run commands and steal a developer's cloud credentials. The path was short: a developer opens the repo, trusts the workspace, and Amazon Q does the rest. Amazon has patched it.

Tracked as CVE-2026-12957 (CVSS 8.5), the bug sat in how Amazon's AI coding assistant handled Model Context Protocol (MCP) servers.

Wiz Research, which found and reported it, showed that a single config file dropped in a repo was enough to go from git clone to cloud compromise.

How the attack worked

Amazon Q read an MCP configuration file, .amazonq/mcp.json, from the open workspace and launched the servers it defined. MCP servers are local processes that an AI assistant can spawn to reach databases, APIs, or build tools, so starting one means running commands on the machine.

Those processes inherited the developer's full environment. That usually means AWS keys, cloud CLI tokens, API secrets, and SSH agent sockets.

Put the two together, and a file sitting in a cloned repo could run arbitrary code with the developer's live cloud session attached. No password, no second sign-in.

In its proof of concept, Wiz had the file run aws sts get-caller-identity and ship the output to an attacker server, capturing the active AWS session. What comes next depends on that developer's cloud permissions: backdoor an IAM user for persistence, reach internal services, or pivot toward production.

AWS and Wiz frame the consent step differently. Amazon's advisory says the user has to trust the workspace when prompted, and CVSS rates the user interaction as passive.

Wiz reported there was no separate consent step for the MCP servers themselves before the fix. The patch closes that gap: Amazon Q now flags an untrusted MCP server and lets the developer reject the command before it runs.

The flaw lives in Language Servers for AWS, the runtime that powers Amazon Q across VS Code, JetBrains, Eclipse, and Visual Studio. All four plugins bundle it, so all four were exposed by versions that shipped an older copy.

What to do

Update. CVE-2026-12957 is fixed in Language Servers for AWS 1.65.0, but AWS's bulletin tells customers to move to 1.69.0.

That build also closes a second issue, CVE-2026-12958, a missing symlink check that could allow arbitrary file writes outside the workspace trust boundary.

The 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 it as none. Wiz found the flaw through research and disclosed it in coordination with Amazon, reporting it on April 20 and seeing a fix on May 12, ahead of the June 26 public write-up.

A pattern, not a one-off

Amazon Q is not the first coding assistant to trip over MCP trust. The bugs are not identical, but they rhyme: project configuration turns into executable behavior, and the trust checks around that handoff keep failing.

Claude Code (CVE-2025-59536) and Cursor (CVE-2025-54136) both had project-level MCP config that led to command execution. Windsurf (CVE-2026-30615) reached the same end by a different path, with 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. Turning it into a running process should take an explicit yes.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

Text extracted automatically; images, tables and formatting may be missing. Original: https://thehackernews.com/2026/06/amazon-q-developer-flaw-could-let.html