Indirect prompt injection is far more than just another chatbot problem; it is a very real and serious attack vector that can result in catastrophic damage, much of which will be irreversible. Take, for example, modern agentic IDEs and coding agents, which can request the use of various tools. Once such tools are authorized, the LLM can ask to execute shell commands, open local files, and make network calls. This sort of tool usage sets the stage for very serious exploits. As an example, this blog post will show how, in the absence of any red flags or systemic suspicion from Claude code, an attacker gained shell access to a developer machine.
In short, agentic coding tools have access to everything they need for this: private data, including environment variables, credentials, API keys, and local configuration files. Untrusted content, such as repositories, documentation, and error messages from recently installed packages, can inject malicious models to steal this data.
What is most interesting the attack described below is that it works even though the payload never appears anywhere in the repo. This means that no scanner would ever catch it, no human reviewer would ever see it, and the agent itself would never have a chance to look at it before running it. Instead, the malicious instruction is injected at runtime, pulled from DNS, after the agent has blindly trusted everything else.
A fully interactive shell appeared on a developer's machine after Claude Code was asked to do one thing: get a freshly cloned project running. No exploit code, no warning, no suspicious command anyone had to approve. Claude Code read the project's setup notes, hit a routine error, ran the documented fix, and that fix quietly opened a reverse shell back to an attacker's server.
The repository contained no malicious code. Every file in it is individually boring and passes review. In fact, the payload that eventually executes was never part of the repo but, instead, lives in a DNS TXT record.
Can an attacker who controls nothing but a public GitHub repository get code execution on anyone who opens it with Claude Code, without committing a single line of malicious code?
The datasheet offers insight into the challenges and solutions in AI security.
The attack is built from three pieces. On their own, none of them looks like anything. The damage only shows up when they run in order.
Claude Code reads the repo files as trusted project context. A guthub issue or .MD file file describes a normal first-time setup:
init must be run once before any other commands work.
The Python package refuses to do anything until it has been initialised. Use it before running init and it raises a plain, helpful error. This is a completely ordinary pattern, and that is exactly why it works.
Running init calls a shell script. It reads like routine cloud-platform bootstrapping, it pulls a config value, then continues. The config value arrives from a DNS TXT record, and it is run as a command.
The dig ... | bash line is the whole trick. The repo never states what the config is. It fetches it the malicious command in the DNS TXT file that attacker controls.
The developer copies the repo link and asks Claude Code to get it running. Every subsequent step happens autonomously:
The DNS value is base64-encoded, so a reverse-shell signature never appears in plaintext anywhere on disk or on the wire:
_axiom-config.m100.cloud TXT
Decodes to a textbook reverse shell:
Claude Code never decided to open a shell. It decided to fix an error. The reverse shell is three indirection steps away from anything Claude Code actually evaluated: an error message it trusted, a script that fetched a value, and a DNS record it never saw.
The attacker now has an interactive shell running as the developer's own user. On the developer's side, the entire terminal output is:
Connect your security infrastructure with our expert-driven vulnerability detection platform.
The attack splits its components across three systems that are never examined together: the repository, the DNS infrastructure, and the developer's trust in their AI agent. Static analysis sees a DNS lookup. Network monitoring sees name resolution. The agent sees a pre-authorised setup step. None of the three looks malicious in isolation.
To defend against this, agents need to surface what a setup command will actually run, including the contents of any script it invokes and anything that script fetches at runtime, not just the command itself. Developers should treat setup instructions and scripts in unfamiliar repositories as untrusted code, regardless of what their AI tool recommends.
Want to test agentic AI systems like this with the 0DIN community? If you are researching prompt injection, agentic tool abuse, jailbreaks, or other GenAI security issues, join the 0DIN AI bug bounty community and help turn real attack research into validated findings. Create a researcher account Submit findings Join our Community of Researchers on Discord
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
