On June 25, 2026, researchers at Mozilla's Zero Day Investigative Network (0DIN) published a proof-of-concept attack showing that a completely clean-looking GitHub repository can trick AI coding agents such as Claude Code into silently opening a reverse shell on a developer's computer. Not a single line of malicious code appears anywhere in the repository.

The result, according to the research, is a fully interactive shell running with the developer's own privileges—and access to whatever secrets sit in that environment, from an ANTHROPIC_API_KEY to an AWS_SECRET_ACCESS_KEY or a GITHUB_TOKEN. From there, an attacker can reach source code, cloud accounts, and customer data.

The technique is important on its own. But the bigger lesson for Canadian and US business leaders is what it reveals about shadow AI—the unsanctioned, unmonitored AI tools your employees are almost certainly already running. This attack only works because a powerful AI agent acts on instructions no human ever reviewed.

What is the new Claude Code attack?

The attack is a form of indirect prompt injection: malicious instructions hidden in content the AI agent reads and acts on, rather than typed by the user. The researchers built an ordinary-looking project repository, pointed an AI coding agent at it, and let the agent follow the setup steps a developer would normally trust it to handle. No human ran a suspicious command on purpose.

Prompt injection, in plain terms, is the AI equivalent of social engineering. Instead of tricking a person into clicking a link, the attacker tricks the AI assistant into carrying out an instruction buried in a file, a README, or an error message it was simply trying to be helpful about.

Mozilla's researchers were clear that this is not unique to one product. They flagged the indirect prompt-injection risk as affecting any agentic coding tool that autonomously follows setup steps—naming Cursor and Google's Gemini CLI alongside Claude Code. Claude Code was the demonstration vehicle, not the sole vulnerable tool.

How does the attack actually work?

The attack chains together three things that each look harmless on their own: a trusted AI agent, routine error handling, and DNS-based payload delivery. Here is the sequence in plain English.

  1. The bait. The repository's README contains normal-looking setup instructions. A Python package in the project is engineered to fail the first time it runs, and the failure message directs the user to run an initialization command to "fix" it.
  2. The handoff. Running that init command calls a setup script (setup.sh). Because an AI coding agent is designed to be helpful and resolve errors on its own, it can run this step autonomously as part of getting the project working.
  3. The hidden payload. The script pulls a value from a DNS TXT record the attacker controls, decodes it from base64, and executes it. That spawns an interactive reverse shell back to the attacker.

The clever, dangerous part is where the payload lives. It is never stored in the repository. It sits in a DNS record—the same kind of internet plumbing that translates a domain name into an address—which the attacker can change at any moment. Because the payload is base64-encoded and fetched only at runtime, no reverse-shell signature ever appears in plaintext in the code, on disk, or in a way that a static security scanner, a human reviewer, or even the AI agent would flag.

In other words: the code you review is genuinely clean. The malicious instruction arrives later, from somewhere else, and runs with the agent's full permissions.

Who is actually at risk?

The population most directly exposed is anyone who points an AI coding agent at code they did not write—developers, technical founders, contractors, and increasingly non-technical staff using AI tools to "just set up" a project they found online. The attack runs with the privileges of whoever is logged in, so a developer laptop with cloud credentials, API keys, and repository access is the high-value target.

For most small and mid-sized businesses, the worry is not that your team is building the next operating system. It is that one employee—often outside IT's view—cloned a repository, asked an AI agent to get it running, and handed that agent the keys to a machine that can reach your production cloud, your customer data, or your code. This is the same pattern we examined in the axios npm supply-chain attack: trusted developer tooling becoming the delivery route.

Anthropic has built genuine safeguards into Claude Code, and the company has been an active participant in AI security research—as we covered when it launched Claude Code Security, its AI-powered vulnerability scanner. The point of this research is not that one vendor is careless. It is that autonomous agents acting on untrusted content is a new category of risk that no single product fully solves yet.

Why does this make shadow AI so dangerous?

This attack is the clearest illustration yet of why shadow AI is more than a policy headache. An AI coding agent is not a chatbot that returns text—it is software that reads files, runs commands, and reaches the internet on your behalf, often with standing access to credentials. When that capability runs without organizational oversight, three things compound at once:

  • No visibility. If IT does not know an agent is installed and running, no one is watching what it executes or what secrets it can reach.
  • Standing privileges. These tools often hold API keys and tokens in plaintext config files, exactly the assets this attack is designed to steal.
  • Autonomy. The agent is built to resolve problems on its own. The very helpfulness that makes it productive is what carries out the attacker's instruction.

Shadow AI is not a fringe behavior. Survey data consistently shows that a large majority of employees—including senior leaders and security professionals—use AI tools their employer has not approved. When those tools are passive, the risk is mostly data leakage. When they are agentic, the risk becomes remote code execution on a corporate machine. That is the line this research crosses, and it is the same governance gap we explored in our look at detecting shadow AI agents and MCP connections.

What should Canadian and US business leaders take from this?

You do not need to understand DNS TXT records to manage this risk. You need to know which AI tools have reach into your systems, and under what controls. These are questions an executive can put to an IT lead or managed service provider this week:

  • Which AI agents can run code or commands in our environment, and who approved them? Distinguish passive assistants from agentic tools that execute actions.
  • Where are our developer and AI credentials stored, and are any in plaintext? API keys and tokens in config files are the loot in this attack.
  • Do AI coding agents run with full developer privileges, or in a sandboxed, least-privilege setup? Containers and scoped tokens limit the blast radius.
  • Do we have any approved, governed AI tooling? Employees reach for shadow tools partly because no sanctioned option exists—a theme we cover in why your business needs an AI usage policy.

These questions map cleanly onto frameworks your business may already reference—the CCCS Baseline Cyber Security Controls and PIPEDA obligations in Canada, and NIST SP 800-171, the CIS Controls, and the FTC Safeguards Rule in the United States. All of them assume you can answer a basic question: what software has access to your sensitive data, and who is accountable for it?

Practical steps to reduce your exposure

For organizations using or experimenting with AI coding agents, a few measures meaningfully reduce the likelihood and impact of this class of attack:

  1. Inventory your AI tools. Build a simple list of which AI agents are in use, by whom, and what they can access. You cannot govern what you cannot see.
  2. Treat untrusted repositories as untrusted. Do not let an AI agent auto-run setup scripts on code pulled from an unknown source. Run unfamiliar projects in a disposable container or virtual machine, never on a machine holding live credentials.
  3. Scope and rotate secrets. Give credentials the narrowest permissions that work, store them in a secrets manager rather than plaintext files, and rotate any key that may have been exposed.
  4. Require human approval for sensitive actions. Configure agents so that running shell commands or reaching external networks needs explicit sign-off, as discussed in when SMBs need a human in the loop.
  5. Give employees a sanctioned option. A governed, approved AI tool is the most effective way to shrink shadow AI, because it removes the reason people go around IT in the first place.

If you are not sure where your organization stands, our free quick security assessment is a fast way to surface gaps in how AI tools, credentials, and developer access are governed.

The durable lesson

The Mozilla research is a preview of a shift, not a one-off bug. As AI agents take on more autonomous work, the attacker's goal moves from tricking a person to tricking the agent—and the agent often has more access and fewer instincts for suspicion than the person ever did. The defense is not to ban these tools, which deliver real productivity, but to bring them into the light: known, scoped, monitored, and governed.

Shadow AI turns that defense off by default. Every unsanctioned agent is a capable piece of software making decisions on your behalf with no one watching. The poisoned-repository attack simply shows what happens when one of those decisions is made for it by an attacker.

This article is intended for general informational purposes only and does not constitute professional security, legal, or compliance advice. Details about the Mozilla 0DIN proof-of-concept attack on AI coding agents are based on public reporting and research disclosures as of the date of publication and may evolve as the investigation continues. Organizations should consult qualified cybersecurity professionals before acting on any specific indicator of compromise or making operational changes based on this article.