vLLM vulnerable to Denial of Service by abusing xgrammar cache

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS

6.5 · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

EPSS

No dated EPSS signal available.

As published by the source; long descriptions are shortened.

Impact This report is to highlight a vulnerability in XGrammar, a library used by the structured output feature in vLLM. The XGrammar advisory is here: https://github.com/mlc-ai/xgrammar/security/advisories/GHSA-389x-67px-mjg3 The xgrammar library is the default backend used by vLLM to support structured output (a.k.a. guided decoding). Xgrammar provides a required, built-in cache for its compiled grammars stored in RAM. xgrammar is available by default through the OpenAI compatible API server with both the V0 and V1 engines. A malicious user can send a stream of very short decoding requests with unique schemas, resulting in an addition to the cache for each request. This can result in a Denial of Service by consuming all of the system's RAM. Note that even if vLLM was configured to use a different backend by default, it is still possible to choose xgrammar on a per-request basis using the guideddecodingbackend key of the extrabody field of the request with the V0 engine. This…

Published by the source

15 Apr 2025, 21:21 UTC

Last modified by the source

15 Apr 2025, 21:21 UTC

Source last checked

26 Oct 2026, 13:31 UTC

1. Revision 2 · amended · 26 Oct 2026

   Amended from ghsa record GHSA-hf3c-wxg2-49q9

2. Revision 1 · created · 24 Oct 2026

   Published from osv record GHSA-hf3c-wxg2-49q9

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: GHSA-hf3c-wxg2-49q9

Advisory: vLLM vulnerable to Denial of Service by abusing xgrammar cache
IDs: GHSA-hf3c-wxg2-49q9
Record: https://patchnext.com/advisories/ghsa-hf3c-wxg2-49q9 (revision 2, source checked 26 Oct 2026, 13:31 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: Medium (CVSS 6.5)
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor fix available; fixed versions by package: vllm 0.8.4. A vendor fix does not mean a deployment is fixed.

## Affected components
- PyPI vllm: affected >= 0.6.5, < 0.8.4; fixed in 0.8.4

## Suggested inspection (read-only)
- `python -m pip show vllm`: prints the installed version. Run with the environment that serves production active.

## Supported action
Upgrade each affected component to a fixed version on its release line. For a transitive dependency, upgrade the parent package or add an override or constraint, then regenerate the lockfile. Redeploy every environment that ran an affected version.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on vllm.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://osv.dev/vulnerability/GHSA-hf3c-wxg2-49q9 (OSV record GHSA-hf3c-wxg2-49q9 lists affected ranges: PyPI vllm >=0.6.5 <0.8.4 (fixed))
- Verified: https://github.com/advisories/GHSA-hf3c-wxg2-49q9 (GitHub-reviewed advisory GHSA-hf3c-wxg2-49q9 lists affected ranges: PyPI vllm >=0.6.5 <0.8.4)

Commands are suggestions: review each one before running it.