AWS Toolkit disclosure requires token exposure checks, not upgrade evidence alone

AWS disclosed that older AWS Toolkit for Visual Studio Code versions left CodeCatalyst bearer tokens in world-readable files and retained them after sessions, exposing cloud credentials to local users or processes.

By Security.io Intelligence Desk · Published Friday, 9 October 2026

Why it is in today’s brief

AWS's new bulletin discloses an older fixed condition, but the disclosure itself changes today's enterprise decision: teams now know that pre-4.10.0 sessions could leave reusable CodeCatalyst bearer tokens readable after use. It warrants inclusion over higher-scored but less privileged bugs because upgrade compliance alone cannot resolve possible historical cloud-credential exposure on developer endpoints.

Read first

AWS says AWS Toolkit for Visual Studio Code versions below 4.10.0 cached CodeCatalyst bearer tokens with world-readable permissions and failed to remove the files when sessions ended. Version 4.10.0 corrected permissions and deletion behaviour.

Act now

Inventory AWS Toolkit versions on managed and unmanaged developer endpoints.

Accountable owner

Head of application security, with developer platform, endpoint security and cloud identity owners.

Decision horizon

Complete endpoint inventory and residual-file search within 48 hours; invalidate affected sessions immediately when exposure evidence is found.

AssessmentHigh confidence

Emerging riskWatch for AWS revisions, evidence of token reuse, additional affected storage locations, telemetry guidance or expansion to forked and derivative extension builds.

What happened

AWS published bulletin 2026-129-AWS on October 8, 2026. Versions of AWS Toolkit for Visual Studio Code below 4.10.0 cached a CodeCatalyst bearer token in a world-readable file and did not remove it after the development session ended. A local user or process with file-system access could read the file and obtain the token.

Version 4.10.0, released on July 9, 2026, changed the cache to owner-only permissions and deletes it when the Dev Environment stops. AWS recommends upgrading to the latest version and ensuring forks or derivative code incorporate the correction.

AWS told users unable to upgrade to delete files named codecatalyst..token from the extension’s Visual Studio Code global storage directory after each session. The cited sources did not publish indicators of token misuse, victim counts or evidence of active exploitation.

Why this matters now

The bulletin concerns a developer endpoint, but the exposed object is a bearer token for a cloud development environment. Any local user or process able to read the cached file could obtain that token without defeating AWS authentication directly. Shared workstations, multi-user systems, compromised developer endpoints and broadly privileged local tooling therefore deserve priority.

The fix had existed for several months before the public security bulletin. Enterprises cannot assume normal extension auto-update behaviour produced complete coverage, particularly across pinned development images, offline systems, remote workstations, forks or derivative builds. The decision requires both a version inventory and a search for artefacts left by earlier sessions.

This is an identity-containment issue as well as a patch issue. Upgrading prevents the documented caching behaviour going forward, but it does not prove that previously readable token files were absent, unread or unused. Endpoints with residual files need a documented session and access review before closure.

The decision for security leaders

Application security should own version discovery across managed developer images, while endpoint security searches historical and current global-storage locations. Cloud identity owners should define what evidence of a residual file requires session invalidation, access review or incident escalation.

Do not close the issue from marketplace deployment statistics alone. Confirm the running extension version on endpoints, identify pinned or forked builds, and account for contractors, virtual desktops and development hosts outside standard software-distribution coverage.

Where a residual token file is found, preserve its metadata before deletion, identify the associated user and session, review relevant access activity and document the disposition. The investigation should remain proportionate to the token’s reachable CodeCatalyst resources and the endpoint’s local compromise risk.

Evidence of closure

Endpoint inventory shows no AWS Toolkit installation below version 4.10.0.
File searches find no residual codecatalyst..token files after sessions.
Sessions associated with discovered token files have an approved disposition.
Managed developer images enforce the approved extension version.

The Security.io assessment

The vulnerability sits at the boundary between endpoint security and cloud identity. A readable bearer token can transfer an already authenticated session to another local process or user, so organisations that treat developer tooling as low-risk workstation software may miss the actual privilege represented by the artefact.

The delayed public bulletin increases the importance of historical exposure review. Version 4.10.0 may already be common, but current compliance cannot prove that older sessions left no readable files or that a local process never accessed them. Closure therefore needs artefact and session evidence in addition to the installed version.

The cited sources did not publish indicators of token misuse, victim counts or evidence of active exploitation. Attribution posture: AWS named no actor, and the cited sources do not establish exploitation of the exposed token files.