LLM10: Improper Output Handling (Rendering, Sinks, Codegen)

Description

Improper output handling is what the application does with a model-generated string before something else interprets it. The 2026 entry frames it as missing validation, sanitisation and context-aware encoding between the model and its consumer: a markdown renderer, a shell, a SQL driver, a template engine, a file path builder, an email body, a terminal or another API. Because the output derives from the prompt, whoever influences the prompt indirectly drives that consumer, and the listed impacts are the classic set - XSS, CSRF, SSRF, privilege escalation and remote code execution - through an LLM rather than a form field. The entry is explicit that this is unsafe use of output rather than output being wrong: incorrect content is LLM07 Misinformation, and validating what goes into the model is LLM01 Prompt Injection.

In deployed integrations the finding is a missing step rather than an exotic payload: a chat UI that auto-fetches an image URL the model wrote, a text-to-SQL layer that interpolates values instead of binding them, a tool that passes model text into a shell string, a summariser whose output lands unescaped in an HTML email, or a terminal and log pipeline that renders raw ANSI so the visible transcript no longer matches what ran. The 2026 edition moved this entry down five places from LLM05:2025, the largest drop in the list, because injection and disclosure now dominate incident records rather than because renderers were fixed, and it widened the scope to insecure code that coding assistants produce at scale. What an over-privileged agent then does with a sink is LLM03 Excessive Agency, and the Stored XSS page in the WEB section covers the rendered-HTML sink itself.

Keywords: insecure output handling, markdown exfiltration, text-to-sql injection, ai generated code security, output encoding, ansi escape spoofing, sandbox escape

Examples/Proof

  • Zero-click markdown beacon
    • Get the model to emit an image URL whose query string carries conversation text. A hit at your collector with no user click proves the render path fetches attacker-controlled targets. See the Markdown Rendering Exfiltration Channels page.
  • Generated SQL and shell arguments
    • Ask a question whose entity name contains a single quote; a driver syntax error, or the literal inlined in the query log, proves the statement is built rather than bound. Then steer a tool argument to a benign command substitution and check for /tmp/poc.txt. See the Model Output Into Executable Sinks page.
  • Assistant-authored weakness at scale
    • Run a fixed prompt battery in the real repository and score every diff with SAST. A per-prompt rate, not one bad completion, is the finding. See the Insecure Code From AI Assistants page.
  • Terminal and log rendering
    • Have the model emit ANSI escapes and carriage returns in an answer that reaches a CLI or log viewer. Overwritten or hidden lines mean the audit trail can be spoofed.

Detection and Monitoring

  • Render-path egress and encoding diffs
    • Log every outbound host the client fetches for rendered output, collect CSP violation reports, and diff the raw completion against what the renderer, email template and terminal display. Alert on first-seen hosts, high-entropy query strings, ANSI escapes and invisible Unicode.
  • Sink-level statement logging
    • Log the exact SQL, argv array, template and outbound body each sink received, tagged with the model turn. Alert on unparameterised statements and on writes from read-only paths.
  • Generated-code posture over time
    • Run SAST and secret scanning on every assistant-authored diff, tracking findings by prompt class so a model or rules-file change shows up as a rate shift.

Remediation

  1. Encode for the consumer, not in general
    • Choose the scheme at the sink that interprets the string - HTML, JavaScript, URL, SQL, shell - rather than sanitising once at the source.
  2. Parameterise and allowlist every executor
    • Bind SQL values, pass argv arrays instead of shell strings, use logic-less templates, and schema-validate structured output before forwarding it.
  3. Turn off auto-fetch and raw HTML in renderers
    • Render markdown to a restricted AST with no raw HTML, iframes or SVG, allowlist image and link hosts server side, and set a strict CSP.
  4. Contain the executor
    • Run code, queries and commands in an ephemeral sandbox with a least-privilege database role, no ambient credentials, no metadata access and default-deny egress.
  5. Treat assistant-authored code as untrusted contribution
    • Apply the same review, SAST and secret-scanning gates to agent pull requests as to human ones, and keep the assistant’s context files under code review.

Prevention Checklist

  • Markdown and HTML from the model rendered without raw HTML, iframes, SVG or external auto-fetch, under a tested CSP
  • All generated SQL executed through bound parameters by a role that cannot write outside its scope
  • No model string reaching a shell, file path or template without argv separation, and structured output schema-validated before any downstream call
  • Assistant-authored diffs blocked on SAST, secret scanning and human review before reaching main