The MCP Security Blind Spot in AI Coding Assistants A high-severity vulnerability in Amazon Q Developer, tracked as CVE-2026-12957 with a CVSS score of 8.5, allowed malicious repositories to execute arbitrary code and exfiltrate cloud credentials when a developer opened a workspace. Discovered by Wiz Research, the flaw exploited how the Model Context Protocol configuration file .amazonq/mcp.json was automatically processed without separate consent. This highlights a systemic security blind spot in AI coding assistants, with similar vulnerabilities found in Claude Code, Cursor, and Windsurf. Security https://www.devclubhouse.com/c/security Article The MCP Security Blind Spot in AI Coding Assistants A high-severity flaw in Amazon Q Developer highlights how repository-carried configuration files are turning simple git clones into cloud compromises. Emeka Okafor https://www.devclubhouse.com/u/emeka okafor For decades, the security model of software development had a simple rule: you can clone a repository and inspect its contents safely, as long as you do not run its build scripts or binaries. AI coding assistants have quietly broken that assumption. A high-severity vulnerability in Amazon Q Developer https://aws.amazon.com/q/developer/ , tracked as CVE-2026-12957 with a CVSS score of 8.5, recently demonstrated how easily this boundary can fail. Discovered by Wiz Research, the flaw allowed a malicious repository to execute arbitrary code and exfiltrate a developer's cloud credentials the moment they opened the workspace and trusted it. This is not an isolated bug. It is a structural design pattern where the convenience of letting a project folder configure an AI agent clashes directly with basic security hygiene. How MCP Configs Become Execution Vectors The root of the vulnerability lies in how Amazon Q handled the Model Context Protocol https://modelcontextprotocol.io MCP . MCP is an open standard designed to let AI assistants connect to external tools, databases, and APIs by spawning local processes. When a developer opened a workspace, the underlying runtime, Language Servers for AWS, searched for an MCP configuration file named .amazonq/mcp.json . If found, the extension automatically launched the local MCP servers defined within that file. Because these servers are simply local processes, starting one means running commands on the developer's machine. These spawned processes inherited the developer's full environment. This environment typically contains active AWS keys, cloud CLI tokens, API secrets, and SSH agent sockets. In their proof of concept, Wiz researchers showed that an attacker could drop a malicious .amazonq/mcp.json file into a repository. Once the developer trusted the workspace, the configuration executed a command like aws sts get-caller-identity and shipped the active AWS session token to an attacker-controlled server. From there, the attacker could exploit the developer's cloud permissions to backdoor IAM users, access internal services, or pivot deeper into the cloud infrastructure. While AWS's security bulletin notes that the user must first trust the workspace when prompted, Wiz reported that there was no separate consent step for the MCP servers themselves before the fix. The patch closes this gap: Amazon Q now flags untrusted MCP servers and requires the developer to approve the command before it runs. A Systemic Pattern Across the Industry The convenience of repository-carried configuration files is a massive attack surface. Amazon Q is not the only assistant to struggle with this. A series of similar vulnerabilities has emerged across the AI developer tool ecosystem: Claude Code CVE-2025-59536 suffered from project-level MCP configuration flaws that led to arbitrary command execution. Cursor CVE-2025-54136 experienced a similar breakdown in how it handled local MCP configurations. Windsurf CVE-2026-30615 was vulnerable to attacks where malicious content could rewrite the local MCP configuration to register and run an unauthorized server. This is also not the first time Amazon Q has faced execution boundary issues. In 2025, independent security research showed that indirect prompt injections could bypass the extension's "readonly" command categorization which bypassed human-in-the-loop confirmation by using commands like find with the -exec flag to run arbitrary system commands. Earlier that same year, a compromised GitHub token in AWS CodeBuild CVE-2025-8217 allowed an attacker to commit malicious code directly into the open-source repository for the Amazon Q VS Code https://code.visualstudio.com extension, which was then distributed via the marketplace. The pattern is clear. When an AI tool treats a configuration file inside an untrusted repository as an instruction to spawn processes, it turns untrusted input into executable code. Developer Impact: Mitigation and Hardening If you use Amazon Q Developer, you need to verify your plugin versions immediately. The vulnerability resides in the Language Servers for AWS runtime, which is bundled across multiple IDE plugins. To secure your environment, update to Language Servers for AWS version 1.69.0. This build not only addresses the MCP flaw CVE-2026-12957 but also patches CVE-2026-12958, a separate vulnerability involving a missing symlink check that could allow arbitrary file writes outside the workspace trust boundary. Ensure your IDE plugins meet or exceed these minimum versions: 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 While the language server typically auto-updates, reloading your IDE is necessary to apply the changes. However, relying solely on "trusting a workspace" is a weak defense. Developers frequently click through trust prompts to get to work. To truly mitigate these risks, organizations and developers should consider isolating their development environments. Running AI coding assistants within containerized environments, ephemeral VMs, or sandboxed dev containers prevents a compromised assistant from accessing the host machine's primary cloud credentials and SSH keys. The End of the Safe Clone The security model of the modern developer workstation is under active revision. As AI agents gain the ability to read files, run terminal commands, and configure their own tools, the boundary between static code and active execution is dissolving. Treating repository-carried configuration files as safe inputs is an assumption developers can no longer afford to make. Until AI tools run in strictly isolated sandboxes by default, the simple act of cloning a repository will remain a potential entry point for supply chain attacks. Sources & further reading - Amazon Q Developer Flaw Could Let Malicious Repos Run Code via MCP Configs https://thehackernews.com/2026/06/amazon-q-developer-flaw-could-let.html — thehackernews.com - Amazon Q Developer: Remote Code Execution with Prompt Injection · Embrace The Red https://embracethered.com/blog/posts/2025/amazon-q-developer-remote-code-execution/ — embracethered.com - Malicious script injected into Amazon Q Developer for Visual Studio Code VS Code Extension https://github.com/aws/aws-toolkit-vscode/security/advisories/GHSA-7g7f-ff96-5gcw — github.com - Amazon's AI coding agent was hacked - update now to avoid possible risks, users warned | TechRadar https://www.techradar.com/pro/amazon-ai-coding-agent-hacked-to-inject-data-wiping-commands — techradar.com - When AI Coding Assistants Turn Malicious: The Amazon Q Security Incident | Colin McNamara https://colinmcnamara.com/blog/amazon-q-ai-security-incident-analysis — colinmcnamara.com Emeka Okafor https://www.devclubhouse.com/u/emeka okafor · Security Editor Emeka has spent over a decade tracking threat actors, vulnerability disclosures, and the evolving landscape of application security, bringing a sharp continent-spanning perspective to his reporting. He's known for translating dense CVE advisories into clear, actionable context that developers and security teams alike actually read. Discussion 0 No comments yet Be the first to weigh in.