High Logic / Race / Validation

Parser Differential (Validation Bypass)

One component checks the input and another consumes it. If they parse bytes differently - e.g. duplicate JSON keys - the filter approves what the app acts on.

Guardrail / Policy Bypass

LLM05CWE-436

Tells spot it before you commit

» The same input is validated by one parser (regex/WAF) and consumed by another (real parser).
» A single "bad" value is blocked, but the app re-parses the payload downstream.
» You can carry raw bytes through verbatim (uploaded file/blob) past the LLM's normalization.

Method

Find where a filter and the consumer disagree - regex matches first key, JSON parser keeps last.
Send duplicate/ambiguous structures so the guard sees "safe" and the app sees the real value.
Carry the raw payload through a channel stored verbatim, since the LLM normalizes JSON in tool calls.

Payloads templates - adapt to authorized scope

Duplicate JSON keys (filter sees first, parser keeps last) json

{"status":"SAFE","status":"error","cache_task_id":"<id>"}

Other differential levers to try text

trailing data · comments · unicode/whitespace · content-type confusion (XML vs JSON)
integer/leading-zero/overflow · case sensitivity · array-vs-scalar coercion

Why it works

A regex/WAF and a real parser interpret the same bytes under different rules. The filter validates its reading; the consumer acts on a different reading - so an input that "passes" is not the input that runs (CWE-436 Interpretation Conflict).

Impact

Bypass of security validation: smuggle a blocked status/role/command past the guard into the component that actually enforces behavior.

Defenses

Canonicalize, then validate the parsed object the consumer will use; never re-parse after validation.
Reject ambiguous input (duplicate keys, trailing data); use one strict parser end-to-end.
Validate at the sink, not on the raw string.

Mappings

OWASP LLM

LLM05 - Improper Output Handling

CWE

CWE-436 - Interpretation Conflict (Parser Differential)