Amazon Q Extension Flaw Leaked AWS Credentials on Repo Open
Every backend lead who has ever told a junior to "just clone the repo and poke around" should pause on this one. A vulnerability in the Amazon Q Developer extension let a workspace configuration file run arbitrary commands the moment a developer opened a hostile repository. No prompt, no warning, no consent. Just code execution inside the same shell that holds your AWS credentials.
What Happened
Wiz researchers disclosed CVE-2026-12957, a flaw in the Amazon Q Developer extension for Visual Studio Code that automatically executed commands found inside workspace configuration files. As SC Media reported, opening a compromised repository was enough to trigger the chain. The extension would parse the config, run whatever the attacker had planted, and the developer would never see a confirmation dialog.
The blast radius was the local workstation, which in practice means active cloud credentials, API keys, and whatever else a working engineer keeps in their environment. Wiz flagged three plausible attack vectors: fake coding tests sent during interview loops, typosquatted open-source packages pulled in as dependencies, and malicious pull requests against legitimate projects. Each one routes through the same trust assumption: a developer clones, opens, inspects.
AWS was notified on April 20 and shipped a patch on May 12. That is roughly three weeks of vendor turnaround on a credential-exfiltration class bug, which is reasonable but not heroic. AWS noted that the language server updates automatically for most users, so the population still exposed today is mostly teams running pinned or air-gapped IDE setups. The same flaw class affected the extension across Visual Studio Code, JetBrains, Eclipse, and Visual Studio, so this was not a single IDE quirk. It was a shared backend behavior with broad reach.
The disclosure also noted that similar vulnerabilities have surfaced in other AI coding tools, which is the part that should make platform leads uncomfortable.
Technical Anatomy
The mechanism is depressingly simple. Modern IDE extensions read workspace configuration files on project load: things like task definitions, run targets, language server hints, and project metadata. Those files are version-controlled, which means whoever owns the repo owns the config. When an extension treats those values as executable instructions rather than declarative data, you have a remote code execution primitive disguised as a productivity feature.
In CVE-2026-12957, the Amazon Q Developer extension consumed workspace configuration content and acted on embedded commands without asking the user. The trust boundary was drawn in the wrong place. The extension implicitly trusted any file inside any folder the user chose to open, which is the same threat model as double-clicking an email attachment from 2003. You can verify the CVE record through the MITRE catalog as fixes propagate.
From an attacker's perspective, the workflow writes itself. Stand up a repository that looks like a legitimate take-home assignment for a senior Go role. Embed the payload in the workspace config. Wait for a candidate to clone and open. The payload runs, harvests `~/.aws/credentials`, environment variables, and any cached session tokens, and posts them to an attacker-controlled endpoint. The developer sees a normal-looking project. By the time anyone notices the egress, the credentials are already minting EC2 instances or draining S3.
The typosquatted package vector is worse because it scales. A single malicious dependency pulled into a popular template repo gives the attacker a steady stream of victims who never reviewed the file. The malicious PR vector targets maintainers directly, which means the highest-privilege accounts in an organization. In production incidents I've seen involving developer-workstation compromise, the root cause is almost always a tool quietly executing input that the developer assumed was inert.
My take: this is the AI-coding-assistant generation of the same class of bug that hit editor plugins a decade ago, and the fix pattern has not changed. Treat repo-supplied configuration as untrusted input, gate execution behind explicit consent, and isolate the language server from credential-bearing scopes.
Who Gets Burned
Three groups are exposed, in descending order of pain.
First, any team running pinned IDE or extension versions for compliance or reproducibility reasons. AWS says the language server updates automatically for most users, but "most" is doing a lot of work in that sentence. Regulated iGaming operators in Malta and Gibraltar often freeze developer tooling to satisfy change-control auditors. Fintechs under DORA scope do the same. Those teams now need to confirm their pinned versions include the May 12 patch or roll forward fast.
Second, any organization that uses long-lived AWS access keys on developer laptops. If a workstation got compromised between the bug's introduction and the patch, the credentials it held should be considered burned. Rotation is not optional. Teams I've worked with who skipped rotation after similar incidents found out months later that a forgotten IAM user was quietly running crypto miners in us-east-2.
Third, engineering orgs that run external coding assessments. The fake-coding-test vector targets your hiring pipeline directly. Every candidate who opened a take-home in the affected window is a potential blast site, and so is every interviewer who opened the candidate's submission. That cuts both ways.
The uncomfortable read: this bug class is going to repeat. AI coding assistants are racing to add agentic features, which by definition means executing things on behalf of the user. Each new capability is another decision point where a vendor has to choose between friction and safety. The market is currently rewarding friction reduction. Expect more CVEs in this shape across Copilot, Cursor, Cody, and whatever ships next quarter. The disclosure explicitly notes similar vulnerabilities have already surfaced in other AI coding tools.
Playbook for Security Teams
Concrete actions for this week, in priority order.
Confirm the Amazon Q Developer extension is updated across every IDE in your fleet: Visual Studio Code, JetBrains, Eclipse, and Visual Studio. Do not trust the auto-update claim until you've checked installed versions against the post-May-12 release. MDM-managed laptops make this a one-query job. BYOD shops need to send a clear notice.
Rotate any AWS access keys, session tokens, and third-party API keys that were resident on developer workstations between April 20 and May 12, or earlier if you want to be conservative about pre-disclosure exploitation. If you are still issuing long-lived IAM user keys to engineers in 2026, this is the incident that should push you to short-lived credentials via IAM Identity Center or equivalent.
Audit your hiring process. Any take-home coding test workflow that involves opening an external repository in a primary development environment needs to move to a disposable VM, a devcontainer, or a cloud sandbox. This is cheap insurance and it closes the fake-test vector permanently.
Add IDE extension inventory to your asset management. Most security teams track OS patches and browser versions but have zero visibility into which extensions developers run. That gap is now a known credential-exfiltration path. Cross-reference findings against the CISA KEV catalog as exploitation reports surface.
Finally, write a one-page internal policy: no AI coding assistant gets installed on a workstation that holds production credentials, full stop. Developers can run assistants in isolated environments. The convenience cost is real. The alternative is worse.
Key Takeaways
- CVE-2026-12957 let the Amazon Q Developer extension auto-execute commands from workspace config files, exposing AWS credentials on repo open.
- AWS patched on May 12 after Wiz disclosure on April 20, but pinned-version shops remain exposed until they verify the update.
- The flaw affected Visual Studio Code, JetBrains, Eclipse, and Visual Studio, making this a cross-IDE backend issue, not a single-editor bug.
- Fake coding tests, typosquatted packages, and malicious pull requests are the three live attack vectors flagged by Wiz.
- Rotate developer-held cloud credentials, sandbox external repos, and inventory IDE extensions before the next AI-assistant CVE lands.
Frequently Asked Questions
Q: What is CVE-2026-12957 and how serious is it?
CVE-2026-12957 is a vulnerability in the Amazon Q Developer extension that allowed attackers to execute arbitrary commands embedded in workspace configuration files when a developer opened a compromised repository. It's serious because exploitation required no user interaction beyond opening the repo, and it could exfiltrate active AWS credentials and API keys.
Q: Do I need to take action if my IDE auto-updates?
AWS says the language server updates automatically for most users, which mitigates the risk. You should still verify installed versions across Visual Studio Code, JetBrains, Eclipse, and Visual Studio, and rotate any cloud credentials that were resident on developer workstations during the exposure window.
Q: How can teams prevent similar AI coding assistant vulnerabilities?
Treat any repository-supplied configuration as untrusted input, run external code in disposable VMs or devcontainers, avoid long-lived cloud credentials on developer laptops, and maintain an inventory of installed IDE extensions. Similar flaws have already been found in other AI coding tools, so the threat class is not going away.
Cisco SD-WAN Zero-Day CVE-2026-20245 Exploited Two Months Pre-Disclosure
A 7.8 CVSS Cisco Catalyst SD-WAN zero-day was exploited at least two months before disclosure, chaining with two undisclosed auth bypass flaws to plant a hidden 'troot' account at a telco.
Kraken Buys 15% of Aave at $385M Valuation
Kraken is putting 35,000 ETH on the table for 15% of Aave at a $385M valuation, two months after an $8B deposit exodus. Bargain hunting or balance-sheet bravado?
Google Ads API v24.2 Lands: What Platform Leads Need to Decide Now
Google's Ads API v24.2 adds AI transparency, security hardening, and new reporting. The real question is who on your platform team absorbs the migration cost.




