The vulnerability (GHSA-9hcf-v7m4-6m2j) describes a denial of service in vLLM where providing an invalid regex during structured output processing can crash the server. This is similar to a previous vulnerability involving invalid JSON schemas (GHSA-6qc9-v4r8-22xg).
The provided patch (commit 08bf7840780980c7568c573c70a6a8db94fd45ff) directly addresses this issue. The core change is in the vllm/v1/structured_output/backend_xgrammar.py file, within the validate_xgrammar_grammar function. Here, a try-except block was added around the xgr.Grammar.from_json_schema(schema) call. This indicates that this specific call was the point of failure when encountering a malformed schema, potentially derived from or representing an invalid user-supplied regex.
Prior to the patch, an unhandled exception from xgr.Grammar.from_json_schema would propagate up and crash the server. The validate_xgrammar_grammar function, by calling this potentially crashing external/library function without adequate error handling for this specific failure mode, is the vulnerable function within the vLLM codebase. It processes the malicious input (or its derivative) and contained the flaw (lack of specific error handling) that led to the DoS.
The commit message "[Bugfix] validate grammar and throw 400 error instead of crashing the engine when xgrammar validation fails" further supports that the crash originated in the xgrammar validation path.
While test cases use guided_regex, and the _validate_structured_output function in vllm/v1/engine/processor.py has a direct path for guided_regex to the guidance backend, the actual fix for the crash is in the xgrammar backend's validation logic. This implies that either the xgrammar backend can also be involved in processing regexes (perhaps after some conversion or if embedded in other structures), or the vulnerability was specifically tied to how xgrammar handled schema generation/validation that could be influenced by an invalid regex.
The function vllm.v1.structured_output.backend_xgrammar.validate_xgrammar_grammar would appear in the stack trace during exploitation as it's the direct caller of the code that failed. The patch ensures this function now handles the error gracefully.