Improper output handling

Model output is not an answer. It is a string on its way somewhere, and the somewhere decides what it becomes. The same sentence is text in a chat bubble, a command in a shell and a script in a browser.

The reframe that makes this ordinary

OWASP's framing turns an unfamiliar problem into a familiar one in a single line.

So a model connected to a shell is a shell with an extra input box. Everything application security already knows applies, and the mitigation says so outright.

Where it sits next to the neighbouring entries

Three entries touch model output and they divide cleanly. Getting this wrong is the most common misfiling in reports.

LLM01  Prompt Injection        the INPUT side. Validation of what goes in.

LLM07  Misinformation          output that is incorrect or misleading.
                               The content is wrong.

LLM10  Improper Output         unsafe USE of output before it is passed
       Handling                downstream. The content may be perfectly
                               correct and still take down the system.

The distinction that matters: LLM07 is about the answer being wrong, LLM10 is about where the answer goes. A correct SQL query executed unparameterised is an LLM10 finding.

Take the inventory

This entry does not reward clever payloads. It rewards listing every place output lands and noticing which of them interpret what they are given.

The impact set is unglamorous and familiar, which is the point. OWASP lists XSS and CSRF in browsers, plus SSRF, privilege escalation and remote code execution on backend systems.

The two sinks added in 2026

Both are already elsewhere in this course, and they are worth naming here because they are the two that rarely appear on anyone's sink list.

The first is the terminal. Control characters written to a terminal, log viewer or IDE pane get interpreted, and OWASP names the consequences: visual spoofing, clipboard hijacking through OSC 52, and exploitation of known terminal emulator bugs. Module 2.4 covers the character classes.

The second is any renderer that fetches. A chat UI that auto-renders Markdown images or link previews will send an outbound request to whatever host the model named, carrying whatever the model put in the query string. Module 3.2 runs that as a full chain.

The pattern that fixes this by construction

The reliable version stops asking the model for the finished artefact. Ask it for a decision, in a shape the application can check, and build the artefact from the decision.

Fragile:  model emits  ->  "DELETE FROM invoices WHERE id = 42"
                        ->  db.execute(thatString)

Sound:    model emits  ->  { action: "void_invoice", id: 42 }
                        ->  validate against a schema
                        ->  check the caller may void invoice 42
                        ->  the application writes the query

The model still chooses. It no longer writes the thing that executes, so the sink never receives model-authored syntax and there is nothing to escape.