In short

In July 2025 version 1.84.0 of the Amazon Q Developer extension for VS Code shipped with code a threat actor had committed to its open-source repository. AWS says the extension's AWS CodeBuild configuration had an inappropriately scoped GitHub token, extracted through a memory dump in a pull request build, and that the commit was automatically included in a release. The injected code was designed to call the Q Developer CLI, an AI agent, but a syntax error stopped it from running. AWS revoked the credentials, removed the code, shipped 1.85.0 and withdrew 1.84.0. Keep write tokens out of builds of untrusted pull requests, review what goes into a release, and limit what an AI agent on a developer machine can do without a person.

  • AWS-2025-015 says the extension "had an inappropriately scoped GitHub token in their CodeBuild configuration" and that the threat actor's commit "was automatically included in a release."
  • AWS-2025-016 explains how such a token leaks: a pull request built automatically by CodeBuild could extract the repository access token through a memory dump, and a threat actor did this for the AWS Toolkit for VS Code and AWS SDK for .NET repositories.
  • The CVE record (CVE-2025-8217, CWE-506 Embedded Malicious Code) says version 1.84.0 "contains inert, injected code designed to call the Q Developer CLI" that fails because of a syntax error.
  • AWS strongly recommends not running automatic pull request builds from untrusted contributors, and rotating any write-scoped credentials such builds could reach.
  • The injected prompt's text, reported by the press as telling the agent to wipe the system and delete cloud resources, is not quoted in any AWS bulletin, the advisory or the CVE record.
  • The near miss is the AI lesson: code that hands instructions to an agent with the user's permissions needs no exploit of its own. Limit what such agents can do without approval.

Incident at a glance

Dates
to
Category
Supply-chain compromise
Organization
  • Amazon Web Services (AWS)
Impact
A threat actor used an over-scoped GitHub token from AWS CodeBuild to commit code that shipped in Amazon Q Developer for VS Code 1.84.0. AWS says the code, designed to call the Q Developer CLI, failed to run because of a syntax error.
How it was found
AWS says it found the over-scoped token while investigating a CodeBuild memory-dump issue that security researchers had reported (AWS-2025-016).

Timeline

  1. The amazonq/v1.84.0 release record is published in the aws/aws-toolkit-vscode repository.
  2. The amazonq/v1.85.0 release record is published; AWS later says 1.85.0 removed the malicious code.
  3. AWS publishes bulletin AWS-2025-015 and tells customers to remove 1.84.0 and update to 1.85.0.
  4. AWS publishes AWS-2025-016 on the CodeBuild memory-dump technique and updates AWS-2025-015.
  5. AWS publishes advisory GHSA-7g7f-ff96-5gcw.
  6. AWS publishes CVE-2025-8217 (CWE-506 Embedded Malicious Code).

Verify it

  1. List every CI project that builds pull requests automatically and confirm none builds untrusted contributors' code with a write-scoped repository credential.
  2. In CodeBuild, confirm webhook event or actor filters exclude untrusted pull requests, or that automatic rebuilds are off.
  3. Confirm release builds run from a protected, reviewed commit in a separate job with its own credentials and a required approval.
  4. Search the extension inventory on developer machines for Amazon Q Developer 1.84.0 and confirm none remains.
  5. Check that AI agent CLIs on developer machines prompt before destructive file, shell and cloud actions and use short-lived credentials.
Applies to

Public repositories built by CI services that hold repository credentials, release pipelines for developer tools and IDE extensions, and developer machines with AI agent CLIs installed.

Part of
Workflow: Build an AppSec program. Collection: case studies
Learning goals and prerequisitesAbout 25 minutes: 10 to read and 15 for the exercise

What you will learn

  • Trace how a repository token in a pull request build became a malicious commit in a released extension, from AWS's own bulletins.
  • Separate AWS's statements from press reports about the injected prompt and how access was gained.
  • Scope CI credentials and pull request builds so contributor code cannot reach a write token.
  • Explain why code aimed at an AI agent's CLI is a payload multiplier, and how to limit what an agent on a developer machine can do.

Before you start

Platform engineers who run CI for public repositories, maintainers of developer tools and extensions, and teams that install AI coding agents

  • Know how a CI service builds pull requests and which credentials those builds can reach.
  • Know what an AI agent's command-line tool can do on a developer's machine.

Refresh first: Keep untrusted CI work outside the release boundary

Go to the guided practice

Malicious code in an AI coding assistant's release

Amazon Q Developer for VS Code is AWS's AI coding assistant extension, developed in the open in the aws/aws-toolkit-vscode repository. On 23 July 2025 AWS published security bulletin AWS-2025-015: in the course of investigating a separate CodeBuild issue (AWS-2025-016), it had determined that the extension "had an inappropriately scoped GitHub token in their CodeBuild configuration. With that access token, the threat actor was able to commit malicious code into the extension's open-source repository that was automatically included in a release." The affected version was 1.84.0. The repository's release record for amazonq/v1.84.0 is dated 17 July 2025, and the one for v1.85.0 is dated 19 July.

AWS says it revoked and replaced the credentials, removed the malicious code and released 1.85.0, and removed 1.84.0 from distribution channels. Because the code remained in existing installations, it told customers to remove every installation of 1.84.0, including forks and derivative copies, and published the SHA-256 of the affected build for checking. AWS published the matching advisory GHSA-7g7f-ff96-5gcw on 26 July and, as the CVE numbering authority, CVE-2025-8217 on 30 July.

How a pull request build exposed a write token

AWS-2025-016, "Memory Dump Issue in AWS CodeBuild", released on 25 July 2025, describes the technique. Researchers showed that a threat actor could submit a pull request that, if built automatically by CodeBuild, "could extract the source code repository (e.g. GitHub, BitBucket, or GitLab) access token through a memory dump within the CodeBuild build environment." If that token has write permission, the threat actor can commit code to the repository. AWS says it identified this technique "was leveraged by a threat actor who extracted the source code repository access token for the AWS Toolkit for Visual Studio Code and AWS SDK for .NET repositories."

The bulletin is blunt about the underlying problem: because builds execute code that contributors committed, "they have access to anything the build environment has access to." CodeBuild added protections against memory dumps in container builds that use unprivileged mode, but AWS still strongly recommends not using automatic pull request builds from untrusted contributors; for public repositories that want them, it recommends CodeBuild's self-hosted GitHub Actions runners feature, which it says is not affected. It lists three ways to stop automatic builds of untrusted pull requests: turn off webhook rebuilds, add a webhook event filter that excludes pull request events, or add an actor filter that allows only trusted users. It also recommends rotating write credentials exposed to such builds and revoking write permissions unless absolutely necessary.

Code aimed at an AI agent, stopped by a syntax error

The CVE record, written by AWS, describes what shipped: version 1.84.0 "contains inert, injected code designed to call the Q Developer CLI. The code executes when the extension is launched within the VS Code environment; however the injected code contains a syntax error which prevents it from making a successful API call to the Q Developer CLI." AWS-2025-015 says AWS Security inspected the code and found it "was distributed with the extension but was unsuccessful in executing due to a syntax error", which "prevented the malicious code from making changes to any services or customer environments." The CVE classifies it as CWE-506 Embedded Malicious Code, with a CVSS 4.0 base score of 5.1 and a CVSS 3.1 score of 4.0 from AWS as the CNA.

In other words, the attacker did not need an exploit for the developer's machine. The plan was to hand instructions to an AI agent that already ran with the user's permissions and, potentially, the user's cloud credentials, and let the agent do the work.

What comes from the press, not from AWS

AWS's bulletins, advisory and CVE record do not quote the injected instructions. BleepingComputer, crediting 404 Media's reporting, quoted part of the injected prompt as telling the agent its goal was "to clear a system to a near-factory state and delete file-system and cloud resources", and reported that the hacker gained access by submitting a pull request from a random account. Treat these as press reports: AWS's own account of access is the over-scoped CodeBuild token and the memory-dump technique above. OWASP's Agentic Top 10 cites the incident among its references for ASI04 Agentic Supply Chain Vulnerabilities.

Where the chain could have been broken

Each link in AWS's account maps to a control a team can check in its own CI and release process.

Where the chain could have been broken
Link in the chainControl
An untrusted pull request was built automaticallyNo automatic builds of untrusted pull requests; actor filters or a maintainer's approval first
The build environment held a repository token with write scopeRead-only, short-lived credentials for pull request builds; write credentials only in a separate release job
The token could be read from build memoryUnprivileged builds and isolation between the contributor's code and the credentials; assume anything the build can reach can be stolen
A commit was automatically included in a releaseProtected branches, required review of every change, and a person approving each release built from a reviewed commit
The payload targeted an AI agent CLI on users' machinesAgents keep permission prompts for destructive and cloud actions, run with scoped credentials and log what they do

Keep write tokens away from untrusted builds, and keep AI agents from acting alone

The bulletins describe a familiar CI failure; the payload is what makes it an AI security case.

  • Assume anything a pull request build can reach, the pull request's author can steal. Keep write and release credentials out of those builds entirely (/domains/supply-chain/ci-cd/ci-untrusted-workflows/).
  • Scope repository tokens to what the job needs, make them short-lived and rotate any that untrusted builds could reach.
  • Release only from a reviewed commit with a person approving; "automatically included in a release" is the step that turned a stolen token into shipped code.
  • Review prompt-like strings in code as code: text that instructs an agent is an executable payload when an agent will read it.
  • On developer machines, run AI agents with permission prompts on for destructive and cloud actions and with short-lived, scoped credentials, so a malicious instruction cannot act alone (/domains/ai-emerging/agent-security/ai-assisted-development/).
  • Publish hashes and clear version guidance when you withdraw a release, as AWS did, so users can find and remove the affected build.

Guided practice

Your team maintains an open-source VS Code extension that ships an AI assistant. CI builds every pull request automatically. After reading AWS's bulletins, review the setup and decide what to change.

Supplied scenario material
Plain text
CI project: extension-ci (hosted build service)
  Trigger: webhook on every pull request event, any author
  Source credential: GitHub personal access token of the release bot (scopes: repo, workflow)
  Build: npm ci && npm test && npm run package
  Main branch: protected, but the release bot is allowed to bypass protection
  Release job: runs nightly from main with the same credential; publishes to the marketplace automatically

Developer machines
  The assistant's companion CLI is installed and signed in to the cloud account with an administrator role

  1. 1. Find the chain

    Describe how an outside contributor could get code into a release.

    Expected result and reasoning

    Their pull request runs with the release bot's token, which has write and workflow scope. If the build can read it, as in AWS-2025-016, they can push directly to main through the bot's bypass, and the nightly job publishes it automatically, as with 1.84.0.

  2. 2. Fix CI

    List the changes to the build and release setup.

    Expected result and reasoning

    Stop automatic builds of untrusted pull requests or require a maintainer's approval; give pull request builds a read-only, short-lived credential; remove the bot's bypass; build releases from a reviewed tag in a separate job with its own credentials and a required human approval.

  3. 3. Limit the agent

    Say what to change on developer machines.

    Expected result and reasoning

    The CLI should prompt before destructive file, shell and cloud actions and use short-lived credentials scoped to what developers need, not an administrator role; its actions should be logged.

  4. 4. Plan the response

    If a malicious version shipped, what would you publish?

    Expected result and reasoning

    An advisory with the affected version, the fixed version, a hash of the bad build, instructions to remove it including forks, a CVE, and the credential rotation done, as AWS did.

Your deliverable: A description of the attack path, the CI and release changes, the agent settings for developer machines and an advisory outline.

The setup is fictional. Test CI changes in a private test repository; do not probe other projects' pipelines.

Save a draft on this device to resume later. Automatic saving begins after you choose Save. Drafts are never sent by this application; use synthetic data.

No draft saved on this device yet.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

  1. AWS-2025-015: Security Update for Amazon Q Developer Extension for Visual Studio Code (Version #1.84). 23 July 2025, updated 25 July 2025.
  2. AWS-2025-016: Memory Dump Issue in AWS CodeBuild. 25 July 2025.
  3. GHSA-7g7f-ff96-5gcw: Malicious script injected into Amazon Q Developer for Visual Studio Code (VS Code) Extension. 26 July 2025.
  4. CVE-2025-8217 (CVE record, AWS as CNA)
  5. aws/aws-toolkit-vscode release amazonq/v1.85.0
  6. BleepingComputer: Amazon AI coding agent hacked to inject data wiping commands (press report). 25 July 2025.
  7. OWASP Top 10 for Agentic Applications for 2026 (ASI04 Agentic Supply Chain Vulnerabilities). Version 2026, December 2025.

Reference information

Download this guide as Markdown