CVE Vulnerability Catalog

Netty HttpServerCodec up to 4.2.17.Final and 4.1.137.Final incorrectly pairs responses with requests when HTTP/1.1 pipelining with Expect: 100-continue is used, leading to response splitting and unsafe connection reuse.

Netty from 4.2.11.Final before 4.2.18.Final has an incomplete hostname verification fix in the QUIC certificate path when using a plain X509TrustManager, allowing attackers to present a certificate for the wrong hostname.

Netty's HTTP/3 codec from 4.2.2.Final through 4.2.17.Final builds the :authority pseudo-header from the Host header before considering the authority of an absolute-form request-target, leading to authority confusion.

Netty's HTTP/3 codec from 4.2.2.Final through 4.2.17.Final does not special-case HTTP/1 CONNECT authority-form request-targets, resulting in malformed HTTP/3 CONNECT with attacker-controlled authority.

Netty's HTTP/3 codec from 4.2.0.Final through 4.2.17.Final has an uncontrolled resource consumption vulnerability in the QPACK encoder-stream instruction decoder, allowing an attacker to declare huge literal lengths, causing unbounded heap growth and OutOfMemoryError.

Netty's QPACK prefixed-integer decoder (netty-codec-http3) from 4.2.0.Final through 4.2.17.Final does not bound continuation bytes, allowing an attacker to cause O(N^2) CPU cost and memory growth, leading to OOM and event-loop starvation.

Netty's HTTP/3 codec from 4.2.0.Final through 4.2.17.Final retains unbounded per-stream QPACK encoder state, allowing an attacker to cause unbounded heap growth and denial of service.

Netty's HTTP/3 codec (io.netty:netty-codec-http3) in versions 4.2.0.Final through 4.2.17.Final does not enforce the RFC 9114 requirement that the :authority pseudo-header field and a literal host header field, when both present, carry the same value. A remote unauthenticated peer can send a single HEADERS frame containing both fields with differing, attacker-controlled values; the request is accepted and delivered to the application with two conflicting authorities, allowing routing, virtual-host, and access-control decisions to be bypassed when different components in the request path consult different fields. This issue is fixed in 4.2.18.Final.

This CVE ID has been rejected as a duplicate. No further vulnerability information is available.

This CVE ID has been rejected as a duplicate. No further vulnerability information is available.

This CVE ID has been rejected as a duplicate. No further vulnerability information is available.

This CVE ID has been rejected as a duplicate. No further vulnerability information is available.

vLLM before 0.29.0 accepts user-controlled stop_token_ids on the OpenAI-compatible POST /v1/completions and POST /v1/chat/completions endpoints but validates only that the values are integers, not that each token id is within the model vocabulary/logits range. When min_tokens > 0, the stop token ids are used as logits indices to suppress stop tokens, so an out-of-range id reaches a CUDA indexing operation (index_put_) and triggers a device-side assertion. An authenticated API user can send a single malformed completion request that returns 500 Internal Server Error and puts EngineCore into a fatal state, causing subsequent requests to fail until the service is restarted (denial of service).

In vLLM versions 0.22.1 through 0.28.0, the operator-supplied model revision pin (--revision / --code-revision) is not propagated to several Hugging Face artifact loads for the FunAudioChat and Tarsier2 architectures. This causes pinned deployments to still resolve behavior-affecting artifacts from the repository's default revision, potentially altering audio preprocessing, speech tokenizer behavior, or Tarsier2 configuration without any change to the operator's configured pin. This is a supply-chain integrity and reproducibility failure, but not remote code execution or a trust_remote_code=False bypass. Fixed in version 0.28.0.

vLLM versions 0.22.0 through 0.23.0 fail to validate stop_token_ids against vocabulary bounds in Rust HTTP and gRPC frontends, allowing out-of-vocabulary token IDs to reach MinTokensLogitsProcessor. Attackers can submit requests with min_tokens greater than zero and out-of-vocabulary stop_token_ids to trigger CUDA tensor indexing failures that leave EngineCore in a fatal state requiring service restart.

vLLM before 0.29.0 fails to enforce decoder prompt-length validation on the disaggregated serving endpoint /inference/v1/generate. When the request contains a 'features' (multimodal) payload, caller-supplied token_ids are not checked against model_config.max_model_len, and for multimodal processors reporting skip_prompt_length_check=True an overlong prompt reaches the worker input-batch copy into a fixed max_model_len-wide NumPy row. A client able to reach the endpoint can trigger a worker failure and denial of service.

vLLM through 0.29.0 fetches and fully materializes remote or inline media before enforcing its documented media controls (the VLLM_MAX_AUDIO_CLIP_FILESIZE_MB compressed-audio size cap, default 25 MB, and per-modality --limit-mm-per-prompt item limits). Across four ingress paths the server reads the entire HTTP response body, base64-decodes the inline payload, or spawns one fetch/decode task per media part, and only then applies the limit (or never applies it). A remote attacker can cause pre-inference memory and bandwidth exhaustion (denial of service).

vLLM before 0.29.0 contains a resource-limit bypass vulnerability in PyNvVideoCodec decoder allocation where sampler subclass shadowing allows independent counter increments. Unauthenticated attackers can select different sampler subclasses in video requests to exceed configured decoder limits and exhaust unaccounted GPU memory.

vLLM before 0.29.0 fails to enforce the VLLM_MAX_AUDIO_CLIP_FILESIZE_MB limit in multimodal chat audio decoding, allowing unauthenticated clients to bypass file size restrictions. Attackers can submit oversized audio files through chat endpoints to consume excessive memory and CPU resources during decoding.

vLLM versions before 0.29.0 contain a denial-of-service vulnerability in the cache_salt parameter accepted on OpenAI-compatible and Anthropic API endpoints, which lacks maximum length validation and is processed on the single EngineCore scheduler thread. Unauthenticated attackers can send HTTP requests with multi-hundred-megabyte salt values that trigger expensive pickle serialization and SHA-256 hashing, stalling the scheduler thread and denying service to all concurrent requests.