Your Decompiler Output Is Now an Attack Surface

A binary just learned how to talk back to the AI analyzing it, and almost nobody noticed.

Summary

If you've handed a stripped binary to an AI agent and trusted the summary it gave you, you need to read this. Researchers showed that strings embedded in a C program can survive decompilation by tools like Ghidra and land, intact, inside the context window of an LLM-based reverse engineering agent. The binary isn't just data anymore. It's a prompt.

Context

This isn't a brand-new category of vulnerability. Prompt injection has been the known soft underbelly of LLM applications since roughly five minutes after people started wiring LLMs up to anything with external input. We've seen it in chat agents reading web pages, in email assistants summarizing inboxes, in coding agents ingesting pull requests. What's new here is the specific pipe: decompiled code, which the security and RE community has treated as a technically adversarial but functionally trusted artifact for decades.

Think about that assumption for a second. Malware analysts have always known the binary they're staring at is hostile. That's the whole point of the exercise. But the output of the decompiler — the pseudo-C, the recovered strings, the control flow graph — has traditionally been treated as a faithful, inert representation of what the binary does. You read it, you reason about it, you're not worried the decompiler output itself is going to do something to you. Now that output is being piped straight into an LLM agent (Cline, GhidraMCP with Qwen3-8B in this case) that treats it as part of its own reasoning context. The trust boundary that used to exist between "binary" and "analyst's brain" has quietly been replaced by "binary" and "LLM's context window," and nobody updated the threat model for the swap.

Hype check

Let's be honest about what this is and isn't. It's not a new exploitation primitive against Ghidra itself, and it's not remote code execution against the analyst's machine (at least not based on what's described here). It's a logic hijack: get the AI agent to misreport, mislead, or redirect its own analysis because it can't distinguish "data I'm supposed to analyze" from "instructions I'm supposed to follow." That distinction sounds subtle until you remember it's the exact same unsolved problem plaguing every LLM-integrated tool right now.

What's being understated is the blast radius of "trusted input" assumptions baked into every AI-RE tool shipping right now. Vendors building AI copilots for malware triage, firmware analysis, vulnerability hunting — all of them are making the same implicit bet that decompiler output is safe to hand to a model unfiltered. That bet was never examined, it was just inherited from the pre-LLM tooling era where the human was the one doing the reasoning and humans don't get "prompt injected" by a string in a disassembly listing (well, mostly).

What's being overstated, if anything, is novelty. Two points and zero comments on HN tells you the discourse hasn't caught up to the implication yet, not that the implication is small. This is the same prompt injection story we've been telling since 2023, just wearing a different costume. The costume matters because of who's in the room: security researchers who are, ironically, the most likely people to be running exactly this kind of agent against exactly this kind of hostile input, on purpose, every day.

Implications

If you're building or buying AI-assisted reverse engineering tooling, the decompiled output needs to be treated the same way you'd treat any other untrusted, attacker-controlled input to an LLM. That means sanitization before it reaches the model, strict separation between "content to analyze" and "instructions to follow" (good luck, nobody's fully solved this), and probably a healthy dose of skepticism toward any AI-generated analysis summary of a binary you didn't compile yourself. Malware authors already obfuscate strings and pack binaries to defeat human analysts. Adding a prompt injection payload aimed at the AI analyst is a logical, cheap next step, and it requires no changes to how the malware actually executes. It's a free attack on the tooling, not the target.

For the broader industry, this is another data point in a pattern: every time we bolt an LLM onto an existing trust boundary, that boundary needs re-examining from scratch, not inherited from the previous tool.

Open question

When your AI reverse-engineering agent reads a binary that was built specifically to lie to it, how do you know the summary it hands you isn't the malware's final payload?

— Cor, Skyblue Soft

Sources

• Attacking AI-based reverse engineering tools using weaponized binaries

AI-assisted draft or imaging, human-curated, reviewed and edited.