{"answers":{"affected":"2 open source packages ship an affected version, including vllm.","exploited":"There is no known exploitation of GHSA-hf3c-wxg2-49q9 in the wild and no public exploit code.","fix":"Upgrade vllm to 0.8.4 or later.","what":"GHSA-hf3c-wxg2-49q9 is a denial of service vulnerability in vllm, published on 15 Apr 2025. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for GHSA-hf3c-wxg2-49q9 and fix it if it is affected.\n\nWhat it is: GHSA-hf3c-wxg2-49q9 is a denial of service vulnerability in vllm, published on 15 Apr 2025. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of GHSA-hf3c-wxg2-49q9 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- vllm (PyPI): affected from 0.6.5; fixed in 0.8.4\n- vllm (PyPI): affected from 0.6.5; fixed in 0.8.4\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-hf3c-wxg2-49q9/ (Markdown: https://insights.sbomify.com/GHSA-hf3c-wxg2-49q9/index.md)","id":"GHSA-hf3c-wxg2-49q9","markdown":"https://insights.sbomify.com/GHSA-hf3c-wxg2-49q9/index.md","name":"GHSA-hf3c-wxg2-49q9","record":{"aliases":[],"analysis":{"component_type":"library","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"yes","non_default_config":false,"product_category":"LLM inference library","requires_auth":"none","summary":"Attackers can cause Denial of Service by exhausting RAM via unique schema requests in vLLM's xgrammar cache.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"### Impact\n\nThis 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\n\nThe [xgrammar](https://xgrammar.mlc.ai/docs/) 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.\n\nA 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.\n\nNote 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 `guided_decoding_backend` key of the `extra_body` field of the request with the V0 engine. This per-request choice is not available when using the V1 engine. \n### Patches\n\n* https://github.com/vllm-project/vllm/pull/16283\n\n### Workarounds\n\nThere is no way to workaround this issue in existing versions of vLLM other than preventing untrusted access to the OpenAI compatible API server.\n\n### References\n\n* https://github.com/mlc-ai/xgrammar/security/advisories/GHSA-389x-67px-mjg3","ecosystems":["PyPI"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"vLLM vulnerable to Denial of Service by abusing xgrammar cache","id":"GHSA-hf3c-wxg2-49q9","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"PyPI","product":null,"products":[],"type":"denial_of_service","year":"2025"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"PyPI","fixed":["0.8.4"],"introduced":["0.6.5"],"last_affected":[],"package":"vllm","purl":null,"source":"GHSA-hf3c-wxg2-49q9"},{"ecosystem":"PyPI","fixed":["0.8.4"],"introduced":["0.6.5"],"last_affected":[],"package":"vllm","purl":"pkg:pypi/vllm","source":"GHSA-hf3c-wxg2-49q9"}],"products":null,"published":"2025-04-15","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"Attackers can cause Denial of Service by exhausting RAM via unique schema requests in vLLM's xgrammar cache.","url":"https://insights.sbomify.com/GHSA-hf3c-wxg2-49q9/"}