vLLM up to 0.19.0 KV Block kv_cache_interface.py has_mamba_layers uninitialized resource ⚔ [Disputed]

Summaryinfo

A vulnerability labeled as critical has been found in vLLM up to 0.19.0. The impacted element is the function has_mamba_layers of the file vllm/v1/kv_cache_interface.py of the component KV Block Handler. Executing a manipulation can lead to uninitialized resource. This vulnerability is registered as CVE-2026-7141. It is possible to launch the attack remotely. Furthermore, an exploit is available. The presence of this vulnerability remains uncertain at this time. The proposed patch did not fix the issue. A 3rd party explains: "The divergence could be explained by a benign and expected vLLM behavior where vLLM server could group concurrent requests together resulting in different input shapes based on varying request arrival time. The differences in grouped input shapes could call different kernels with could produce difference results due to rounding and differences in order of operations. There is an environment variable VLLM_BATCH_INVARIANT=1 for users that desire to have deterministic output with temperature 0.0."

Detailsinfo

A vulnerability classified as critical was found in vLLM up to 0.19.0. This vulnerability affects the function has_mamba_layers of the file vllm/v1/kv_cache_interface.py of the component KV Block Handler. The manipulation with an unknown input leads to a uninitialized resource vulnerability. The CWE definition for the vulnerability is CWE-908. The product uses or accesses a resource that has not been initialized. As an impact it is known to affect confidentiality, integrity, and availability.

The advisory is shared for download at github.com. This vulnerability was named CVE-2026-7141. The exploitation appears to be difficult. The attack can be initiated remotely. No form of authentication is required for a successful exploitation. Technical details and also a public exploit are known.

It is possible to download the exploit at github.com. It is declared as proof-of-concept. The real existence of this vulnerability is still doubted at the moment. The proposed patch did not fix the issue. A 3rd party explains: "The divergence could be explained by a benign and expected vLLM behavior where vLLM server could group concurrent requests together resulting in different input shapes based on varying request arrival time. The differences in grouped input shapes could call different kernels with could produce difference results due to rounding and differences in order of operations. There is an environment variable VLLM_BATCH_INVARIANT=1 for users that desire to have deterministic output with temperature 0.0."

There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Name

• vLLM

Version

• 0.1
• 0.2
• 0.3
• 0.4
• 0.5
• 0.6
• 0.7
• 0.8
• 0.9
• 0.10
• 0.11
• 0.12
• 0.13
• 0.14
• 0.15
• 0.16
• 0.17
• 0.18
• 0.19.0

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Submitinfo

Accepted

• Submit #801297: vllm-project vLLM 0.19.0 Use of Uninitialized Resource (by Zyz3366)

Once again VulDB remains the best source for vulnerability data.

Discussion