# vLLM Outlines Grammar Cache Exhaustion Attempt

- **Severity:** Medium
- **Signature ID:** `7b3f1c2e-9a54-4d6b-8f21-c0d47e6a15b9`

## Summary

vLLM's structured-output feature (guided_json, guided_regex, guided_grammar) compiles a new cached grammar for every schema it has not seen before. An attacker who sends a fast stream of requests each with a slightly different schema forces the server to keep compiling and caching new grammars, which can fill up disk space and eventually deny service.

## How the attack works

An attacker sends many structured-output HTTP requests to a vLLM endpoint in a short window, from what looks like one client process. Almost every request uses a schema that has never been seen before, so each one bypasses the cache and forces a new grammar to be compiled and stored. Because grammar compilation writes an unbounded new cache entry per unique schema, this drives continual disk growth. The rule watches for this specific pattern -- a high ratio of unique schemas to total requests within a 60-second window from one session -- rather than the disk-fill itself, since disk usage and service outage are not visible in the available telemetry.

## Why it matters

An attacker can push a vLLM server toward disk exhaustion and eventual denial of service by repeatedly triggering grammar cache writes, without needing valid credentials beyond normal API access.

## What you can do

- Set a cap on the number of distinct grammar/schema cache entries or total cache disk size vLLM is allowed to use, and evict or reject beyond that.
- Rate-limit or throttle structured-output requests per client/session, especially bursts of many distinct schemas in a short time.
- Monitor disk usage on hosts running vLLM's grammar cache directory and alert on rapid growth.
- If you run batch pipelines that legitimately generate unique per-document schemas, review their traffic pattern separately so it isn't confused with an attack, and consider giving them a separate rate allowance.

## Known benign look-alikes

- Batch document-extraction pipelines that synthesise a per-document JSON schema (enums built from that record's field values). Each request really is a new grammar, so the uniqueness ratio is legitimately high. Mitigated only by report-only action and the 25-request / 60-second floor; treat repeated hits from the same pipeline as a tuning signal, not an incident.
- CI regression or conformance suites that sweep many guided_json / guided_regex variants against a development vLLM endpoint.
- Benchmark and load-test harnesses for Outlines/XGrammar that generate randomised schemas by design.
- Agent frameworks that embed a run id, timestamp or trace id into the schema title or description, making otherwise identical schemas hash uniquely. Whitespace is normalised before hashing, but injected identifiers are not stripped.
- Multi-tenant gateways where many distinct tenants' schemas are proxied through one agent process instance, so unrelated tenant diversity accumulates on one session counter.

## References

- https://github.com/vllm-project/vllm/security/advisories
- https://dottxt-ai.github.io/outlines/
- https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/
- https://attack.mitre.org/techniques/T1499/003/

---
Source: https://www.netzilo.com/threats/vllm-outlines-cache-exhaustion