Module shadowing: your agent writes the exploit for me
I never send you malware. I just publish a webpage, a clean-looking "JavaScript best practices" site, and wait for your coding agent to read it. Say you ask it to summarize my page. My site quietly serves a ZIP archive with some encoded files and a suspicious binary decoder inside.
Your agent does the right thing first. It sees the binary, flags it as untrusted, and refuses to run it. Good instinct. But it still wants to read the encoded data, so it decides to write its own Python decoder from scratch. That is the mistake, and it is the agent's idea, not mine.
Here is the trick. Python's official base64 library internally imports another module called struct. Because of module shadowing, Python can search the script directory, or the current directory in some invocation modes, before the standard library, so it imports my local, malicious struct.py instead of the real one. The instant the agent runs import base64, my code runs, and it spawns a detached background process on your computer.
What I get
Your SSH keys, local API tokens, internal networks, and proprietary source code, all from an agent that thought it was being careful. It refused the obvious binary and got owned by a helper it wrote itself.
Why it works
The trust boundary is the working directory, and the agent forgot it. Untrusted content it fetched off the web ended up sitting next to code it then executed. It could not tell "data I read" from "code I run."
GhostJacking: I attack you through your own firewall logs
Part two needs even less. All I need is the logs from your own firewall. I fire one request at your website, built so it gets blocked. Your firewall does its job and blocks it. Then it logs my blocked request byte for byte, headers and all, unescaped, with no tag saying "this came from an attacker."
In that request I hid something inside the User-Agent header, the harmless part that just says what browser or tool I am. I disguised mine as a trusted security scanner reporting a routine problem, one your agent will happily "just fix."
You ask your AI triage agent to look into the blocked traffic. It reads my fake header as if it were a real finding, decides it is a DNS problem, and starts working on my suggested "fix." The agent is wired with real tools, so it edits your DNS: it changes the A record and adds a CNAME that repoints your website and your email to my domain. In other variants it runs one npx command that installs a malicious package, or, if it has a shell, that one line opens a reverse shell.
What I get
Once I own your DNS I can point your site at my servers, forge a real certificate for your own domain, hijack your email, and hand the whole domain to myself. No malware. No exploit. I just wrote one line in a log file. Researchers at Tenet Security named this GhostJacking and presented it at DEF CON 34.
Why it works
Same root cause as Part 1. Your firewall log is attacker-controlled text, but the agent treats it as trustworthy metadata. It cannot tell my planted "finding" from a real one, and it has the keys to act on it.
Your agent defense checklist
Both attacks are the same bug wearing two costumes: an AI agent cannot reliably tell data from instructions, and it was handed tools powerful enough to matter. Every fix below is about keeping untrusted input away from the tools that can act.
These controls reduce exposure and limit damage. A completed checklist records your work; it does not certify an agent or eliminate prompt injection.
The next field note.
Straight to your inbox.
Drop your email and I'll send the next one when it's live. One message, no spam, and you can reply to it. Or just follow on Instagram.