Malicious PR Nearly Turned AI Tool Into a Wiper

How the attack worked

On July 13, 2025, a GitHub user submitted a pull request to Amazon's public aws-toolkit-vscode repository. The change looked unremarkable, reusing the title of a prior legitimate commit. In reality, it downloaded an external file at build time and spliced a new prompt into the extension's packaging script. That prompt instructed the AI coding agent to wipe the system to a near-factory state and delete file-system and cloud resources. The script passed the prompt directly to the command-line interface with flags set so the agent would not need further approvals before executing. The update shipped within days to nearly a million VS Code extension installs before the destructive instructions failed to run due to a formatting error.

Why it nearly succeeded

The pull request exploited two weak points at once. First, it relied on a human review gap: a routine-looking contribution from an unfamiliar account, recycling a legitimate commit title, is the kind of pattern a reviewer might miss without deliberate scrutiny. Second, it exploited a technical gap: an overly-permissive GitHub access token sitting inside the build and release service allowed the malicious code to be packaged into an official release. Once merged, the change moved through the normal build pipeline and was distributed to users through the marketplace like any other update.

What defenders should watch for

• Pull requests from unfamiliar or new contributors, especially ones that reuse titles or wording from earlier legitimate changes.
• Build or packaging script modifications that add external file downloads at build time.
• Automation or CLI flags configured to bypass additional approvals before executing commands.
• Prompts or instructions embedded in code that direct an AI agent toward destructive actions such as deletion or wiping.

Building resistance

Amazon confirmed the malicious code did not successfully execute in a customer environment, revoked the attacker's credentials, removed the code, and shipped a clean build within two days. Beyond incident response, the case points to durable defenses: treat pull requests as a social-engineering surface, not just a code-quality checkpoint, and scrutinize intent rather than syntax alone. Require independent policy evaluation and human-in-the-loop confirmation for any destructive action, regardless of whether it comes from careful reasoning or an injected prompt. Apply least privilege and short-lived credentials to CI/CD tokens so a single overreaching credential cannot turn a code change into a mass-distributed release. Finally, flag unexpected build-time downloads and packaging-script edits as high-risk items deserving deeper review before merge.

What happened in the aws-toolkit-vscode incident?

A GitHub user submitted a pull request to Amazon's public aws-toolkit-vscode repository that shipped within days to nearly a million VS Code extension installs. The update injected a destructive prompt into the packaging script meant to wipe systems and delete file-system and cloud resources, but it failed to execute due to a formatting issue.

How did the malicious code get approved and shipped?

The root cause was an overly-permissive GitHub access token in the build and release service, which allowed the malicious code to be packaged into an official release without being caught.

Did the attack actually cause damage?

Amazon confirmed the malicious code did not successfully execute in a customer environment. Amazon revoked the attacker's credentials, removed the code, and shipped a clean build within two days.

What can teams do to prevent similar attacks?

Treat unfamiliar pull requests as a social-engineering risk rather than only a code-quality task, require human-in-the-loop confirmation for destructive actions, lock down CI/CD tokens with least privilege and short-lived credentials, and flag build-time downloads or packaging-script changes for extra review.