OWASP LLM Top 10 / LLM10
LLM10

Improper Output Handling

Insufficient validation, sanitisation, and handling of model output before it is passed downstream — treating LLM output as trusted gives users indirect access to backend functionality, enabling XSS, SSRF, SQL injection, and remote code execution. In 2026 it falls the furthest, from fifth to tenth.

Source: OWASP Top 10 for LLM Applications 2026 (CC BY-SA 4.0) — condensed for clarity.
Overview

What it is

Improper Output Handling is the insufficient validation, sanitisation, and handling of model output before it is passed to other components and systems. Because model output can be steered by prompt input, passing it downstream unchecked is effectively giving users indirect access to additional functionality. Successful exploitation can produce XSS and CSRF in browsers and SSRF, privilege escalation, or remote code execution on backends.

Improper Output Handling concerns the unsafe use of model output before it moves downstream, whereas LLM07 Misinformation concerns output that is simply incorrect; validating and sanitising model inputs is LLM01 Prompt Injection.

Impact grows when the model holds excessive application privileges, when the system is exposed to indirect prompt injection, when third-party tool inputs are unvalidated, when context-specific output encoding is missing, and when terminal, log, or IDE sinks render output without neutralising control characters. The 2026 entry adds two modern sinks: ANSI/control-character injection into terminals and IDE panes, and client renderers that auto-fetch external resources (markdown images, link previews) referenced in output, enabling exfiltration through outbound requests. It also spans the insecure code assistants generate at scale.

Attack surface

Common examples

  • Model output is passed directly into a system shell or into exec / eval, resulting in remote code execution.
  • Generated JavaScript or Markdown is returned to a user and interpreted by the browser, resulting in XSS.
  • Generated SQL is executed without parameterisation, leading to SQL injection.
  • Output is used to build file paths without sanitisation, enabling path traversal.
  • Generated content is placed in email templates without escaping, enabling phishing.
  • Output containing ANSI escape sequences is written to a terminal, log viewer, or IDE that interprets them, enabling visual spoofing or clipboard hijacking (for example OSC 52).
  • A chat UI auto-renders a markdown image or link preview referenced in output, letting an attacker who controls part of the context exfiltrate conversation data through the image URL.
Defense

Prevention & mitigation

  • Treat the model as an untrusted user. Adopt a zero-trust posture and apply proper input validation on the model's responses before they reach backend functions.
  • Follow OWASP ASVS. Use the Application Security Verification Standard for effective input validation, sanitisation, and output encoding.
  • Encode output back to users. Encode model output to mitigate JavaScript or Markdown execution, using context-aware encoding for where the output will be used (HTML, JavaScript, SQL).
  • Parameterise database operations. Use parameterised queries or prepared statements for anything involving model output.
  • Apply a strict Content Security Policy. Use CSP to mitigate XSS from generated content.
  • Log and monitor outputs. Detect unusual patterns in model output that might indicate an exploitation attempt.
  • Sanitise control characters. Strip ANSI escape sequences, BEL, OSC, backspace, and carriage return before output is written to terminals, logs, or other interpreting sinks; encode them visibly when they must be kept.
  • Stop renderers from auto-fetching. Disable auto-rendering of markdown images, link previews, and iframes by default; where rendering is required, restrict fetches to an allowlist or proxy them server-side, stripping data-bearing query parameters.
In the wild

Example attack scenarios

  1. A general-purpose LLM passes its response unvalidated to a tool that also offers privileged administrative functions, causing the tool to shut down for maintenance.
  2. A website-summariser tool follows an injected instruction to capture sensitive content and, with no output filtering, sends it to an attacker-controlled server.
  3. A chat feature that crafts SQL runs an unscrutinised query to delete all database tables.
  4. A web app returns an unsanitised JavaScript payload generated from a crafted prompt, leading to XSS in a victim's browser.
  5. An LLM generating marketing email templates is manipulated into embedding malicious JavaScript, causing XSS in vulnerable email clients.
  6. An application automatically compiles and deploys LLM-generated code without review, and insecure output reaches production and is exploited.
Further reading

References

  • OWASP Top 10 for LLM Applications 2026 — LLM10:2026 Improper Output Handling: genai.owasp.org
  • OWASP Application Security Verification Standard (ASVS)
  • Rehberger — Terminal/ANSI and markdown-image exfiltration write-ups (2024)
  • OWASP Cheat Sheet Series — Output Encoding & Content Security Policy

How Neural Industries helps. We test how your application handles model output across every sink — browser, backend, database, terminal, and chat renderer — and help you add context-aware encoding, parameterisation, and safe rendering before output is trusted.

Request an assessment →