Amazon Q for VS Code: a drive-by pull request put a data-wiping prompt into a coding agent with nearly a million installs

What happened

In mid-July 2025 an unauthorised contributor got malicious code into Amazon's open-source aws-toolkit-vscode repository, the codebase behind the Amazon Q Developer extension for Visual Studio Code, an AI coding agent. AWS's own account of how is the important part. Its security bulletin states the extension "had an inappropriately scoped GitHub token in their CodeBuild configuration," which let a threat actor "commit malicious code into the extension's open-source repository that was automatically included in a release." The attacker, speaking to 404 Media, described it more colourfully: they opened a pull request "from a random account with no existing access" and were "given admin credentials." The compromised code shipped in the extension's marketplace release, version 1.84.0, in mid-July 2025 (reporting places the release at 17 to 19 July; AWS's bulletin does not give the date). AWS removed 1.84.0 from distribution and shipped a clean version, 1.85.0, about two days after the release (The Register), then published its security bulletin on 23 July, updated 25 July. The exact dates vary across reports; the compromised build was in the marketplace for a matter of days.

The injected content was a prompt aimed at Amazon Q's agent. As reported, it instructed the agent to delete all non-hidden files from the user's home directory and then to discover the user's AWS profiles and delete their cloud resources through the AWS CLI. The script passed the prompt to the Q CLI with --trust-all-tools and --no-interactive set: the agent authorised to run any tool, with no human confirmation step. Some coverage quotes the prompt's goal as clearing "a system to a near-factory state" and logging progress to /tmp/CLEANER.LOG.

It did no damage. AWS's security bulletin is specific about why: "the malicious code was distributed with the extension but was unsuccessful in executing due to a syntax error," and "this prevented the malicious code from making changes to any services or customer environments." The person responsible told reporters the wiper was "designed to be defective" as a protest; AWS attributes the non-execution to the syntax error. Either way, the destructive instruction never ran.

The attacker's stated motive was to embarrass the vendor: to expose what they called AWS's "security theatre" and, in their words, the way "ruthless corporations leave no room for vigilance among their overworked developers."

The duty engaged

The value here is in what it isolates: the supply-chain security duty underneath every AI agent a business installs. No personal data was touched, so the duty shows up uncluttered.

Security of processing (GDPR Article 32), had it fired. Run the counterfactual. Had the prompt executed against a developer handling personal data, deleting their files and cloud resources, it would have been a catastrophic availability breach. Article 32 binds controllers and processors. The deploying organisation, as controller of the data on the developer's machine, would have carried that duty, and could not discharge it by pointing at a vendor; whether AWS shared it turns on whether it acted as a processor here, which the public record does not establish. The clean lesson here is causal: the failure that would have caused the breach originated in the vendor's release pipeline, out of reach of any deploying organisation's own configuration.

The agent-authorisation question. The malicious script did not rely on the developer's own settings. It invoked the Q CLI with --trust-all-tools and --no-interactive itself, so anyone who ran the compromised extension got an agent authorised to run any tool with no confirmation, whether or not they had ever chosen that posture. The supply-chain compromise was the delivery mechanism; the caller-supplied auto-execute flags were what would have turned a bad string into a wiped machine. The design lesson is that an agent must not honour a caller's request to trust all tools and skip confirmation for destructive operations. AWS reached the same conclusion: it moved Amazon Q Developer and Kiro to require human confirmation before affected commands run, a change disclosed in October 2025 (bulletin AWS-2025-019).

Contract and the software-supply-chain expectation. The deploying organisations installed an official extension from a trusted marketplace, published under Amazon's own publisher account. Their security expectation was that the vendor controls what ships under its name. That is exactly what failed: an official release carried code from a contributor with no legitimate access.

The liability chain (conditional)

No harm occurred, so this is an allocation sketch. Had the wiper executed against a real tenant:

The vendor (AWS) bears the structural exposure. The vulnerability was entirely within its own process: an over-scoped build token let a commit from a contributor with no legitimate access reach an official marketplace release under Amazon's name. As with the EchoLeak near-miss (AIR-2026-004), the deploying organisations had nothing to patch and no configuration to correct; the failure and the fix were both the vendor's. The strongest fact in AWS's favour is the one that obtains: no customer environments were affected, and AWS moved quickly — it removed 1.84.0 and shipped the clean 1.85.0 about two days after the compromised release (The Register), before publishing its bulletin on 23 July.

The deploying organisations were bystanders, mostly. A developer who installed the official extension from the marketplace did nothing wrong, and because the malicious script set the auto-execute flags itself, a developer's own tool-trust settings would not have stopped this attack. The controllable choices on the deployer side are elsewhere: pinning versions and staging updates rather than auto-installing the newest marketplace release, and constraining blast radius through least-privilege cloud credentials so that even an executed wiper reaches little. This is the only material deployer-side responsibility; the rest is vendor-side.

The individual who injected it bears primary responsibility for the unauthorised change, whatever the stated motive; "we were exposing your bad security" is no defence to tampering. As with other agent-credential incidents, the wrongdoer is the party against whom recovery is least practical, so governance has to concentrate on the controllable links: the vendor's release pipeline and the deployer's update-staging and credential scoping.

What would have prevented it

• Gate who can merge to a production release. The root failure was a contributor with no existing access getting a malicious commit into a production build. Branch protection, mandatory review by trusted maintainers, and no auto-granting of credentials are the controls whose absence produced this.
• Keep a confirmation step the agent will not silently surrender. Here the malicious script supplied --trust-all-tools --no-interactive itself, so a confirmation step protects anyone only if the agent enforces it for destructive operations regardless of caller-supplied flags. For any agent that can touch a filesystem or cloud credentials, that non-negotiable confirmation is the floor.
• Constrain the agent's blast radius. Least-privilege AWS profiles, no standing delete permissions on the developer's default credentials, and separation between the coding environment and production cloud access all shrink what a compromised agent can reach.
• Version-pin and stage vendor updates. Auto-updating an agentic extension to the newest marketplace release the moment it ships is the pattern that exposed the install base at once. Pinning plus a short soak period would have caught a release that was in the wild for days before it was pulled.

Mapped controls

• OWASP Top 10 for Agentic Applications 2026: ASI04 Agentic Supply Chain (primary): the agent vendor's own build and release pipeline was the poisoned component, propagating a malicious instruction to every downstream install. The delivery was a supply-chain compromise — the shipped build carried the payload — so ASI06 (which covers runtime memory and context poisoning) is a poor fit. The harm would have been realised by the caller-supplied --trust-all-tools invocation, unbounded tool authorisation with no confirmation step; the 2026 list carries no dedicated excessive-agency category, and the nearest fit is ASI02 Tool Misuse and Exploitation.
• NIST AI RMF: a GOVERN failure at the vendor (no effective control over who can commit to a production release) and a MANAGE failure on the deployer side wherever agents run with unrestricted tool-trust and no update-staging.
• The general rule the incident stands for: the pipeline that ships an agent and the tool-trust it runs under both decide whether it can be relied on. With the Salesloft Drift supply-chain breach (AIR-2026-002) and the EchoLeak vendor-side near-miss (AIR-2026-004), this is the register's third study of a failure the deploying organisation could not have patched, and its clearest example of "trust all tools" as an explicit governance choice.

Sources

• AWS Security Bulletin, "Security Update for Amazon Q Developer Extension for Visual Studio Code (Version #1.84)" (AWS-2025-015), published 23 July 2025, updated 25 July 2025 — root cause ("an inappropriately scoped GitHub token in their CodeBuild configuration"), remediation, and the verbatim non-execution finding — checked 18 July 2026 [primary]
• GitHub Security Advisory GHSA-7g7f-ff96-5gcw, "Malicious script injected into Amazon Q Developer for Visual Studio Code (VS Code) Extension" (CVE-2025-8217), aws/aws-toolkit-vscode — affected 1.84.0, patched 1.85.0 — checked 18 July 2026 [primary]
• The Register, "Compromised Amazon Q extension told AI to delete everything – and it shipped" (Tim Anderson), 24 July 2025 — confirms the --trust-all-tools and --no-interactive flags, dates 1.84.0 to 19 July with 1.85.0 "two days later", and describes the injected instructions — checked 18 July 2026
• BleepingComputer, "Amazon AI coding agent hacked to inject data wiping commands" (Lawrence Abrams), July 2025 — source for the install count ("nearly one million installs" / 964,000+) and the 17 July release date — checked 18 July 2026
• AWS Security Bulletin AWS-2025-019, "Amazon Q Developer and Kiro – Prompt Injection Issues in Kiro and Q IDE plugins", 7 October 2025 — the later, distinct prompt-injection findings whose fix requires human confirmation before affected commands run — checked 18 July 2026 [primary]
• 404 Media, "Hacker Plants Computer Wiping Commands in Amazon's AI Coding Agent" — the attacker's own account of obtaining access and the "designed to be defective" claim (behind a paywall, so quoted only where corroborated) — checked 18 July 2026

Corrections

• 18 July 2026 (same day as publication, following two further top-to-bottom and bottom-to-top adversarial due-diligence passes): four points were tightened against the sources. (1) The ~1 million figure is the extension's reported marketplace install count (BleepingComputer: nearly a million installs), now cited and described as installs rather than distinct developers. (2) The fix timeline was re-anchored: version 1.85.0 shipped about two days after the compromised release (The Register), before AWS's 23 July bulletin; an earlier draft implied a same-day response to a 23 July flag. (3) "Signed" was softened to "official" throughout, as no source confirms the 1.84.0 release was cryptographically signed. (4) The AWS-2025-019 follow-up is now dated as disclosed October 2025 and added to the sources, and the secondary OWASP mapping was corrected (the caller-supplied auto-execute flags have no clean category in the 2026 list; nearest is ASI02). The substance of the analysis is unchanged.

Cite this entry as AIR-2026-007 (https://companyscope.io/register/air-2026-007). Entry IDs are stable; corrections publish as dated addenda on this page.

This analysis is the work Janus Compliance does for clients before the incident. For a fixed-scope read of your own EU AI Act Article 50 exposure, see the Article 50 teardown; for ongoing agent governance, Janus DPO-as-a-Service. Browse the full register or the vendor compliance index.