vLLM Outlines Grammar Cache Exhaustion
An attacker sends a flood of requests to a vLLM server's structured-output feature, making every request use a brand-new JSON schema. Because vLLM caches a compiled grammar file for every distinct schema and never deletes old ones, this fills up the server's disk and can take the service down for everyone using it.
How the attack works
vLLM's guided-decoding feature (Outlines backend) compiles a grammar for each unique schema it sees and writes it to a local cache with no cleanup. An attacker scripts a high volume of short requests, each carrying a schema that has never been used before, within a short time window. The cache grows without bound as it stores a new grammar file per request. Eventually the filesystem fills up, causing failures for all tenants sharing that vLLM instance. The detection ties this pattern to a single session by tracing process lineage, so it flags one session's request flood, not cross-session or cross-user correlation.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 3f7c1a92-8b4e-4d61-9a05-6e2fb1c7d840
- Severity
- High
Why it matters
A single malicious session can exhaust disk space on a shared vLLM server, causing denial of service for every other user or application relying on that endpoint.
What you can do
- →Set a size cap and eviction policy on the grammar/schema cache directory, or move it to a bounded, auto-cleaned filesystem.
- →Rate-limit or throttle structured-output requests per session/API key, especially bursts of distinct schemas.
- →Monitor disk usage on vLLM hosts and alert before it reaches capacity.
- →Review high-volume structured-output workloads (benchmarks, fuzzers, CI suites) and separate them from production infrastructure to avoid false alarms and real exhaustion alike.
Known benign look-alikes
- Evaluation or benchmark harnesses that emit a distinct JSON schema per test item (for example per-document field extraction), producing many unique schemas quickly.
- Schema fuzzing or conformance suites run against a self-hosted vLLM endpoint in CI.
- Agent frameworks that inline request-specific enum values, IDs or few-shot examples inside the schema, making every schema textually unique for an otherwise benign workload.
- Deliberate load or capacity testing of a structured-output endpoint.
- Mitigations - the rule requires at least 25 schema-bearing POSTs from ONE process session inside a 5-minute window, a >=90% unique-to-total schema ratio, applies a 10-minute per-session cooldown so a sustained job reports once rather than continuously, and only ever reports (never blocks) so no inference request is interrupted.