The Amazon Q Developer extension incident: what AWS confirmed, and the lesson

The short answer

In July 2025, AWS disclosed that version 1.84.0 of the Amazon Q Developer extension for Visual Studio Code contained malicious code. A threat actor used a GitHub token from AWS’s CodeBuild configuration, which AWS says had an “inappropriately scoped” level of access, to commit the code to the extension’s open-source repository, and it was included automatically in a release. AWS says the code was distributed but failed to execute because of a syntax error, so it made no changes to any services or customer environments. The fix is version 1.85.0; the issue is CVE-2025-8217.¹²

If you still have 1.84.0 installed anywhere, remove it: AWS notes the malicious code remains present in existing installations, even though it can’t run.¹

What AWS confirmed

From bulletin AWS-2025-015 and the matching GitHub advisory:¹²

The GitHub advisory’s title calls it a “malicious script injected into” the extension.²

How the code got in

The advisory says AWS found the over-scoped token while investigating a second bulletin, AWS-2025-016.² That bulletin, “Memory Dump Issue in AWS CodeBuild,” explains the route: security researchers reported that a crafted pull request built automatically by CodeBuild could extract a repository access token from a memory dump in the build environment, and if the token had write permissions, an attacker could commit malicious code. The repositories whose tokens were extracted were the AWS Toolkit for Visual Studio Code and the AWS SDK for .NET.³

AWS’s recommendations in that bulletin are worth copying for any CI system, not just CodeBuild:³

• Don’t run automatic pull request builds from untrusted contributors.
• If a public repository must build untrusted contributions, use isolated runners.
• Limit webhook builds to trusted actors, or turn pull request triggers off.
• If untrusted builds ran with write-capable credentials, rotate them and review git logs for unusual activity.
• Revoke write permissions that aren’t strictly necessary.

In short: a pull request from a stranger ran in a build that held a token able to push to the repository, and the release process published what was pushed.

What AWS did not publish

AWS’s bulletin and advisory call it malicious code and a malicious script. Neither publishes the code or describes in detail what it was meant to do. Press coverage at the time described its intent; we stick to the primary sources here and don’t repeat second-hand accounts of the payload.

What the primary sources do establish is enough for the lesson: an attacker got code into an AI coding assistant’s official release, through the build pipeline, and the release went out to users.

Why this matters more for AI coding tools

A VS Code extension already runs with your user’s permissions. An AI coding assistant extension usually also has:

• Permission to run commands in your terminal, often after one approval or in an auto mode.
• Access to credentials your shell can reach: cloud CLI profiles, .env files, SSH keys. Our post on agents reading .env files covers that reach.
• A trusted voice. You’ve learned to accept its suggestions. Malicious behaviour inside a trusted tool is harder to notice than a strange download.

So the blast radius of a compromised AI extension is your whole developer environment, and through it, whatever your credentials reach.

What to do as a user

1. Check versions. In VS Code, open the Extensions panel and confirm Amazon Q Developer is past 1.84.0. AWS’s steps: Extensions panel, find Amazon Q Developer, click Update.¹
2. Turn off auto-update for AI tools that can run commands, where your editor allows it, and update deliberately after a release has been out for a few days.
3. Keep production credentials off developer machines. If a compromised extension can’t find a production key, it can’t use one.
4. Review what the extension may do without asking. Any “run commands without confirmation” setting is the difference between a bad suggestion and a bad action.

The same reasoning applies to MCP servers fetched with npx; the mcp-remote advisory is a neighbouring case.

What to do if you ship tools

• No write tokens in builds that run untrusted code. Pull requests from forks build with read-only credentials, or not at all.
• Separate build from release. A release should need a person, or at least a signed tag created outside the build that ran contributor code.
• Scan pull requests that touch agent configuration. A change to .mcp.json, .claude/settings.json or similar files deserves the same review as a change to CI. Our docs show how to scan every pull request with the Deedglass scan Action.

Before then, see what an agent on your machine could do without a prompt: paste its config into the check page or run npx deedglass scan (how the grade works); to try tool-call rules in your browser, open the playground.

Questions people ask

Which Amazon Q extension version was affected?

Version 1.84.0 of the Amazon Q Developer extension for VS Code. Version 1.85.0 is the fix.¹

Did the malicious code run?

AWS says it was distributed but failed to execute because of a syntax error, and made no changes to services or customer environments.¹

How did the attacker get access?

Through a GitHub token in CodeBuild with more access than it needed, which AWS links to a memory-dump issue in automated pull request builds.²³

Written with AI assistance and checked against our claims register.