AWS reported that an attacker reached the Amazon Q Developer VS Code extension release path through a GitHub token with overly broad access in the CodeBuild configuration. The fix for any team is the same: give each build token the least access it needs, and review it on a schedule.
What AWS reported
The AWS bulletin for CVE-2025-8217 says malicious code was committed to the extension's open-source repository and automatically included in release 1.84.0. The entry point named in the bulletin is a GitHub token with overly broad access in the CodeBuild configuration. AWS revoked and replaced the credentials and shipped version 1.85.0.
The bulletin does not say more about how the token was obtained, and this post does not guess. The lesson holds regardless: a token that can write to a repository, and sits in a build system, is a path to your release.
Where overbroad tokens hide
- Build service settings. A personal access token pasted into a CI project years ago and never reviewed.
- Workflow permissions. A default that grants write access to every job.
- Shared service accounts. One credential used by many pipelines.
- Forks and pull requests. Jobs triggered by outside contributions that run with secrets.
A one hour audit
- List every token your CI can use. Include repository tokens, package registry tokens and cloud keys.
- Write down what each can do. Read, write, merge, release, publish.
- Match it to the job. A test job needs read. A release job needs publish rights, only on a protected branch.
- Remove or replace. Swap long-lived personal tokens for short-lived, scoped credentials where your platform supports it.
- Protect the release path. Require review on the branch that triggers publishing, and limit who can edit build configuration.
- Set an expiry. Rotate on a schedule so forgotten tokens die.
Separate the build from the publish
A common safe pattern: one job builds and tests with read access. A second job, gated by approval and running only on a protected ref, holds publishing rights. Anything an outsider can trigger should never see publish credentials.
For the GitHub side, see GitHub token permissions: set read only default. For fork and trigger risks, see pull request target versus pull request fork safety.
Why extensions raise the stakes
An editor extension runs on developer machines with access to source and credentials. If a release is tampered with, it reaches every machine that auto updates. That is why the release credential deserves the same care as a production secret. Read more in the 1.84.0 incident explained.
Safeguard can enforce policies and gates on pull requests and scan dependencies, and the free scan at gold.safeguard.sh/scan is a quick way to start.
Quick check
Does a read only token stop this kind of attack?
It removes the write path for that token. You still need protection on the branch and the publish job.
Is rotating tokens enough?
Rotation helps with forgotten tokens, but scope matters more. A fresh token with broad access is still broad.
Sources
Last reviewed: 19 October 2026.
