Researchers Disclose Amazon Q Developer VS Code Flaw Affecting Cloud Credentials

A coding-AI-assistant flaw with cloud-credential implications — defender posture review for the week.

SEATTLE, WASHINGTON — Amazon Q Developer drew fresh scrutiny in late June 2026 after researchers at Wiz disclosed a pair of vulnerabilities in the AI coding assistant's Visual Studio Code extension and its underlying Language Servers for AWS — flaws that, under the right conditions, could expose a developer's cloud credentials to a malicious repository. AWS addressed the issues in updated builds, documented them in a security bulletin, and credited the researchers; the company reported the fix as the resolution of a coordinated disclosure rather than a response to in-the-wild abuse.

The disclosure reads as a vendor-flaw and trust-boundary story rather than a breach, but it lands on a sensitive surface: the AI assistant a developer runs inside the editor, with the same access to credentials and tokens the developer has. For organizations that have rolled Amazon Q Developer into their supply-chain and development workflows, the practical question is a defender-posture one: confirm the deployed build is patched, and understand how the tool decides whether to trust a workspace it has just opened.

What the Research Disclosed

According to Wiz Research, the vulnerabilities sit in the Amazon Q Developer extension for Visual Studio Code and in Language Servers for AWS, the runtime that powers Amazon Q Developer's AI coding assistance across its IDE plugins. The researchers reported two issues. The first, tracked as CVE-2026-12957 and assigned a CVSS score of 8.5, is described as an improper trust-boundary enforcement issue: if a local user opened a maliciously crafted workspace, commands defined in the project's configuration files could be executed automatically. The second, CVE-2026-12958, is a missing symlink-validation issue in which a maliciously crafted symlink in a workspace could resolve to a file path outside the workspace's trust boundary.

The mechanism at the center of the research is the way the assistant handled Model Context Protocol configurations. By default, according to the disclosure, Amazon Q automatically loaded and executed MCP server configurations defined in a workspace file — reported as .amazonq/mcp.json — without first requiring the user to approve or otherwise vet them. Because any process spawned from that configuration inherited the developer's environment, the research describes a path in which a developer who simply opened a prepared repository could have commands run on their machine with their own privileges and access.

The defender-relevant consequence is what that inherited environment can contain. The research notes that spawned processes could pick up cloud credentials, command-line tokens, API keys, and even SSH agent sockets present in the developer's session. In other words, the exposure is not limited to the contents of the repository itself; it extends to whatever access the developer's machine already holds, which on a working developer's laptop can be considerable. Wiz reported the issues to Amazon through a coordinated disclosure process.

Defender Posture for Organizations Using Amazon Q Developer With VS Code

For security teams, the first task is the most concrete: confirm which build of Amazon Q Developer and its language server is actually deployed across the organization's developer machines. AWS addressed the reported issues in Language Servers for AWS version 1.69.0 and the corresponding Amazon Q Developer plugin releases that bundle it, and the public advisory points teams to upgrade to the latest plugin version. Treating that as a patch-verification exercise — inventorying installs rather than assuming a representative version speaks for the whole fleet — is the durable step here, because extensions update on their own cadence and individual developers may lag behind a centrally managed baseline.

The second task is to understand the trust model the tool uses now. The substance of the disclosure is about how an assistant decides whether to trust a freshly opened workspace and the configuration files it carries. Defenders reviewing their posture can ask whether the deployed version prompts before loading workspace-level configurations, whether that behavior can be enforced through policy or managed settings, and whether developers in the organization understand that opening an unfamiliar repository in an AI-assisted editor is itself an action with security weight. The goal is not to single out one product but to make the editor's trust decisions visible and governable.

The third task is to limit what a developer's environment exposes in the first place. Because the research turns on inherited credentials and tokens, the controls that blunt this class of issue are the same ones that harden any developer endpoint: scoping cloud credentials tightly, preferring short-lived tokens over long-lived static keys, keeping secrets out of broadly readable environment variables where practical, and ensuring that a single developer machine cannot reach far more than the developer's role requires. None of these are specific to one CVE, which is precisely why they outlast it.

The MCP-Configuration Path in Context

The Model Context Protocol is a standard for connecting AI assistants to external tools and data sources, and MCP servers are the small programs that broker those connections. That design is useful — it is what lets an assistant read a project, call a tool, or run a task on the developer's behalf — but it also means an MCP configuration is, in effect, a list of programs the assistant may launch. The research's central observation is that automatically loading and executing such a configuration from an untrusted workspace, without an approval step, collapses the boundary between reading a repository and running code from it.

Read narrowly, the defender takeaway is about a single configuration file and a single product's default. Read more broadly, it is about a pattern: AI development tools increasingly act on files they find in a workspace, and a workspace is exactly the kind of thing an outside party can shape. That is the same logic behind other recent disclosures in editor and developer-tool integrations, including a one-click OAuth token-theft research finding in a VS Code web environment, where opening or interacting with attacker-influenced content carried more authority than a user might expect.

The constructive framing for defenders is to treat workspace-level configuration — MCP files, task definitions, editor settings, and the like — as untrusted input that an assistant should not act on silently. That principle does not depend on the specifics of any one tool's implementation, and it gives teams a stable lens for evaluating the next AI-assistant integration they adopt rather than reacting to each disclosure in isolation.

Parallel Exposure for Other VS Code AI-Assistant Extensions

One reason this disclosure resonated beyond Amazon Q is that researchers have reported structurally similar issues across the wider AI-coding-tool ecosystem in the same period. Reporting on the Amazon Q research notes that comparable workspace-configuration and auto-execution issues — frequently centered on MCP — have been identified in other assistants, including Claude Code, Cursor, and Windsurf, each tracked under its own CVE identifiers. The common thread is not a shared codebase but a shared design tension: tools that are valuable precisely because they act on a developer's project can be steered by whoever controls that project's files.

That pattern is worth naming because it changes how a defender should scope the question. The relevant unit of risk is not "is Amazon Q patched" alone but "how does every AI assistant our developers run decide what to trust." Teams that have standardized on AI-assisted development can use this cluster of disclosures as a prompt to inventory the assistants in use, check each against its vendor's advisories, and apply the same workspace-trust scrutiny uniformly. It is a close cousin of the questions raised by AI-agent integrations elsewhere, such as the prompt-injection research disclosed against a consumer voice assistant, where untrusted input reached a component with more privilege than the design anticipated.

The same caution applies in continuous-integration and automation contexts, where assistants and agents increasingly run with standing access. Recent research into an AI-agent integration's repository-takeover path in a popular code-hosting workflow underscored that the trust boundary problem is not confined to the desktop editor; it follows AI tooling wherever that tooling is granted the ability to act.

Open Questions

Several points remain worth tracking rather than asserting. The disclosure is framed as a coordinated finding with a vendor fix in hand, and AWS reported no evidence that the issues were abused before remediation; whether opportunistic attempts follow now that the research is public is something defenders should monitor rather than presume. The reporting also reflects the researchers' description of the default behavior and the conditions required to trigger the flaws, and organizations should confirm the specifics against the vendor's own advisory for their exact deployment.

What is settled is enough to act on. Two vulnerabilities in a widely used AI coding assistant — one carrying a CVSS score of 8.5 — turned on the assistant acting on workspace configuration without an approval step, with cloud credentials and tokens reachable through the developer's inherited environment, and fixed builds are available now. For organizations using Amazon Q Developer with VS Code, the prudent reading is to verify the deployed version, review how the tool handles untrusted workspaces, and extend that same review to every AI assistant their developers run.

Sources