Prompt injection in the wild: DUSTMAKER targets coding assistants

Google Threat Intelligence Group has reported prompt-injection functionality in DUSTMAKER, credential-stealing malware used by UNC6780, also known as TeamPCP. Its 8 September 2026 report describes malicious workspace configuration that instructs coding assistants to run commands, alongside comments in malware loaders aimed at disrupting LLM security analysis.

The findings connect a prompt injection attack to an observed software supply-chain campaign. They also require care about outcomes: GTIG identifies functionality in malware samples, while describing the scanner-disruption technique's purpose as likely attacker intent. The report provides no measured success rate for either technique across developer tools.

How DUSTMAKER reaches the developer workspace

GTIG attributes a series of supply-chain compromises across PyPI, npm and Docker Hub to UNC6780 since March 2026. The group compromises software distribution paths, deploys credential stealers and monetises stolen data or access. The report describes compromised developer accounts used to distribute trojanised MCP servers and malicious code placed directly into legitimate organisational repositories.

Within a developer environment, DUSTMAKER drops or modifies files in hidden project directories used by coding assistants and IDEs, including .claude/, .vscode/ and .cursor/. Those locations can contain configuration that tools load during ordinary work. GTIG describes the malware using them both for automatic build or startup execution and for instructions addressed to an AI assistant.

These mechanisms need separate checks. An executable startup hook can launch a process through the IDE's configuration handling. A prompt-injection instruction relies on the assistant interpreting text and selecting an action. A workspace review needs to examine both executable configuration and the instructions supplied to the model.

When repository content becomes assistant authority

Coding assistants use project instructions to learn build commands, test conventions and local working rules. That makes the origin and review of those instructions consequential. An attacker who controls part of the workspace can put an instruction where the assistant expects project guidance.

GTIG describes DUSTMAKER configuration directing assistants to run arbitrary commands or scripts during routine developer interactions. The trust boundary is crossed when attacker-controlled repository text gains the authority to choose a local operation under the developer's permissions.

The chain has four parts:

1. The attacker controls workspace content. A compromised package or repository brings malicious files into the development environment.
2. The tool loads project context. Workspace instructions enter the assistant's context alongside legitimate code and guidance.
3. The assistant interprets an instruction as work to perform. The attacker attempts to make command execution appear part of the development task.
4. An execution boundary decides the effect. Shell permissions, sandboxing, approvals and action policy determine what the proposed operation can reach.

Reading a repository grants access to information. Permission to execute its instructions needs a separate decision. A familiar directory name, plausible setup task or established package identity offers context, but cannot establish that every instruction inside the workspace is authorised.

Our prompt injection guide explains this distinction between trusted instructions and untrusted content. The Amazon Kiro disclosure shows a related chain in a controlled demonstration: repository content influenced local file access, a configuration change and an outbound request. DUSTMAKER places workspace instruction manipulation in the context of malware used in supply-chain operations.

Loader comments target the security scanner

The second technique targets a different reader. GTIG found adversarial comments at the top of DUSTMAKER's JavaScript loaders. The text invokes prohibited subject matter, apparently to provoke a safety refusal from an LLM asked to analyse the code below it.

Here, the attacker-controlled input is the file under inspection. The authorised task is security analysis. If the scanner treats comments in that file as instructions governing its own response, the analysed material can interfere with the analysis.

GTIG describes causing scanners to fail or skip analysis as the likely intent. It does not publish a scanner-by-scanner test, bypass rate or demonstrated clean verdict caused by those comments. Its separate statement that the activities triggered Gemini safety responses does not establish a successful bypass of a security scanning pipeline.

For teams operating LLM-assisted review, the practical question is what happens after a refusal. A refused, interrupted or incomplete scan needs an explicit unresolved state and a route to further analysis. A pipeline that records only whether a model returned text can lose the distinction between completed inspection and an unexamined file.

What security teams can check now

The following controls address the boundaries described in the report:

• Review workspace instructions before execution. Include hidden directories, assistant rules, IDE tasks and startup hooks in review. Check changes to those files with the same care as build scripts and CI configuration.
• Open unfamiliar projects with limited authority. Use isolated environments, minimise accessible credentials and require review before enabling automatic setup or broad shell access.
• Inspect the complete proposed action. Check the command, arguments, working directory, files and network destinations. A task label such as setup cannot express those effects.
• Keep repository content subordinate to policy. Project instructions should have no authority to weaken tool approvals, expand permissions or change organisation security rules.
• Record scan completion explicitly. Separate a completed analysis from a refusal, timeout or parsing failure. Route unresolved files to another analysis method or a security reviewer before approval.
• Investigate suspected compromise beyond the instruction file. Review package provenance, credential exposure and CI changes. Removing malicious text alone leaves other malware functionality and stolen credentials to address.

The SiYuan MCP file-upload case illustrates why the operation and its arguments matter. Its sensitive-file boundary required enforcement even when a user could see and approve the tool call. The same review principle applies when workspace text asks a coding assistant to execute a command.

Google's response and the remaining boundary

Google reports disrupting the campaigns, disabling associated assets and strengthening Gemini's classifiers and model safeguards against misuse. The report links to its open-source supply-chain mitigation guidance.

GTIG states no CVE for these DUSTMAKER techniques and identifies no universal fixed version covering all coding assistants or LLM scanners. Google's response concerns its own services and the campaigns it investigated. Teams still need to evaluate how their developer tools load workspace instructions and handle incomplete security analysis.

Promptective applies organisation policy on supported AI interaction and action paths. The relevant checkpoint is the proposed operation: what the assistant wants to execute, which resources it would access and whether policy permits that action. Our AI agent security overview explains that approach. The DUSTMAKER reporting establishes the threat pattern; evaluating a particular integration requires testing its own action boundary.

The lasting lesson is to make authority explicit. Repository instructions can help an assistant understand a project. Security policy must govern the actions that follow, and analysis pipelines must account for files they have yet to inspect.

Sources

• Google Threat Intelligence Group, “GTIG AI Threat Tracker: From Prompting to Autonomy – The Evolution of Adversarial AI”, published 8 September 2026. The UNC6780 section and Tables 1 and 2 describe the supply-chain vectors and DUSTMAKER functionality.