Amazon Q, Claude Code and MCP made repository text a supply-chain attack surface

Amazon Q, Claude Code, GitHub Copilot, Cursor, Jules and Windsurf have made source repositories part of the control plane. The relevant change is not that developers now receive code suggestions from a model. That was already enough to create quality and provenance problems. The sharper change is that AI-assisted development tools now read untrusted project text, reason over it, call tools, edit files, run commands and sometimes reach the network with the developer's ambient privileges.

That turns ordinary repository content into a supply-chain input. A malicious instruction hidden in a Markdown file is no longer just text. A poisoned issue, README, test fixture or generated file can become a steering signal for an agent that has access to secrets, terminals, package managers and internal services. The repository is no longer only something a developer builds. It is something the assistant interprets.

Embrace The Red's public writeups make the pattern concrete across current tools: Amazon Q remote code execution via prompt injection, Amazon Q DNS-based secret leakage, Amazon Q invisible prompt injection in the VS Code extension, Claude Code data exfiltration via DNS, GitHub Copilot remote code execution via prompt injection and Cursor arbitrary data exfiltration through Mermaid. The details vary, but the shape is consistent.

The software supply chain now includes language addressed to a machine that can act.

The old boundary no longer holds

Traditional supply-chain compromise normally needed code execution somewhere recognisable. An attacker poisoned a dependency, replaced a build artifact, compromised a maintainer account, abused CI credentials or shipped a malicious extension. The dangerous object was executable code, or at least something a toolchain treated as executable.

AI-assisted development weakens that assumption. The model consumes comments, documentation, commit messages, issue text, pull request descriptions, terminal output, log files and arbitrary project content. Those inputs may be treated as context rather than code, but they influence a system that can produce code and trigger tools. This is prompt injection in a development environment, with the important distinction that the model is standing next to the keys.

That matters because repositories are full of attacker-controllable text. Open-source projects accept issues and pull requests. Internal repositories ingest tickets, generated reports, copied stack traces, vendor snippets, dependency metadata and documentation from outside the organisation. A developer asking an agent to "review this PR", "fix this failing test" or "summarise the issue and implement it" may unintentionally grant untrusted prose a path into the assistant's decision loop.

The supply-chain object has therefore changed. It is not only the package installed by npm, pip or cargo. It is the instruction substrate around the package. A malicious maintainer does not always need to hide code in a dependency if the target's assistant can be persuaded to write the code, run it or disclose the token required to publish it.

Amazon Q shows the shape of the workstation risk

The Amazon Q findings are useful because they cover three different parts of the same problem: remote code execution through prompt injection, secrets leaked through DNS and invisible prompt injection in the VS Code extension.

Remote code execution is the familiar endpoint. If a prompt injection can cause an assistant to create or run commands, the AI layer becomes another route to the same class of workstation compromise defenders already understand. The difference is how the payload reaches the system. It does not need to arrive as a suspicious binary. It can arrive as instructions embedded in content that the assistant was expected to read.

DNS-based secret leakage is the more instructive pattern. It treats the network as a covert output channel. A model or tool does not need a full HTTP exfiltration primitive if it can influence lookups such as <secret>.attacker.example. Developer environments are unusually rich targets for this because they commonly hold cloud credentials, package registry tokens, SSH keys, source access tokens and ephemeral credentials minted by single sign-on flows.

Invisible prompt injection completes the triad. Hidden Unicode, styling tricks and otherwise non-obvious text can be read by the model without being meaningfully visible to the developer. That breaks the normal human review assumption. The user thinks they are asking the assistant to process a file or page whose contents they understand. The assistant may be receiving a different effective document.

A secure design cannot rely on the developer noticing hostile instructions if the interface can present one document to the human and another to the model. The review surface has split.

The CVE records show measurable severity

Claude Code's CVE-2025-55284, described by NVD as a confirmation-prompt bypass that could read a file and send its contents over the network, is rated CVSS 4.0 7.1 High and CVSS 3.1 7.5 High in the NVD entry. The description is narrow but important. Reliable exploitation requires the ability to place untrusted content into a Claude Code context window. That is not an exotic precondition for a coding agent that reads repositories, issues, copied logs and documentation.

GitHub Copilot's CVE-2025-53773 is listed by NVD as improper neutralisation of command elements in GitHub Copilot and Visual Studio, allowing local code execution. NVD rates it CVSS 3.1 7.8 High in the CVE record. Embrace The Red's writeup frames the practical trigger as prompt injection, which is the relevant part for supply-chain modelling: attacker-controlled text can cross into command execution through the assistant path.

Cursor's CVE-2025-54132 is listed by NVD as Mermaid-based data exfiltration after prompt injection, with sensitive information leaving through an image fetch. The NVD record currently shows two CVSS 3.1 assessments from different sources: 4.4 Medium and 7.5 High. That split is itself useful. Scoring depends on assumptions about privileges, interaction and reachable data, while the architectural lesson is less ambiguous. A rendering feature inside an AI coding workflow can become an exfiltration channel when the model can be steered by hostile context.

The CVSS numbers do not make these flaws interchangeable. They do make one editorial point harder to dodge: this is not merely a theoretical prompt-injection genre. Public vulnerability records now describe coding assistants and adjacent developer tools as paths to local code execution or data exfiltration.

Claude Code and DNS exfiltration make agent behaviour observable to attackers

Claude Code's DNS exfiltration case demonstrates the same asymmetry in a product designed for agentic software development. Agents sit close to secrets because useful development work requires context. They inspect repositories, read configuration files, run tests, parse errors and sometimes invoke tools that inherit local environment variables.

The attacker's problem is therefore not always privilege escalation. It is instruction capture. If a malicious input can get the agent to read a sensitive file or environment value, the remaining question is how to move the data out. DNS is attractive because it is ubiquitous, noisy enough to blend in and often less scrutinised than HTTP egress from developer machines.

This is not a Claude-specific lesson. It applies to any tool that gives a model access to local context and then permits network-visible side effects. A build error copied from a public issue, a poisoned README in a cloned repository or a malicious instruction inside a dependency's documentation can all become candidate sources. Once the agent is allowed to connect reading with acting, exfiltration becomes a workflow problem rather than an exploit chain in the classical sense.

The uncomfortable part is that successful exploitation may look like normal assistant use. The developer asked for help. The assistant inspected files. A lookup happened. Nothing crashed. No malware needed to persist. The system did the work it was designed to do, but for the wrong principal.

Repository manipulation is the new dependency confusion

Dependency confusion exploited naming and resolution rules. Attackers published packages that build systems would select by mistake. Repository manipulation for AI agents exploits interpretation rules. Attackers place instructions where assistants will read them and depend on the agent to resolve authority incorrectly.

The primitive can be simple. A malicious issue says a test must be fixed by running a diagnostic command. A pull request includes a hidden instruction telling the assistant to read .env before reviewing the diff. A README contains invisible text directing the model to add a post-install hook. A generated file includes a comment that appears harmless to the developer but is specific enough to steer the agent. A Mermaid diagram abuses rendering or parsing behaviour, as reflected in Cursor's CVE-2025-54132 for arbitrary data exfiltration via Mermaid.

The agent's context window becomes the resolver. It must decide which text is instruction, which text is data, which text is adversarial and which authority each fragment should have. Current systems have repeatedly failed at that distinction because language models are designed to follow instructions, not to enforce security labels across mixed-trust input.

This is where supply-chain language is precise rather than metaphorical. The attacker may never touch the dependency graph. Instead, they poison the repository state that downstream developers and assistants consume. The compromised artifact is the development conversation itself.

Copilot, Cursor, Jules and Windsurf show this is not one vendor's bug

Embrace The Red also describes Google Jules data exfiltration, Google Jules invisible prompt injection, Jules remote-control behaviour, Windsurf memory-persistent data exfiltration and Windsurf MCP control gaps. OpenHands appears in the same research stream with prompt injection leading to remote code execution and access-token exposure.

That spread matters. If the failures were confined to one extension, the response would be ordinary patch management. The evidence instead points to a product category struggling with a shared design problem: development assistants are being given tool access before the trust model for their inputs is mature.

The products differ in interface and ambition. Some present as pair programmers. Some operate as autonomous coding agents. Some run in VS Code. Some integrate deeply with browsers, terminals or repository hosts. Yet the same attack primitives recur: indirect prompt injection, hidden instructions, file API abuse, tool-mediated exfiltration, remote code execution and memory or context persistence across sessions.

A product can patch one vulnerable parser or one unsafe command path. That does not remove the class. Any assistant that ingests untrusted content and can trigger privileged actions needs a policy layer that the model cannot rewrite. The model should not be the component deciding whether an instruction from a README is allowed to read a secret. That decision belongs in a smaller, stricter system with explicit labels and enforceable capability boundaries.

MCP turns local context into shared infrastructure

Model Context Protocol adds a second layer to the problem. It standardises how AI applications connect to tools and data sources. That is useful, which is why adoption is fast. It also means that an assistant's reach can expand from repository files to Slack, browsers, databases, ticketing systems, shells and cloud APIs through a common interface.

Embrace The Red's Anthropic Filesystem MCP Server directory-access bypass and Anthropic Slack MCP Server data exfiltration advisory fit the broader pattern. The agent is no longer only reading code and suggesting edits. It is mediating access across systems that were never designed to treat natural-language context as an authorisation boundary.

MCP tool descriptions are especially sensitive because they are instructions to the model about how tools should be used. If an attacker can influence those descriptions, or if a malicious server can present a benign tool with hostile hidden instructions, the model may treat the tool's own text as authoritative. Users often see a tool name and a short confirmation prompt, not the full instruction surface that shaped the model's behaviour.

The danger is compositional. A filesystem server can read. A Slack server can send. A browser server can visit. A shell server can execute. Each tool may appear acceptable alone. Combined through an agent that shares context between them, they form an exfiltration pipeline. The chain does not need a memory corruption bug. It needs the model to connect the steps.

What defenders should change

The first defensive shift is to treat AI assistants as execution surfaces, not productivity widgets. If a tool can read files, call APIs, run commands or open network connections, it belongs in the same risk category as other developer automation. It needs least privilege, audit logs, egress controls and explicit approval boundaries.

Second, untrusted repository text should be labelled and handled as data. An assistant reviewing a pull request should not be allowed to treat the pull request body, comments or changed documentation as privileged instruction. The model needs a hard separation between developer intent and repository content. Prompt wording alone is not enough because the adversarial input is also prompt wording.

Third, tool access should be narrow by default. A coding assistant does not need blanket access to the home directory to fix a unit test. It does not need cloud credentials to explain a stack trace. It does not need outbound DNS in every workflow. Where network access is required, egress should be observable and constrained.

Fourth, MCP servers and similar plugins should be pinned, reviewed and isolated. Installing a server should be treated more like installing a local binary than enabling a theme. Organisations should maintain an allowlist, pin versions, inspect tool descriptions, monitor changes and avoid connecting high-risk tools into the same agent session. A Slack sender and a filesystem reader in the same context is a ready-made leakage path.

Fifth, secrets should be kept away from the assistant's default reach. Environment variables, dotfiles, package tokens and cloud credentials are convenient for humans and scripts. They are also exactly what an injected instruction will ask the model to read. Short-lived scoped credentials and per-task sandboxes reduce the value of a successful prompt injection.

Finally, vendors need to stop presenting user confirmation as a complete defence. A confirmation dialog that hides the relevant prompt, truncates parameters or fails to show derived network effects is not meaningful consent. The user cannot approve what the interface does not show.

The supply-chain boundary moved again

The recurring mistake in software supply-chain security is assuming the boundary has stabilised. First the risk was source code. Then it was dependencies. Then build systems, CI tokens, package registries, maintainers, IDE extensions and developer workstations. AI-assisted development tools move it again, into the text that surrounds the work.

That is what makes this class awkward. The vulnerable surface is not only a parser, protocol or package. It is the habit of treating repository content as harmless until compiled. Agents invalidate that habit. They can read the harmless thing, believe it, translate it into a command and execute the result under a trusted identity.

The cheapest supply-chain attack has always been the one that uses the victim's own process. AI coding agents offer a new version of that old bargain: poison the instructions, let the trusted tool do the rest.