Multimodal Prompt Injection: The Image Is the Payload

Q: What is multimodal prompt injection?

Multimodal prompt injection is an attack where the malicious instruction is delivered through a non-text channel — an image, a PDF, a screenshot, a chart, or a rendered web page — rather than as text in the user’s message. A multimodal model treats every input channel as instruction-bearing: it reads the pixels through a vision encoder, extracts glyphs from a PDF’s text layer, runs OCR over an uploaded scan, or ingests a browsed page, and it cannot reliably tell content it should merely reason about from instructions it should follow. The crucial property is that the payload does not need to be human-visible or human-readable; it only needs to be parsed by the model. White-on-white text, a caption too faint to notice, a line that only becomes legible after the platform downscales an image, or a comment buried in a document layer all bypass a text sanitiser because none of that text was in the string you sanitised. It is the same confused-deputy vulnerability class as classic prompt injection, but the delivery is more dangerous because the human reviewer in the loop is blind to it — they see an ordinary invoice, screenshot or web page.

Q: Why do text-based prompt-injection filters fail against images and PDFs?

Because every control in a standard prompt-injection defence stack inspects the text channel, and a multimodal payload never enters that channel as text. Input sanitisation, intent classifiers, delimiter wrapping and output diffing all operate on strings — the user message, the system prompt, the tool arguments. When the instruction is encoded in the pixels of an image or the glyphs of a PDF, the model extracts it internally, after your text filter has already passed the request as clean. There was nothing in the string to catch. OWASP’s LLM01:2025 entry states the principle directly: prompt injections do not need to be human-visible or readable as long as the content is parsed by the model. So a filter tuned to catch “ignore previous instructions” in a text box is simply looking in the wrong place. The fix is not a better text filter; it is treating every non-text input as untrusted, instruction-bearing content at the moment it is ingested, and carrying that untrusted provenance tag through the entire pipeline so the model that eventually acts knows the extracted text came from an adversarial source.

Q: What was the EchoLeak vulnerability (CVE-2025-32711)?

EchoLeak, tracked as CVE-2025-32711 with a CVSS score of 9.3, was the first documented real-world zero-click prompt-injection exploit against a production LLM system — Microsoft 365 Copilot — disclosed in June 2025. A single crafted email was enough to trigger unauthenticated data exfiltration with no user interaction: the victim did not have to click anything. The mechanism chained several bypasses. The attacker embedded a hidden instruction payload in the email using white-on-white text and HTML comments, invisible to the human recipient but parsed by the model when Copilot read the message into its context. That payload evaded Microsoft’s Cross-Prompt Injection Attempt (XPIA) classifier, circumvented link redaction using reference-style Markdown, and abused auto-fetched Markdown images to leak data out through a Microsoft Teams proxy that content-security policy allowed. Microsoft patched the issue server-side and reported no exploitation in the wild. EchoLeak is the canonical case study because it demonstrates the full chain — invisible payload, classifier evasion, and an automatic egress channel in the model’s own output rendering — that structural defences, not detection alone, are required to break.

Q: How does an image-scaling injection attack work?

An image-scaling attack, weaponised against production AI systems by Trail of Bits in August 2025, exploits the fact that AI platforms routinely downscale uploaded images before feeding them to the model. The attacker crafts an image that looks innocuous — often nearly blank — at full resolution, but contains a hidden instruction that only becomes legible after the platform’s resize step. The trick relies on aliasing: by carefully placing content relative to the downsampling grid, the attacker ensures the instruction emerges when the specific interpolation algorithm (nearest-neighbour, bilinear or bicubic) reduces the image to the model’s expected input dimensions. The model then sees a clear instruction that the human who inspected the original upload never saw. Trail of Bits demonstrated real data exfiltration — extracting Google Calendar data to an attacker’s email via Gemini CLI combined with a Zapier MCP integration running default auto-approval — and showed more than six Google and third-party products were affected. They released an open-source tool, Anamorpher, to generate the crafted images. The defence is to normalise and downscale images to a fixed target yourself at ingestion, so the model sees exactly the image your safety checks inspected, closing the gap the attack drives through.

Q: What is the dual-LLM or CaMeL pattern for defending against injection?

The dual-LLM pattern, and its more formal refinement CaMeL from Google DeepMind, is a structural defence that separates the model that reads untrusted content from the model that takes actions. A quarantined LLM is the only component that touches the untrusted image, PDF or web page, and it is constrained so it can only emit structured data — it has no tools, no ability to call functions, and no egress path. A separate privileged LLM orchestrates the actual actions (sending, writing, fetching, paying) but never sees the raw untrusted content; it works only with the structured, provenance-tagged data the quarantined model produced. The reasoning behind it is Simon Willison’s “lethal trifecta”: an agent becomes dangerous when it combines access to private data, exposure to untrusted content, and the ability to communicate externally. Remove any one of those legs from the untrusted path and an exfiltration cannot complete. The pattern is valuable precisely because it does not rely on detecting the payload — even a perfectly successful injection into the quarantined model produces bad structured data and nothing else, because that model was never able to reach anything consequential in the first place.

Q: Can a prompt-injection firewall or classifier fully stop these attacks?

No, and treating a classifier as your primary boundary is one of the most common and dangerous mistakes. A prompt-injection firewall that blocks 95% of attacks still fails one in twenty, and in security a control an attacker can iterate against — resubmitting variations until one passes — is not a boundary at all; it is a speed bump. The VPI-Bench benchmark of visual prompt injection measured system-prompt defences as offering “only limited improvements,” and deceived computer-use agents at rates up to 51% and browser-use agents up to 100% on specific platforms. Detection absolutely has a place as one layer of defence in depth — a cheap classifier screening tool outputs before the main model acts genuinely reduces risk — but it must never be the wall. The load-bearing controls are structural: isolating untrusted content in tool-result blocks, JSON-encoding it so it cannot break out into an instruction context, separating the reading model from the acting model, and gating consequential actions behind human confirmation. Those hold even when the classifier is bypassed, which against a determined attacker it eventually will be.

Q: How should I handle images, PDFs and screenshots that users upload to my AI app?

Treat every uploaded file and every non-text input as untrusted, instruction-bearing content from the moment it enters your system, and put it through a defined ingestion pipeline before the model ever reasons about it. First, normalise: downscale images to a fixed target resolution yourself, strip metadata, flatten PDF layers, and render documents to a canonical form — this both removes hidden channels and closes the image-scaling gap where the model sees a different image than your safety check did. Second, tag provenance: whatever text or structure you extract (via OCR, PDF parsing or vision) is labelled as untrusted tool-result data, JSON-encoded, and never spliced into your system or user prompt. Third, separate reading from acting: let a quarantined model with no tools and no egress do the interpretation, and pass only structured, provenance-tagged output to the privileged model that can take actions. Fourth, gate the actions: require human confirmation for anything consequential — sending, paying, writing to shared state, fetching external URLs — and sanitise and redact model output before any auto-render so a reply cannot silently fetch an attacker URL carrying your data. The goal is that a successful injection produces bad text and no blast radius.

Q: Is multimodal injection different enough to need its own defences, or does my text-injection strategy cover it?

It is the same vulnerability class with a new delivery mechanism, which means your existing defence-in-depth strategy is the right foundation but does not automatically extend to cover it — you have to consciously stretch each layer to the new modalities. The underlying problem is identical: the model cannot distinguish data from instructions, so an adversary who controls any input the model parses can attempt to redirect it. What changes is the channel. If your text-injection strategy already isolates untrusted content, separates privileged from unprivileged model contexts, and gates actions, then the work is to make sure images, PDFs, OCR output and browsed pages are routed through those same controls rather than bypassing them because they are “just an upload.” Concretely, that means adding image normalisation and metadata stripping at ingestion, ensuring vision and OCR output inherits the untrusted tag, and adding multimodal cases to your red-team suite so you actually test downscale-reveal, low-contrast, PDF-layer and screenshot vectors. Anthropic, for example, runs dedicated classifiers over screenshots for its computer-use tool and asks for user confirmation before acting — a modality-specific extension of an existing principle. So: reuse the architecture, but audit every layer for the assumption that input is text, because that assumption is exactly what the attack exploits.