Data exfiltration through markdown images in LLM apps

Markdown image exfiltration is a way to move data out of an LLM app without any click from the user. The app renders a model-written image tag. The browser fetches the image URL. If the URL holds private data, that data reaches a server the attacker runs.

The weakness sits in output handling: the app renders what the model wrote. OWASP lists the area as Improper Output Handling (LLM10:2026, LLM05:2025).

How does markdown image exfiltration work?#

Untrusted text tells the model to write an image tag, and the tag's URL includes data from the chat. The app renders the tag, the browser requests the URL, and the data arrives in the attacker's server log. Three conditions must all hold:

1. Untrusted content reaches the model. A web page, email, document, ticket or tool result carries hidden instructions. This is indirect prompt injection.
2. The model can see something worth taking. Chat history, retrieved documents, a memory store or a secret in context.
3. The app lets the browser call an arbitrary host. The renderer shows remote images, or the content security policy allows the destination.

In the chain, step 3 is the one the app must stop.

Which real cases show this?#

Five cases from 2023 to 2025 show the same pattern in different products, each with a primary source and a date.

The fixes in the Bing and ChatGPT cases targeted the output channel. The EchoLeak chain beat several controls in a row, so one filter is a weak plan. The paper's "first real-world zero-click" label is the authors' own claim.

For memory-based persistence, see agent memory poisoning.

How do you fix it?#

Control what the output layer renders and what the browser may fetch, and use several controls, because one filter can be bypassed.

How do testers check for this channel?#

Testers check each place the app renders model output, on each client, with a harmless collector they control. They report what the app fetched, not what the model said.

1. List the renderers. Web app, mobile app, desktop app, email digests, Slack or Teams bots, exported PDFs, admin consoles. Each can parse markdown in its own way.
2. List the content sources. Which untrusted text can reach the model? Documents, web pages, email, tickets, tool results, memory.
3. Plant a marker. In a test account, place a benign instruction that asks the model to include a marker image from a collector host you own. Use test data only.
4. Observe. Check the network log of the client and your collector log. Did the client request the host? Was it a redirect? Did a query string or path carry any text?
5. Vary the form. Try inline links, reference-style links, autolinks and raw HTML where the renderer allows it. Record which forms the sanitizer handles.
6. Check other exits. Link previews, tool calls that fetch URLs, and email or message sends.
7. Check the policy. Read the CSP headers. Look for wildcard hosts and hosts with open redirects.

A finding needs evidence of a real request that carried test data to the collector. A rendered tag with no request is a lower finding. Report controls that held, such as a proxy that stripped query strings.

What should you do next?#

Inventory every surface that renders model output, close the image path, then review the other outbound paths. Add the check to your release tests for each new client.

No set of controls proves that data cannot leave. The UK NCSC wrote in December 2025 that prompt injection may never be fully mitigated, and that the aim is to reduce likelihood and impact. Output controls reduce impact when injection succeeds.

Excession Labs tests these channels in scoped LLM application security assessments, with written authorization from the system owner. For the wider class, see our prompt injection guide and our RAG security guide.