CVE-2026-12957: Amazon Q Developer Flaw Let a Cloned Repo Steal AWS Credentials

Amazon patched a high-severity flaw in Q Developer in mid-2026 that gave attackers a straight path from a cloned repository to a developer's live AWS credentials.

What Happened

The vulnerability, tracked as CVE-2026-12957 with a CVSS base score of 8.5, lived inside the way Amazon Q Developer processed Model Context Protocol (MCP) server configurations embedded in a workspace. MCP is an emerging standard that lets AI coding assistants communicate with external tools and services. The problem: Q Developer would read and act on MCP configuration files shipped inside a repository without independently validating whether those configurations were safe to run.

The attack chain required almost no sophistication. A developer clones a repository — a routine act that happens thousands of times a day across engineering teams. The IDE asks if the developer trusts the workspace. The developer clicks yes. They always click yes. Amazon Q then reads the MCP configuration bundled in that workspace and spawns a server process running under the developer's own identity.

That spawned process inherits the developer's full local environment. For most AWS engineers, that environment is rich with credential material: named profiles, SSO session tokens, or instance role credentials accessible through the EC2 metadata service. Once code execution lands, exfiltrating those secrets is trivial.

Why This Attack Surface Is Genuinely New

Two design assumptions failed simultaneously here, and both deserve attention from security architects.

First, workspace trust — the prompt that IDE environments use to gate dangerous operations — was treated as a meaningful security boundary. It isn't, when an AI agent auto-loads and acts on configuration files before a human can review them. The click happens in under a second. The credential theft can happen in the same second.

Second, MCP server definitions embedded in a repository were effectively treated as declarative data: static configuration that describes intent rather than executing it. That distinction collapsed the moment Q Developer began spawning processes based on those definitions. Declarative and executable are no longer separate categories when an AI agent sits in the middle.

The Verizon 2024 Data Breach Investigations Report found that 68% of breaches involved a human element — someone clicking, trusting, or misconfiguring something. The workspace-trust dialog is exactly that element, dressed in a UX wrapper that signals safety while enabling risk.

The Regulatory Picture

No formal regulatory action accompanied this disclosure. The SEC's cyber-incident reporting obligation under Item 1.05 of Form 8-K attaches only to incidents a registrant deems material. A patched developer-tool vulnerability with no confirmed exploitation is unlikely to clear that bar. CISA's CIRCIA reporting framework remains in proposed-rule status, so covered-entity obligations for supply-chain-style developer compromises are still a future concern rather than a present compliance requirement.

That regulatory quiet should not be mistaken for low severity. A single developer's AWS credentials, depending on their IAM permissions, can unlock production environments, S3 buckets, secrets in Parameter Store, or RDS instances. The blast radius of this class of attack scales with the permissions attached to the compromised identity, not with the sophistication of the exploit.

What Controls Failed

The root control failure here was insufficient trust boundary enforcement at the AI agent layer. Traditional IDE threat models assumed that code execution required an explicit user action — running a script, building a project, invoking a command. AI coding assistants shattered that assumption. They auto-load configurations, auto-spawn processes, and auto-consult external services, all in the background of what the developer perceives as a passive read operation.

Missing guardrails around MCP configuration ingestion compounded the problem. There was no sandboxing of spawned server processes, no isolation of the network or credential environment those processes could reach, and no secondary approval step before a configuration file from an untrusted source triggered execution. Any one of those controls, implemented, would have broken the attack chain.

Identity hygiene also plays a role. Ambient credentials — long-lived profile tokens or SSO sessions with broad permissions sitting idle in a developer's environment — are the fuel this attack burns. Short-lived credentials scoped to least privilege don't eliminate the risk, but they cut the blast radius sharply. NIST SP 800-207, the Zero Trust Architecture guide, is explicit on this: no implicit trust based on network location or host identity, verify explicitly and limit access to what is needed for the task at hand.

What Defenders Should Do Now

Update Amazon Q Developer to the patched build immediately. That is the non-negotiable first step.

Beyond the patch, audit every MCP server configuration present on developer workstations, particularly those pulled from third-party or open-source repositories. Treat any MCP definition file from an external source as potentially executable intent, not passive configuration.

Review IAM permissions attached to developer identities. If an engineer's local credentials can touch production resources, the blast radius of the next credential-theft flaw — and there will be a next one — is unacceptably large. Enforce least-privilege access and rotate credentials frequently. Consider whether ambient, persistent credentials should exist on developer machines at all, or whether short-lived credentials issued on demand better fit the risk profile.

Finally, educate developers that workspace-trust dialogs carry real security weight. This is precisely where security-awareness training tailored to engineering teams can shift behavior: developers who understand that a single trust click can expose cloud credentials treat that dialog differently than those who see it as a UI speed bump.

The Bigger Picture

MCP is young. The specification is still being hardened, adoption is accelerating faster than the threat model is being defined, and the relationship between AI agent, host environment, and remote server is being written in production code rather than in security design documents. Amazon Q is not the last product that will ship a finding in this class.

AI coding assistants are now credential-adjacent processes running with the full ambient authority of whoever is logged in. Every new auto-loaded configuration format — MCP today, something else by next quarter — adds attack surface that legacy IDE security models never contemplated. Security teams that treat these tools as simple text editors with autocomplete will keep getting surprised.

The fix is available. Apply it. Then start asking harder questions about what else your AI development tooling is loading, executing, and reaching out to on behalf of your engineers.