The Security Risks of Running Unfamiliar Repos with Claude Code: How AI Agents Get Hijacked

A Scenario You Could Actually Run Into

Imagine this: someone sends you a GitHub repo link. You don't feel like setting up the environment yourself, so you hand it off to Claude Code with a simple "get this running." It reads the README, installs dependencies, runs initialization — every step feels like routine development work.

Then the project throws an error: "Environment not ready, please run the initialization script." If you were doing this yourself, you might pause and check what the script actually does. But Claude Code doesn't think that way. To it, this is just an "unfinished task," so it keeps going.

The problem is in that script.

This security research comes from Mozilla's Lindin team, with follow-up coverage from tech outlet The Decoder. It doesn't describe a theoretical vulnerability — it's a real attack chain that can be triggered inside everyday development workflows.

How the Attack Chain Stays Hidden

What makes this attack so clever is that the dangerous payload is hidden somewhere you can't see.

The script doesn't embed malicious instructions directly in the repo code. Instead, it queries a DNS record. Think of DNS as the internet's "address book" — normally it tells your computer where to find a server for a given domain. In this case, researchers quietly tucked an external instruction into that address book.

Specifically, DNS supports a field called a TXT record — originally used for domain verification or email authentication. An attacker can write any arbitrary string into this field, including a complete shell command. When the initialization script performs a DNS lookup, the returned "text" gets passed directly into an execution function, completing a "data-as-code" injection. Since DNS queries are entirely legitimate network activity, firewalls and security tools barely bat an eye.

In security research, this technique has a name: Indirect Prompt Injection. The attack instruction never appears in code the AI can directly see — it's hidden in an external data source that only gets loaded dynamically at runtime, making pre-execution detection extremely difficult.

This means:

• You open the repo and see no malicious code;
• A code scanner scans the repo and finds nothing;
• The AI reads the README and spots no anomalies.

Each piece looks normal in isolation: the README looks like a normal README, the error looks like a normal error, the init script looks like a normal script, and the DNS query looks like an ordinary network request.

But connected together, they form a complete attack chain. Only when the initialization script actually runs does the instruction hidden in DNS get retrieved and executed on your machine.

The Aftermath: Your Credentials Are Already Gone

Once the instruction executes on your machine, the consequences are serious.

An attacker can open a channel out from your computer. Local sensitive credentials — API keys, GitHub tokens, cloud service keys — can all be quietly exfiltrated through that channel.

There's also an underappreciated cascade risk: credentials in a development environment tend to have far-reaching blast radii. A GitHub token might have write access to multiple private repos; a cloud service key might be tied to storage buckets, compute instances, and databases; even a seemingly ordinary API key can expose business logic, prompt templates, and user data — and generate substantial bills. In real attack scenarios, automated exploitation of stolen credentials is often complete within minutes, long before the victim notices anything is wrong.

What makes it even more chilling is how silent the whole thing is. Your terminal won't flash a "you've been attacked" warning — it might just quietly print "environment ready." You think the task completed successfully. Your keys are already in someone else's hands.

The Problem Isn't That AI Is Dumb — It's That It's Too Eager

The instinctive reaction might be: is Claude Code just too naive to catch this?

But the real problem the research reveals is the opposite — it's too eager.

It sees an error and wants to fix it. It sees instructions and follows them. It sees initialization fail and tries to recover. A human developer faced with "please run the initialization script" might instinctively hesitate and take a closer look. An AI agent tends to cross that psychological threshold without a second thought.

This is the fundamental difference between an AI agent and a regular chatbot. A chatbot's capabilities stop at "generating text" — the worst it can do is give you a wrong snippet to copy. An AI agent (AI Agent) has real tool-calling capabilities — it can read and write files, execute terminal commands, and make network requests. Claude Code, Devin, and GitHub Copilot Workspace all fall into this category. This architecture gives AI genuine "execution authority" — the ability to produce lasting effects in the real world.

Security researchers call this risk profile "Capability Overhang": when a system's capacity for action far outpaces its capacity for safety judgment, its helpfulness itself becomes an attack surface. In other words:

• A chatbot's mistakes stay at the information layer;
• An agent's mistakes land directly at the action layer.

When a tool has execution permissions, its eagerness can be weaponized as an entry point.

Defending Against AI Agent Security Risks: Ask One Extra Question

For years, the security community has hammered home one piece of advice: don't run unfamiliar code from unknown sources.

In the age of AI agents, that needs one more layer: don't let AI run something it hasn't fully understood yet.

When vetting an unfamiliar repo, don't just ask whether the code itself is clean. Ask one more question:

After the AI gets this running, will it go out and "fetch something" from the internet?

In practice, consider building these protective habits:

1. Isolate your execution environment: Use a sandbox, container, or temporary VM for unfamiliar repos — don't let AI agents touch your host machine or real credentials directly;
2. Principle of least privilege for credentials: Don't store long-lived API keys, tokens, or cloud secrets in environments the AI operates in; prefer short-lived tokens with limited scope;
3. Review initialization scripts: Treat any "please run this script" prompt with suspicion, especially anything involving network requests or DNS queries;
4. Restrict agent permissions: Where possible, add a manual confirmation step for the AI tool's command execution and network access.

AI agent tools are rapidly integrating into development workflows, and the productivity gains are real. But alongside efficiency, they inherit the double-edged sword of execution authority. This research is a reminder: before you hand the keys to an AI, think carefully about which doors it might open for you.

Key Takeaways