LLM05: Improper Output Handling
Downstream systems blindly execute, render, or store untrusted model output (XSS, RCE, SSRF via tool calls).
Last reviewed October 2026
Why LLM05 evidence is hard
The model is not the victim here; the system that trusts it is. Of the 1,683 templates mapped to this control, 1,679 ask the model to produce code and score whether the result carries a known weakness class, which is the downstream half of insecure generation. The blunt cases - HTML that renders, SQL that concatenates - are filed under the disclosure control instead, a residue of the older numbering. Treat model output as untrusted input and most of this follows.
How Penaxtra maps to LLM05
The LLM05 identifier is written onto the finding at the moment it is created, not mapped in afterwards, so the JSON and PDF exports come out already in your assessor's structure. Every finding carries the probe that was sent, a SHA-256 digest of the response it provoked, the tier that decided the verdict and its status history from first observation to close. Identity survives a re-scan: a control you closed and that comes back reopens under the same row with a reopen count, rather than arriving as a new issue.
LLM05 capabilities
Findings tagged with the OWASP LLM Top 10 LLM05 identifier
Penaxtra severity for this control (high)
Cross-framework identifiers attached to the same finding where controls overlap
PDF and JSON evidence export with the control identifier attached
LLM05 control coverage
Findings for LLM05 carry the OWASP LLM Top 10 LLM05 identifier along with the corresponding control identifiers in the other frameworks Penaxtra maps, so one result is reflected across each mapped framework.
Frequently asked
What is LLM05 (Improper Output Handling)?
Downstream systems blindly execute, render, or store untrusted model output (XSS, RCE, SSRF via tool calls). It is an OWASP LLM Top 10 control; Penaxtra assesses it at high severity.
How does Penaxtra test for LLM05?
The LLM05 identifier is written onto the finding at the moment it is created, not mapped in afterwards, so the JSON and PDF exports come out already in your assessor's structure. Every finding carries the probe that was sent, a SHA-256 digest of the response it provoked, the tier that decided the verdict and its status history from first observation to close. Identity survives a re-scan: a control you closed and that comes back reopens under the same row with a reopen count, rather than arriving as a new issue.
Does a finding for LLM05 help with an audit?
Each finding is tagged with the OWASP LLM Top 10 LLM05 identifier and exported in the PDF and JSON evidence pack, so it appears on the auditor control list with the identifier already attached.