A critical security vulnerability, tracked as CVE-2026-12957 and rated with a CVSS score of 8.5 (High), was recently discovered and patched in Amazon Q Developer, Amazon’s artificial intelligence (AI) coding assistant. The flaw enabled a sophisticated attack vector where a malicious repository could execute arbitrary commands and steal a developer’s sensitive cloud credentials, including AWS keys, cloud CLI tokens, API secrets, and SSH agent sockets. The vulnerability’s discovery by Wiz Research underscores the ongoing challenges in securing AI-powered development tools, particularly concerning the delicate balance between developer convenience and robust security measures. Amazon has since released a patch to mitigate this significant threat, urging all users to update their installations promptly.
Understanding the Vulnerability in Amazon Q Developer
Amazon Q Developer is an advanced AI assistant designed to enhance developer productivity by providing real-time code suggestions, debugging assistance, and integration with various development environments and cloud services. Its core functionality often involves interacting with local system resources and leveraging developer credentials to perform tasks, a feature that, while convenient, introduces a potential attack surface if not meticulously secured.
The flaw, identified by Wiz Research, resided in how Amazon Q Developer handled Model Context Protocol (MCP) servers. MCP is a crucial component that allows AI assistants to spawn and manage local processes to interact with external resources like databases, APIs, or build tools. This interaction is facilitated by a configuration file, specifically .amazonq/mcp.json, located within the open workspace of a developer’s project.
The attack scenario was remarkably straightforward and insidious. A malicious actor could craft a seemingly innocuous repository containing a specially designed .amazonq/mcp.json file. When a developer cloned this repository, opened it in their integrated development environment (IDE), and subsequently "trusted" the workspace – a common prompt in modern IDEs to enable full functionality – Amazon Q Developer would automatically read the malicious MCP configuration. Crucially, before the patch, there was no separate consent mechanism for the MCP servers themselves. The AI assistant would then launch the servers defined in the malicious configuration.
The critical danger lay in the fact that these launched processes inherited the developer’s full environment. This inheritance meant that any commands executed by the malicious MCP server would run with the same privileges and access to the sensitive information available to the developer’s session. This typically includes active AWS session keys, command-line interface (CLI) tokens, various API secrets, and even SSH agent sockets. The path from cloning a repository to a full cloud compromise was alarmingly short: "a developer opens the repo, trusts the workspace, and Amazon Q does the rest." No password prompts or secondary authentication steps were required for the attacker to gain control over the developer’s cloud session.
How the Attack Unfolded: A Technical Deep Dive
Wiz Research’s proof of concept (PoC) vividly demonstrated the severity of this vulnerability. In their simulated attack, the malicious .amazonq/mcp.json file instructed Amazon Q to execute the aws sts get-caller-identity command. This AWS CLI command is designed to return information about the identity of the AWS account currently in use, effectively revealing the active AWS session credentials. The output of this command, containing sensitive session data, was then exfiltrated to an attacker-controlled server.
Once these active AWS session tokens were compromised, the potential for further damage was extensive. The attacker’s subsequent actions would depend entirely on the permissions associated with the compromised developer’s AWS identity. This could range from backdooring an AWS Identity and Access Management (IAM) user to establish persistence, gaining unauthorized access to internal services within the organization’s AWS environment, or pivoting to production systems, potentially leading to data breaches, service disruptions, or even complete control over critical cloud infrastructure. The absence of a separate consent step for launching these MCP servers before the fix represented a significant security oversight, turning a common developer action (trusting a workspace) into a critical vulnerability.
The Role of Model Context Protocol (MCP) and Trust Boundaries
The Model Context Protocol (MCP) is integral to how AI coding assistants like Amazon Q extend their capabilities beyond simple text processing. By allowing these assistants to spin up local processes, MCP facilitates rich interactions with a developer’s specific project context, enabling actions such as running tests, querying local databases, or interacting with version control systems. However, this power also introduces a complex security challenge: how to safely execute code and access resources based on potentially untrusted input from a project repository.
The core issue highlighted by CVE-2026-12957 was a breakdown in the trust boundary around MCP server instantiation. While developers are often prompted to "trust" a workspace when opening a new or unfamiliar project, this general trust dialog was not granular enough to explicitly warn about or require separate consent for the execution of potentially malicious MCP servers defined within that workspace. Amazon’s advisory initially framed the user interaction as passive, implying that the user "had to trust the workspace when prompted." However, Wiz’s findings emphasized that there was no distinct, explicit consent step specifically for the MCP servers before the fix. This subtle but crucial difference meant that merely trusting a workspace, a routine action for many developers, was sufficient to trigger the malicious payload.
The patch implemented by Amazon directly addresses this gap. With the updated versions, Amazon Q Developer now actively flags an untrusted MCP server and presents an explicit prompt to the developer, allowing them to review and reject the command before it is executed. This change introduces a much-needed layer of explicit user consent, restoring a critical security boundary that was previously missing.
Discovery, Disclosure, and Amazon’s Swift Response
The vulnerability was discovered and responsibly reported by Wiz Research, a cybersecurity firm known for its expertise in cloud security. Their proactive research into AI development tools brought this critical flaw to light. The chronological timeline of events underscores a diligent and coordinated effort:
- April 20: Wiz Research identified the flaw and reported it to Amazon through responsible disclosure channels. This initiated Amazon’s internal investigation and remediation process.
- May 12: Amazon successfully developed and deployed a patch to address CVE-2026-12957, as well as a second related vulnerability. This swift action within weeks of the initial report demonstrates Amazon’s commitment to addressing security concerns promptly.
- June 26: Wiz Research publicly disclosed the vulnerability and its findings, coinciding with Amazon’s official security bulletins and advisories. This coordinated public release allowed developers and organizations to understand the threat and take necessary update actions immediately.
It is important to note that, as of the public disclosure, there was no known public exploitation of CVE-2026-12957. CISA’s ADP (Active Exploitation of Vulnerabilities) entry for this CVE also lists it as "none," indicating that the vulnerability was patched before it could be widely leveraged by malicious actors in the wild. This outcome is a testament to the effectiveness of responsible disclosure practices and the rapid response from vendors like Amazon.
Affected Platforms and Remediation Steps
The flaw was present in "Language Servers for AWS," the underlying runtime that powers Amazon Q Developer across multiple popular IDEs. Consequently, all four major plugins bundling this runtime were exposed: VS Code, JetBrains (IntelliJ IDEA, PyCharm, etc.), Eclipse, and Visual Studio. Any versions of these plugins that shipped with an older, unpatched copy of the Language Servers for AWS runtime were vulnerable.
To mitigate the risk, Amazon strongly advises all customers to update their installations immediately. While CVE-2026-12957 is fixed in Language Servers for AWS version 1.65.0, Amazon’s security bulletin recommends moving to version 1.69.0. This recommendation is crucial because version 1.69.0 also addresses a second, related security issue: CVE-2026-12958.
CVE-2026-12958: A Second Critical Fix
CVE-2026-12958 describes a missing symlink check within the Language Servers for AWS runtime. This vulnerability could allow arbitrary file writes outside the intended workspace trust boundary. In an attack scenario, this could enable an attacker to create or modify files in sensitive system locations beyond the developer’s project directory, potentially leading to further compromise, privilege escalation, or persistence on the developer’s machine. While distinct from the credential theft flaw, CVE-2026-12958 represents another significant risk, reinforcing the importance of updating to the latest recommended version.
The language server typically auto-updates unless network configurations specifically block this process. Developers can also ensure they have the latest build by simply reloading their IDE or manually checking for plugin updates within their respective development environments.
Broader Implications for AI Development Security
The discovery of CVE-2026-12957 and CVE-2026-12958 carries significant implications for the broader landscape of AI-driven software development and supply chain security. As AI coding assistants become increasingly integrated into daily development workflows, they introduce new attack vectors that organizations must diligently address.
- Supply Chain Vulnerability: The incident highlights the inherent risks of incorporating third-party code, even if seemingly benign, into development environments. A malicious repository can serve as a Trojan horse, compromising not just the immediate project but the entire developer workstation and, by extension, the organization’s cloud infrastructure.
- Developer Environment as a High-Value Target: Developer machines are prime targets for attackers due to the extensive access they often have to source code, credentials, internal networks, and production environments. Compromising a developer’s machine can serve as a highly effective pivot point for lateral movement and deeper infiltration.
- Balancing Convenience and Security: AI assistants are designed for convenience and productivity. However, this often involves granting them significant permissions to interact with the local system and cloud resources. The challenge lies in designing these tools with robust security safeguards that do not unduly hinder the developer experience, ensuring that convenience does not come at the cost of security.
- The Evolving Threat Landscape: As AI tools become more sophisticated, so too will the methods employed by attackers. Security researchers and vendors must continually anticipate and address novel attack techniques that leverage the unique functionalities and integrations of AI assistants.
A Recurring Pattern in AI Coding Assistants
What makes the Amazon Q Developer vulnerability particularly noteworthy is that it is not an isolated incident but rather fits into a recurring pattern observed across the AI coding assistant ecosystem. Wiz Research, in its public disclosure, explicitly pointed out similar vulnerabilities affecting other prominent AI development tools:
- Claude Code (CVE-2025-59536): This vulnerability allowed remote code execution through project-level configuration, similar to the Amazon Q flaw.
- Cursor (CVE-2025-54136): Another AI code editor that exhibited a similar issue, where malicious project configurations could lead to command execution.
- Windsurf (CVE-2026-30615): While the exact path differed, this vulnerability also led to arbitrary command execution by allowing attacker-controlled content to rewrite local MCP configurations, effectively registering malicious servers.
The common thread running through these incidents is clear: the convenience of allowing a project folder to configure an AI agent often creates an untrusted input surface. When this untrusted input dictates executable behavior, and the trust checks around that handoff are insufficient, the stage is set for serious security breaches. The industry-wide challenge lies in fundamentally rethinking how these tools handle project-carried configurations, ensuring that any action that involves running processes or accessing sensitive resources based on untrusted input requires explicit, unambiguous user consent.
Recommendations for Developers and Organizations
In light of these findings, developers and organizations must adopt a proactive and multi-layered approach to secure their development environments and AI-powered workflows:
- Immediate Updates: Ensure all instances of Amazon Q Developer and the underlying Language Servers for AWS runtime are updated to the latest recommended version (1.69.0 or higher) across all IDEs (VS Code, JetBrains, Eclipse, Visual Studio).
- Vigilance with Repositories and Workspaces: Exercise extreme caution when cloning and opening repositories from untrusted or unknown sources. Developers should always scrutinize repository contents and be wary of unexpected prompts to "trust" a workspace, especially when new explicit consent steps for MCP servers are introduced.
- Principle of Least Privilege: Implement and enforce the principle of least privilege for all developer credentials and cloud access. Developers should only have the minimum necessary permissions required to perform their tasks, limiting the potential impact of a credential compromise.
- Enhanced Security Training: Provide regular security awareness training for developers, focusing on common attack vectors, the risks associated with AI development tools, and best practices for securing their workstations and cloud access.
- Secure Development Environments (SDEs): Consider using isolated and tightly controlled Secure Development Environments, which can help contain potential breaches and limit access to sensitive production resources from individual developer machines.
- Security Scanning and Monitoring: Integrate security scanning tools into the CI/CD pipeline to identify malicious code or configurations in repositories. Implement robust logging and monitoring for developer activities and cloud resource access to detect anomalous behavior indicative of a compromise.
- Review AI Tool Configurations: Regularly review the configurations and permissions granted to AI coding assistants and other development tools to ensure they align with security best practices and organizational policies.
The vulnerability in Amazon Q Developer serves as a potent reminder that even the most advanced tools, designed to enhance productivity, can harbor critical security flaws. As the adoption of AI in software development accelerates, continuous vigilance, robust security engineering, and a commitment to responsible disclosure will be paramount in safeguarding the digital infrastructure that underpins our modern world. The industry must learn from these recurring patterns and implement more resilient security architectures that prioritize explicit trust and granular control over potentially dangerous automated actions.
