AI Coding Agents Have a New Attack Surface. Here's How GhostJacking Actually Works.
A WAF's own block log became a delivery channel this year. Here's the mechanism, the default configs that failed, and what OWASP just added to account for it.
In this article 5 sections
Quick answer: GhostJacking is a real attack technique disclosed this year that turns a web application firewall's own block log into a way to smuggle commands into an AI coding agent. The WAF does its job, logs the blocked payload verbatim, and an agent asked later to "review recent blocked traffic" reads that log and executes what's inside it. Testing found it worked against Claude Code roughly 90% of the time on a configuration the vendor itself recommends. It's not a flaw in one product — it's what happens when a read-only tool and a write/execute tool share a session with no trust boundary between them, and September's disclosures show that failure mode showing up in more places than one firewall log.
I want to be upfront about something before going further: security stories in AI tooling get hyped in both directions, either "the sky is falling" or "this is a minor edge case nobody will actually hit." GhostJacking is neither. It's a specific, demonstrated technique with a specific fix, and it's worth twenty minutes of your time to understand the actual mechanism instead of the headline. Protocol Wire covers AI and developer security stories by sticking to what researchers actually demonstrated.
What GhostJacking Actually Does
Here's the mechanism in plain terms. A web application firewall's entire job is to catch malicious traffic and log it so a human can review what got blocked. That log is, by design, a faithful record of exactly what the attacker sent — the WAF isn't going to sanitize its own audit trail, because then it wouldn't be useful for incident response. Reporting on the technique describes it as turning that log into a delivery channel: an attacker crafts a payload they know will get blocked, worded so it reads as an instruction rather than an exploit attempt, and waits. When a developer later asks their coding agent to "check what's been hitting the WAF this week" and points it at the log, the agent reads the blocked payload as part of its normal context — and if that payload looks like a legitimate instruction, a sufficiently capable agent with tool access can just follow it.
What makes this particularly nasty is that it doesn't require compromising anything upstream. The attacker never touches your codebase, your CI pipeline, or your credentials directly — they're relying entirely on a completely ordinary security control doing exactly what it's supposed to do, and on a developer's entirely reasonable instinct to have an agent triage a noisy log instead of scrolling through it by hand. That's the same instinct that makes agents useful in the first place, which is what makes this class of attack hard to just train people out of. You can't fix "don't have your agent read the WAF log" with a Slack reminder, because reading the WAF log is the job.
The Default Configs That Failed
GhostJacking wasn't the only finding in this cycle, and arguably not the most alarming one. Security researchers also found that the default GitHub Actions configurations published by Anthropic, Google, and OpenAI for their own respective coding agents all fell to a single unauthenticated vulnerability class, and all three ended in remote code execution. Read that again: not a third-party tool built carelessly on top of a good API, but the vendors' own recommended starting point for wiring an agent into a CI pipeline. That's the detail that should actually worry a team more than the specific WAF-log trick, because it means "just follow the vendor's setup guide" isn't a safe default assumption anymore for any of the major coding agents, not just one. Teams adopting enterprise agents, such as Factory's AI coding Droids, should ask the same question.
OWASP's New Skill Risk List
The response from the security standards side is a new addition to OWASP's GenAI security guidance covering what it calls the "skill" layer — the prose instruction files agents load and act on directly, the same category of content that made GhostJacking possible in the first place. Most security tooling built for the last decade treats a text file as inert until proven otherwise. An agent treats a text file as something to potentially act on by default. That's the actual category error underneath most of this year's disclosures, and it's also why a WAF log, a README, or a code comment can all become an attack vector in a way that would have sounded absurd three years ago. OWASP formalizing this as its own risk category matters less for the specific mitigations listed and more for giving security teams a shared vocabulary to point at when they tell an engineering team "no, this actually is our problem."
What Actually Fixes This
The fix that keeps showing up across every writeup of this class of vulnerability is the same one: never let a read-only tool and a write/execute tool share a session without an explicit trust boundary between them. Practically, that means an agent reading a WAF log, a support ticket queue, or incoming email shouldn't have unsupervised access to a tool that can run a shell command or push code in the same turn, full stop — route that through a human approval step or a separate, deliberately dumber process. In practice that looks less like a single setting and more like a checklist: separate the credentials an agent uses for reading logs from the ones it uses for pushing code, put a human in the loop before any tool call that mutates state gets triggered by content the agent didn't originate itself, and treat any prose file an agent can load — a README, a runbook, a ticket description — as untrusted input by default rather than trusted context. None of that is exotic. Most of it is the same least-privilege thinking security teams have preached for two decades, just applied to a new kind of actor that happens to read really fast and never gets bored halfway through a log file. It's the same lesson from why most enterprise AI agent pilots never reach production: the part that actually stalls or breaks these projects is almost never the model's raw capability, it's the plumbing around permissions and trust boundaries that nobody budgeted time for. Notably, OpenAI's new Agents API, which shipped the same month as these disclosures, bakes the Sandbox in as its own distinct concept from Tools for exactly this reason — whether that architectural separation actually holds up under adversarial testing the way GhostJacking held up against Claude Code is the next thing worth watching, not assuming.
Conclusion
None of this means AI coding agents are unsafe to use, and an "AI agents are a security nightmare" headline deserves the same eye-roll as "AI agents will replace your engineering team" ones. It means the trust boundary between what an agent reads and what an agent can execute is a real design decision, not a detail to leave to defaults, and September's disclosures are the clearest evidence yet that the vendors' own defaults aren't a safe place to stop thinking about it. Check what your agent's session actually has access to in the same turn it's reading untrusted input. If the answer is "everything," that's the finding, not a hypothetical. Protocol Wire will keep following how vendors handle this boundary.
