vLLM CVE-2026-100649

Requires a vLLM deployment (before 0.29.0) that accepts video inputs and uses the PyNvVideoCodec decoder path with configured decoder allocation limits - the flaw is specific to that multimodal video-decode feature, so text-only or non-video deployments are not exposed. Exploitation requires the ability to select among multiple sampler subclasses in requests so their allocation counters increment independently and bypass the shared cap. The CVSS vector marks it unauthenticated (PR:N) and network-reachable (AV:N), but AC:H and AT:P indicate success is not deterministic: it depends on winning allocation/timing conditions across repeated requests, and real-world exposure is further limited where the vLLM API endpoint is fronted by an API key or network gateway. Impact is limited to availability degradation via GPU memory exhaustion (VA:L) - no data disclosure or code execution.

This is a genuine but low-severity availability issue, not a critical priority. The vendor's CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N) yields only 6.3 (MEDIUM) and, critically, sets only VA:L - a LOW availability impact with no confidentiality or integrity impact (VC:N/VI:N). This is consistent with the description: a resource-limit bypass that exhausts 'unaccounted GPU memory', i.e. degraded service rather than a full crash or RCE. Key tempering signals are AC:H and AT:P: exploitation is not trivially reliable - the attacker must repeatedly select differing sampler subclasses to shadow the decoder counter and win against normal allocation behavior, and success depends on race/timing conditions. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no evidence of active or automated exploitation - the profile is theoretical/reported-by-researcher (VulnCheck) rather than in-the-wild. Signals are internally consistent: a network-reachable but hard-to-reliably-trigger, availability-only weakness. The one caveat worth verifying is the auth boundary - the description says 'unauthenticated' and the vector confirms PR:N, but real vLLM deployments frequently sit behind an API key or gateway, which would raise the effective privilege bar. Overall: real bug, low real-world urgency.

An attacker with network access to a vLLM server that accepts video inputs submits multiple inference requests, each choosing a different sampler subclass so that per-subclass counters increment independently and never reach the configured PyNvVideoCodec decoder cap. By repeatedly instantiating decoders that escape accounting, the attacker allocates GPU memory beyond the intended limit, degrading service for legitimate users. No public exploit code is identified at time of analysis, and the CVSS AC:H/AT:P metrics indicate reliable triggering requires favorable timing and repeated attempts.