Skip to content

GHSA-85xf-c7hm-whqw CVE-2026-105757 PYSEC-2026-4199

vLLM: Structured-output request errors escape the request boundary and terminate the shared EngineCore — engine-fatal denial of service (3 sites)

Medium PyPI
Severity
6.5 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
0.31%
Chance of exploitation in the next 30 days. Higher than 24.32% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-20 Improper Input Validation
CWE-248 Uncaught Exception
CWE-755 Improper Handling of Exceptional Conditions
Fix
0.30.0
Upgrade vllm to this version or later

Description

Affected

  • Ecosystem / package: pip / vllm
  • Affected versions: vLLM ≤ 0.25.1 (confirmed on 0.25.1, commit 752a3a504485). The lower bound predates 0.25.1; maintainers can confirm how far back each path reaches.

Summary

Three structured-output request paths let an ordinary request reach a condition that raises an uncaught, engine-fatal exception instead of a per-request validation error. The failure is not confined to the request that caused it: it escapes into EngineCore's busy loop and triggers a fatal _send_engine_dead(), so one malformed structured-output request denies service to all concurrent and subsequent tenants of that engine. The requests are ordinary API calls; the client does not need any privileged configuration beyond the (often default) structured-output feature.

The shared root cause is the absence of a per-request exception boundary around structured-output grammar/token handling: a value that should fail as a request-scoped validation error instead propagates as an uncaught exception (or bypasses frontend validation entirely) and reaches the scheduler/engine loop, which treats the failure as fatal.

These sites are distinct from the published fixes for GHSA-6qc9-v4r8-22xg and GHSA-8wr5-jm2h-8r4f: GHSA-6qc9 (PR #17623) added frontend json-schema/regex/type validation but the completion check on v0.25.1 still catches only TimeoutError, so Site 1's valid duplicate-root EBNF via the latched xgrammar backend still re-raises and kills EngineCore; GHSA-8wr5 (PR #44744) fixes recovered-token state in the eagle spec-decode path and explicitly does not treat trailing -1 padding as the fault, so Site 2's -1 reaching backend_guidance.validate_tokens() via ngram_gpu survives it.

Affected code

Links pinned to the confirmed commit 752a3a504485 (v0.25.1). The three sites are:

Site 1 — latched-backend compile exception escapes. StructuredOutputManager permanently latches one backend on the first structured-output request and always compiles through it, ignoring the per-request auto backend selection. A grammar that auto accepts only via a fallback backend (e.g. a duplicate-root EBNF) then makes the latched xgrammar compiler raise; the exception is stored in the grammar Future, and the completion check catches only TimeoutError, so Future.result() re-raises during scheduler promotion and kills EngineCore.

The escaping-exception sink: the completion check only handles TimeoutError, so any compile exception stored in the Future re-raises out of result() during scheduler promotion.

# vllm/v1/structured_output/request.py Lines 48-59
    def _check_grammar_completion(self) -> bool:
        # NOTE: We have to lazy import to gate circular imports
        from vllm.v1.request import RequestStatus

        if isinstance(self._grammar, Future):
            try:
                # We will check whether the future is ready within 100 us
                self._grammar = self._grammar.result(timeout=0.0001)
                self.status = RequestStatus.WAITING
            except TimeoutError:
                return False
        return True

Site 2 — guidance treats ngram_gpu -1 padding as a token id. The ngram_gpu proposer pads a fixed-width draft-token row with -1 and separately records num_valid_draft_tokens, but the scheduler forwards the untrimmed padded row into GuidanceGrammar.validate_tokens(), which passes -1 to the native llguidance matcher; the matcher cannot convert a negative value to its unsigned token type and raises an OverflowError, uncaught and fatal.

The sink passes the padded row straight to the native matcher with no lower-bound check on token ids:

# vllm/v1/structured_output/backend_guidance.py Lines 181-196
    def validate_tokens(self, tokens: list[int]) -> list[int]:
        """Checks if the list of tokens are accepted by the parser in sequence.
        Will not advance the parser.

        Returns the prefix list of tokens that are accepted by the parser.
        """
        if len(tokens) == 0:
            return []
        if self.ll_matcher.is_stopped():
            return []

        num_tokens = self.ll_matcher.validate_tokens(tokens)

        self.check_error()

        return tokens[:num_tokens]

Site 3 — Rust frontend accepts an empty structured-output value the Python frontend rejects. The opt-in Rust frontend admits an empty structured_outputs.json / structured_outputs.grammar string that the Python frontend rejects; the empty value passes through the wire-params conversion without validation, reaches the engine, and marks EngineCore dead.

The conversion maps each field to a constraint with no non-empty check, so an empty json/grammar string is forwarded unchanged:

// rust/src/engine-core-client/src/protocol/structured_outputs.rs Lines 135-162
impl TryFrom<WireStructuredOutputsParams> for StructuredOutputsParams {
    type Error = Error;

    fn try_from(raw: WireStructuredOutputsParams) -> Result<Self> {
        use StructuredOutputConstraint::*;

        let mut constraint = None;

        macro_rules! insert_constraint {
            ($name:literal, $value:expr) => {
                if let Some(value) = $value {
                    if let Some((existing, _)) = constraint {
                        return Err(Error::InvalidStructuredOutputsParams {
                            message: format!(
                                "multiple structured output constraints specified: {existing}, {}",
                                $name
                            ),
                        });
                    }
                    constraint = Some(($name, value));
                }
            };
        }

        insert_constraint!("json", raw.json.map(Json));
        insert_constraint!("regex", raw.regex.map(Regex));
        insert_constraint!("choice", raw.choice.map(Choice));
        insert_constraint!("grammar", raw.grammar.map(Grammar));

Impact

Any client able to send an ordinary structured-output request (two requests for Site 1) can terminate the shared EngineCore, denying service to all tenants of that engine instance. Availability only; no code execution, memory corruption, or data disclosure.

  • Site 1 affects the default "auto" structured-output backend; no speculative decoding or non-default configuration is required.
  • Site 2 requires a deployment using the guidance backend together with ngram_gpu speculative decoding; the -1 sentinel is produced by the proposer itself, so an ordinary constrained request suffices — the client does not craft the negative token.
  • Site 3 requires the opt-in Rust frontend; a single request with an empty constraint value is enough. API-key middleware narrows the attacker from unauthenticated to authenticated but does not restore the missing validation.

Suggested Fix

Convert structured-output failures into request-scoped errors at the boundary. Each site is a distinct fix shape; the core hunk for each is below.

Site 1 — resolve the backend per request instead of latching one process-wide, so a grammar is always compiled with the backend that auto actually selected for it (and a compile failure is that request's error, not the engine's):

# vllm/v1/structured_output/__init__.py — grammar_init(), replacing the latched-backend path
backend = self._get_or_create_backend(request.structured_output_request.backend)
if self._use_async_grammar_compilation:
    grammar = self.executor.submit(self._create_grammar, request, backend)
else:
    grammar = self._create_grammar(request, backend)

Site 2 — drop negative sentinels before handing the row to the native matcher, inside validate_tokens():

# vllm/v1/structured_output/backend_guidance.py — validate_tokens(), before the ll_matcher call
for i, token in enumerate(tokens):
    if token < 0:
        tokens = tokens[:i]
        break
if len(tokens) == 0:
    return []

Site 3 — reject empty json/grammar strings in the Rust wire-params conversion, matching the Python frontend, before the value reaches the engine:

// rust/src/engine-core-client/src/protocol/structured_outputs.rs — try_from(), before constraint mapping
if matches!(&raw.json, Some(Value::String(value)) if value.trim().is_empty()) {
    return Err(Error::InvalidStructuredOutputsParams {
        message: "structured_outputs.json cannot be an empty string".to_string(),
    });
}
if matches!(&raw.grammar, Some(value) if value.trim().is_empty()) {
    return Err(Error::InvalidStructuredOutputsParams {
        message: "structured_outputs.grammar cannot be an empty string".to_string(),
    });
}

The three sites share one root cause and the same fix shape (bound the failure to the request), so they are filed as a single advisory; happy to split into per-component advisories if the maintainers prefer. Each fix carries a regression test.

Credit

Reported by: Patch the Planet (Trail of Bits + OpenAI collaboration)

These vulnerabilities were discovered using GPT-5.5-Cyber as part of the Patch the Planet security initiative.


Proposed fix: a fix for this issue is proposed in a public pull request: https://github.com/vllm-project/vllm/pull/51450

Affected versions

PyPI

PackageVulnerableFixed in
vllm
< 0.30.0
0.30.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

vllm PyPI → 0.30.0

pip
pip install --upgrade "vllm>=0.30.0"
poetry
poetry add "vllm>=0.30.0"
uv
uv add "vllm>=0.30.0"

Severity breakdown

CVSS 3.1 6.5

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

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Weakness

CWE-20: Improper Input Validation

The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

How to prevent it
  • Architecture and Design: Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
  • Architecture and Design: Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
  • Architecture and Design, Implementation: Understand all the potential areas where untrusted inputs can enter the product, including but not limited to: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
  • Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
  • Implementation: When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.
  • Implementation: Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.
  • Implementation: Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.
  • Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
  • Implementation: When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.

CWE-248: Uncaught Exception

An exception is thrown from a function, but it is not caught.

CWE-755: Improper Handling of Exceptional Conditions

The product does not handle or incorrectly handles an exceptional condition.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-8397-8qf6-f2gm
vLLM: Phi-4 multimodal audio encoder materializes and retains full attention matrices: a single max-length audio OOM-crashes the vLLM engine
Medium Also affects vllm
GHSA-x567-49g5-p4cf
vLLM: Responses API bypasses trust_request_chat_template for chat_template_kwargs
Medium Also affects vllm
GHSA-vvpg-rrww-wpmh
vLLM: Permissive default CORS origins allow cross-origin requests to the vLLM HTTP server
Medium Also affects vllm
GHSA-q97c-p368-75c4
vLLM: Out-of-vocabulary prompt token id passes input validation and triggers a CUDA device-side assert (engine crash / DoS)
Medium Also affects vllm
GHSA-h3rc-j82p-2c3h
vLLM: Untrusted EPS inputs can trigger denial of service or Ghostscript RCE
High Also affects vllm
GHSA-gq5q-89c7-vhvx
vLLM DeepSeek-OCR image processing vulnerable to denial of service
Medium Also affects vllm
GHSA-6757-hggm-hp2w
vLLM: Public multimodal SHM handle forgery reaches worker-side `pickle.loads()` with insecure serialization disabled
High Also affects vllm
GHSA-542m-9234-8gvf
vLLM: DoS via unbounded chat_template Jinja2 rendering exhausts the renderer thread pool
Medium Also affects vllm
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor