A Single File in a Cloned Repo Could Hand Amazon Q Your AWS Keys. The Real Lesson Isn't Patch Amazon Q — It's Audit What Your Agent Auto-Loads.
A Single File in a Cloned Repo Could Hand Amazon Q Your AWS Keys. The Real Lesson Isn't Patch Amazon Q. It's Audit What Your Agent Auto-Loads.
Wiz disclosed a vulnerability in Amazon's AI coding assistant this week (CVE-2026-12957, CVSS 8.5), and the mechanics are the kind that should make you check your own setup, not just bump a version. Amazon Q read a Model Context Protocol config file, .amazonq/mcp.json, straight out of whatever workspace you had open, and launched the MCP servers it defined. No prompt. No consent dialog. No workspace-trust check.
So the attack is: drop that file in a repo, get someone to clone it and open it in their editor, and a process starts running with their full environment attached. That environment is usually AWS keys, cloud CLI tokens, API secrets, and an SSH agent socket. Git clone to cloud compromise, from one file you never opened.
Amazon fixed it. There's no known public exploitation, and CISA's entry lists exploitation as none. Patch and move on, but if you stop there, you've missed the actual lesson, which is bigger than Amazon Q.
What the bug actually was
MCP is the protocol your agent uses to talk to tools: a file system, a database, a browser, whatever you've wired up. An MCP server is just a process the agent can start and send commands to. Useful, and exactly as dangerous as it sounds, because "start a process" is the whole ballgame.
The mistake Amazon Q made was treating a project-local config file as trusted. It saw .amazonq/mcp.json in the open workspace and obeyed it: started the servers listed there, which inherited the developer's live shell environment. A malicious repo could define a "server" that's really just a command to read your AWS credentials file and POST it to an attacker's box. You clone the repo to take a look, your editor opens the folder, Amazon Q reads the config, and the command runs. You did nothing but open a directory.
The fix is in Language Servers for AWS 1.65.0, though AWS's own bulletin tells customers to move to 1.69.0. Wiz reported it April 20, Amazon shipped a fix May 12, and the public write-up landed June 26.
Why this isn't an Amazon problem
Here's the part that should change how you work. Amazon Q got named this week, but the pattern (an agentic dev tool auto-loading project-local config and acting on it) is everywhere now. Think about how many things in your setup read files out of the workspace the moment you open it:
MCP config files, in more than one tool. Editor settings that can define tasks and run commands. Git hooks. Format-on-save and lint configs that can shell out. "Recommended extensions" prompts. Devcontainer definitions that build and run. Agent instruction files that your coding agent reads and follows as if you wrote them.
Every one of those is a place where opening a repo means executing someone else's intent. The industry spent years training us that cloning a repo is safe: you're just copying text, you haven't run anything yet. Agentic tooling quietly broke that assumption. Opening the folder is now closer to running ./untrusted-script.sh than to reading a file.
The agentjacking attacks earlier this month and the npm worm running through build steps are the same story from different angles: the trust boundary moved, and a lot of tools didn't move their defaults with it.
The 10-minute Saturday audit
You don't need to become a security researcher. You need to know what auto-executes when you open a project, and gate the riskiest cases. Do this once:
List the agentic tools you actually use (Amazon Q, Claude Code, Cursor, Copilot, whatever) and update every one of them. For Amazon Q specifically, get to 1.69.0. The others ship security fixes constantly and most people are weeks behind.
For each tool, find out what project-local files it reads on open and whether it acts on them without asking. Check the docs or the settings for "workspace trust," "auto-load," "auto-approve," or MCP config discovery. If there's a setting that requires confirmation before running workspace-defined servers or tasks, turn it on. The few seconds of friction per project is the cheapest insurance you'll buy this year.
Adopt one habit for code you don't own: when you clone something from a stranger (a ZIP off a search result, a repo from a tutorial, a "minimal reproduction" someone attached to an issue) look before you open it in your agent-enabled editor. cat the config files. Specifically check for .amazonq/, .mcp.json, .vscode/tasks.json, .cursor/, devcontainer files, and any agent-instruction files. If you don't recognize what they do, open the folder somewhere your agent isn't watching, or in a throwaway environment.
If you work with cloud keys daily, the real fix is to not have long-lived credentials sitting in your shell environment in the first place. Short-lived, scoped tokens turn "stole my AWS keys" into "got a token that expires in an hour and can't touch prod." That's a bigger change than a Saturday, but it's the one that actually caps the blast radius regardless of which tool gets the next CVE.
The honest take
It's fair to push back that this is theoretical. No public exploitation, the bug's already patched, and "someone tricks you into cloning a booby-trapped repo" requires a setup. You could reasonably file this under "patch it and don't worry."
I think that read is too comfortable, for one reason: the attack doesn't need a clever social-engineering campaign. It needs you to do the most normal thing a developer does: clone a repo to look at it. Cloned-repo-that-outranks-the-original and fake-reproduction-attached-to-an-issue are both live tactics right now. The exposure isn't exotic; it's Tuesday.
So patch Amazon Q, yes. But the durable move is the audit: know what your tools execute on open, gate the ones that run workspace config without asking, and treat opening someone else's folder as the privileged action it quietly became. The next CVE in this category is already written. The habit is what protects you from it.
Author
Lukas
@lukcombinator