vLLM Guided Decoding Invalid JSON Schema DoS

How the attack works

An attacker sends a normal-looking completion request to a vLLM endpoint (/v1/completions, /v1/chat/completions, or /generate) with a guided_json or json_schema parameter attached. Inside that schema, the 'type' field is set to something invalid: a programming-language type like 'int' or 'dict', a misspelling like 'stsring', wrong casing like 'String', or a non-string value like a number or empty array. vLLM passes this schema to the xgrammar library to compile a decoding grammar, xgrammar rejects the bad type with an unhandled runtime error, and that error propagates up and terminates the server. Every request in flight, and every request queued afterward, fails until the process is restarted.

Netzilo detection

Why it matters

A single crafted request with no authentication bypass or exploit chain required can take down the inference server, dropping all pending and future requests until it's manually restarted. This is a straightforward denial-of-service against any exposed vLLM deployment that accepts guided decoding parameters.

What you can do

• →Validate guided_json/json_schema payloads server-side before passing them to the inference engine, rejecting any schema with a non-canonical or malformed 'type' value.
• →Run vLLM behind a process supervisor that auto-restarts on crash, and add restart-rate alerting so repeated crashes are visible quickly.
• →Rate-limit and authenticate access to completion endpoints that accept guided decoding parameters, since this is a low-effort, unauthenticated crash trigger if exposed publicly.
• →Track vLLM/xgrammar upstream fixes that catch and gracefully handle schema-compilation errors instead of letting them terminate the engine core.

Known benign look-alikes

• Developer iterating on a guided decoding schema who introduces a genuine typo. The request still crashes or errors the inference server, so it is worth surfacing, but it is not an attack.
• vLLM CI / integration suites and schema fuzzing harnesses that deliberately post malformed schemas against a staging endpoint. Partially suppressed by filter_test_harness when the client self-identifies in user/metadata.
• A user pasting a broken JSON Schema into the prompt and asking the model to fix it. Structurally impossible to match (in-string JSON must escape its quotes and the patterns require unescaped quotes); filter_prompt_repair is a second line of defence for oddly encoded bodies.
• Clients that intentionally send loose type vocabulary such as "int" or "bool" to a gateway that normalises the schema before forwarding to vLLM; those requests never reach xgrammar in their invalid form.
• Non-vLLM services that happen to expose a path containing "/completions" or "/generate" and accept a json_schema field with non-standard type tokens.

References

• https://owasp.org/Top10/A03_2021-Injection/
• https://cwe.mitre.org/data/definitions/20.html
• https://docs.vllm.ai/en/latest/features/structured_outputs.html
• https://attack.mitre.org/techniques/T1499/004/