Two separate security research teams published findings this week that, taken together, describe a genuinely new category of attack on developer machines. Both dropped within 24 hours of each other — June 26 and June 27 — and both point at the same underlying problem: AI coding agents are designed to be helpful, and attackers have figured out how to make that helpfulness work against you.
Neither attack requires malicious code in the repository. That's the part worth sitting with for a moment.
What Mozilla's 0DIN Team Just Showed
On June 27th, researchers at Mozilla's Zero Day Investigative Network published a proof-of-concept demonstrating how an attacker can compromise a developer's machine through a completely clean GitHub repository.
Here's the attack chain. An attacker publishes a GitHub repo — looks normal, passes every automated scan, contains nothing that would raise a flag on code review. The repo includes a Python package designed with a specific property: it refuses to run until initialized. When a developer (or their AI coding agent) tries to use it, it throws an error: "Package not initialized. Run python3 -m axiom init to continue."
That's a normal-looking setup step. AI coding agents are trained to help resolve errors. Cursor, GitHub Copilot, Gemini CLI, and similar tools will read that error and suggest running the init command — or just run it automatically in agentic mode.
The init script calls home to an attacker-controlled server. But it doesn't fetch a file anyone can see. It reads a DNS TXT record. The DNS TXT record contains a base64-encoded reverse shell payload. That payload executes, and the developer's machine now has an active connection back to the attacker — a shell running with the developer's full privileges.
No malicious code ever appeared in the cloned repository. The entire payload lived in a DNS record that only resolves at runtime, a step removed from anything any scanner ever evaluated. The 0DIN researchers put it plainly: "no exploit code, no warning, no suspicious command anyone had to approve."
The Amazon Q Story Is the Same Attack from a Different Angle
The day before — June 26th — a separate research team at Wiz disclosed CVE-2026-12957, a vulnerability in Amazon Q Developer. Root cause: Amazon Q automatically loaded MCP server configuration files from .amazonq/mcp.json in any workspace the developer opened. If you cloned a repo that contained one of these config files, Q would silently launch the servers it defined — with your live AWS session attached.
No user approval. No warning. Just: clone repo, open in Q, your cloud credentials are now in the hands of whoever set up that MCP config.
Amazon patched this in May after responsible disclosure. But the disclosure itself triggered a broader audit, and similar auto-execution behaviors were found in Windsurf (CVE-2026-30615) and in early configurations of other tools. The common thread: AI coding tools were designed to trust repository context as authoritative, and that trust is now a documented attack surface.
Why This Matters for Small Teams Specifically
The delivery mechanism for both attacks is social engineering — not a compromised package registry, not a man-in-the-middle attack, not a phishing email. Someone shares a repo. Maybe it's:
- A "code challenge" in a job application process
- A tutorial linked in a blog post or newsletter
- A tool shared in a developer Slack or Discord
- A GitHub repo linked in a LinkedIn DM
These are all things your developers encounter constantly. And the "clone this and try it out" workflow is exactly the moment AI coding agents are most likely to be running, because that's the workflow they accelerate. Let the agent spin up the dependencies while you read the README.
Large engineering organizations have some structural protection here — code review workflows, sandboxed dev environments, security tooling watching for anomalous outbound connections. Not perfect, but there's friction.
A five-person dev team at a nonprofit or a small agency doesn't have that. Developers clone repos they find interesting. They run them locally. They use Cursor or Copilot to help with setup because it's faster. There's no one reviewing what commands the agent is running during initialization, and no monitoring watching for a DNS lookup to an unfamiliar domain followed by a reverse shell connection.
The other piece: the payload here isn't ransomware or a banking trojan. It's a shell. What the attacker does with that shell depends on what's on the developer's machine. If they're running with full admin rights (common in small org setups), the attacker has full access to the filesystem. If they have environment variables set with AWS keys, database credentials, API tokens — those are exposed immediately. If the machine has access to internal systems because the developer is VPN'd in, that's in scope too.
The Root Issue: AI Agents Trust What Repos Tell Them
What makes the Mozilla 0DIN attack particularly hard to defend against is that the AI agent isn't being deceived by malicious code. It's being deceived by a malicious error message. The difference matters.
Supply chain attacks that poison packages get caught — eventually — because the malicious code exists somewhere in an artifact that gets scanned. The DNS TXT payload attack leaves nothing to scan. The repo is clean. The package on PyPI is clean. The only thing that isn't clean is a DNS record that resolves at the exact moment a developer runs an init command, and resolves differently every time (or only once, after which the attacker rotates it).
AI coding agents are very good at helping developers get past setup errors. They're not designed to ask: "Before I suggest running this init script, let me verify what it fetches at runtime." That gap is what this attack exploits.
What to Do Right Now
Talk to your developers about the "clone and run" risk explicitly. Most of them have internalized supply chain attack awareness around npm and PyPI packages. Fewer have thought about the fact that a setup script in a cloned repo can fetch a payload from a DNS record that never appeared in any code review. That specific framing is new and worth a five-minute conversation.
Run AI coding agents in sandboxed environments when exploring new repos. A VM, a Docker container, a dev container with restricted outbound access — any environment that isn't your developer's main machine with their credentials and cloud sessions loaded. This sounds like overhead, but it's genuinely low-cost. Dev containers can be templated and shared across the team.
Restrict outbound DNS during development where possible. The specific technique in the Mozilla research requires a DNS lookup to an attacker-controlled domain at init time. Monitoring or blocking unusual outbound DNS queries from dev machines is not zero cost, but it's the most direct technical defense against this specific vector.
Audit what your AI coding agent is authorized to run automatically. Most tools have configurable trust levels — some actions require approval, others execute automatically. The default settings for agentic mode are often permissive. Tighten them so that any command involving an init script, a shell script, or external network calls requires explicit developer approval before execution.
Treat "try this repo I found" with the same caution as "try this attachment I found." The social engineering delivery for this attack pattern is a legitimate-looking repository shared through a trusted channel. The attacker is counting on the implicit trust developers extend to GitHub links compared to, say, an email attachment.
Two research teams, 24 hours, the same category of attack from two different angles. That's not a coincidence — it's a signal that this attack surface is being actively explored right now. The tools your developers are using to move faster are also the tools attackers are mapping for new entry points.
If your team is using AI coding tools for local development — and most dev teams are at this point — this is worth a quick conversation this week about what "safe practices" look like now that the threat model has changed. We've been walking teams through exactly this kind of security posture update, and the conversations are short and concrete. The patterns aren't complicated; the awareness is what's missing.