# Amazon Q Developer Flaw Let Attackers Steal Cloud Credentials Through Poisoned Code Repositories
A high-severity vulnerability in AWS's Amazon Q Developer AI coding assistant could allow attackers to silently capture cloud credentials and API keys from developers simply by tricking them into opening a malicious repository. Amazon Q would automatically execute attacker-controlled commands without asking permission—a flaw that exploited a fundamental trust assumption about what code inside a workspace should be allowed to do.
The vulnerability, tracked as CVE-2026-12957, affected Amazon Q Developer plugins across Visual Studio Code, JetBrains IDEs, Eclipse, and Visual Studio, as well as the underlying language server. AWS patched the issue on May 12 after being notified by Wiz researchers on April 20. The company published a security advisory this week, alongside proof-of-concept code that demonstrated the attack path.
## The Threat
The core problem was straightforward: Amazon Q Developer would automatically execute configuration files and shell commands embedded in a workspace without first prompting the developer for permission. This meant that opening a booby-trapped repository could immediately trigger malicious code that ran in the developer's environment—with full access to any cloud credentials, API keys, or session tokens already loaded in their shell.
For a developer authenticated to AWS, GitHub, or other cloud services, the impact was severe. An attacker could capture active session credentials and exfiltrate them silently, giving the attacker the same cloud access the developer had. No warning, no visible activity, no log entry visible to the developer themselves.
"The combination of auto-execution, shell spawning, and environment inheritance created a high-severity vulnerability in a widely-used developer tool," Wiz researchers noted. "A single malicious repository could compromise not just the developer's local machine, but their cloud infrastructure as well."
## Background and Context
Amazon Q Developer is an AI-powered coding assistant that helps developers write, refactor, and understand code. It's designed to be convenient—it integrates with IDEs, offers code suggestions, and can interact with external tools and services through local process integrations. The goal is to reduce friction and keep developers in flow.
That convenience came with an unexamined assumption: that configuration files and setup scripts inside a workspace were trusted code. In isolated development environments, that might be reasonable. But in a world where developers fork repositories, clone open-source projects, review pull requests, and collaborate across teams, the assumption breaks down. A developer might open a repository they've never seen before—a coding interview challenge, a new package, a PR review—and never expect that act to execute arbitrary commands.
Amazon Q Developer isn't alone in this. Similar vulnerabilities have been identified in other AI coding tools, including Anthropic's Claude for VS Code and Cursor. The issue highlights a broader pattern: as AI assistants gain deeper integration into development environments, they inherit security responsibilities that previously belonged to developers. When the assistant acts without explicit permission, the risk compounds.
## Technical Details
The vulnerability had two registered CVEs:
When a developer opened a workspace containing a malicious .vscode/settings.json or similar configuration file, Amazon Q would parse and execute embedded shell commands or integrations automatically. The extension would spawn a shell process and inherit the developer's environment—including all active AWS credentials, GitHub tokens, Stripe API keys, and other sensitive data stored in environment variables or local credential files.
An attacker could craft a repository designed to exfiltrate credentials to an attacker-controlled server, giving the attacker time-limited session tokens with the same privileges as the compromised developer.
AWS released patches across all affected platforms:
AWS's language server updates automatically for most customers unless network policies block it. IDEs reloading will trigger an update. For customers with auto-update blocked, manual upgrade to the latest Amazon Q Developer plugin version is required.
## Attack Scenarios
The Wiz researchers outlined several realistic attack paths:
| Attack Vector | Example |
|---|---|
| Fake Coding Challenge | Attacker posts a GitHub repository with a recruiting-themed interview problem. Developers clone it to solve the challenge. Hidden malicious configuration executes on open. |
| Typosquatted Package | Attacker creates a repository one character off from a popular library (e.g., aws-sk-v3 instead of aws-sdk-v3). A developer searching for the real package finds the fake and clones it. |
| Malicious Pull Request | Attacker opens a PR to a popular open-source project with a helpful feature. A reviewer clones the branch to test it. The PR includes poisoned configuration. |
| Supply Chain Watering Hole | Attacker compromises a developer tool repository or fork and injects configuration files targeting developers who work on that project. |
In each scenario, the attack is silent. The developer feels a moment's lag as their IDE reloads, but sees no warning, no execution log, no suspicious activity. By the time they realize something's wrong, the attacker already has their credentials.
## Implications
For development teams, this vulnerability exposed a critical gap: AI assistants were making security decisions (auto-execute yes/no) that should have been left to developers or explicitly governed by policy.
For individual developers: Any developer using Amazon Q Developer between the disclosure (April 20) and the patch deployment (May 12) was potentially at risk if they opened an untrusted repository. Even after the patch, developers should consider rotating any credentials that might have been active during that window.
For enterprises: Teams that auto-deploy developer tools across the organization face a distribution problem. If auto-update was blocked by network policy or proxy configuration, developers might still be running vulnerable versions. Security teams need to audit what versions of Amazon Q are running in their environments.
For open-source maintainers: The attack path through malicious PRs or typosquatted packages means maintainers need to be aware that reviewers testing code are potentially at risk. This shifts the responsibility for vetting pull requests—reviewers should not assume that opening a PR is a safe operation.
For cloud providers: This vulnerability is a signal that as AI assistants integrate deeper into development workflows, the security model needs to shift from "trust the workspace" to "verify every action." Auto-execution without explicit permission is incompatible with defense-in-depth security.
## Recommendations
For developers:
.vscode/, Makefile, setup scripts)For security teams:
For Amazon Q users:
---
## HackWire Analysis
The Amazon Q vulnerability exposes a fundamental architectural flaw in how modern AI assistants are integrated into development environments: the permission model is inverted. Instead of asking developers "what should I be allowed to do in this workspace?", the assistant assumes access and asks forgiveness later—if it asks at all.
This isn't a weakness unique to Amazon Q. The Wiz researchers noted that similar vulnerabilities exist in Claude, Cursor, and other AI coding tools. The pattern is consistent: as AI capabilities expand, the impulse is to grant broader environmental access to deliver better suggestions and faster code completion. The security trade-off happens silently, without explicit developer awareness.
What makes this timing critical is the velocity of AI adoption in development workflows. AWS is pushing Amazon Q aggressively as a competitive response to GitHub Copilot and other AI coding assistants. Many enterprises are auto-deploying it to their development teams without security review. The vulnerable window (April 20 to May 12) was long enough that organizations with slower patch cycles likely still have vulnerable developers in the field.
The broader implication: AI assistants in privileged environments (with access to credentials, shell execution, file system) need explicit trust models. Developers should not passively inherit the assistant's judgment about what's safe to run. This isn't a temporary issue that patches alone can fix—it requires a shift in how these tools are designed and integrated.
For defenders, the lesson is immediate: inventory your AI coding assistant deployments. Verify that patches are applied. And educate developers that opening a repository from an untrusted source is no longer just a code-reading exercise—it's now an execution risk. The attack surface for cloud credential theft just got larger.
— HackWire Editorial
---
## Related Coverage