CVE-2026-105757 vllm-project CVE debrief

Who should care

Defenders responsible for systems using the vLLM package, especially in shared engine setups, should assess exposure and prioritize patching or mitigation. This includes operators, platform administrators, vulnerability management teams, and security teams who need to review the vulnerability's impact on their environments and take necessary actions.

Why it matters

CVE-2026-105757 is a denial of service vulnerability in the vLLM package that allows an ordinary API request to cause an uncaught, engine-fatal exception. Defenders should prioritize patching or mitigating this vulnerability, especially in environments where the vLLM package is used in a shared engine setup.

• Denial of service for all concurrent and subsequent tenants of the engine
• Potential for data loss or service disruption
• Need for verification of affected versions and inventory checks
• Priority for patching or mitigating the vulnerability

Technical summary

The vLLM package is vulnerable to a denial of service attack due to an uncaught, engine-fatal exception caused by malformed structured-output requests. This issue affects vLLM ≤ 0.25.1 and is fixed in version 0.30.0. The root cause is the lack of a per-request exception boundary around structured-output grammar/token handling. Defenders should prioritize patching or mitigating this vulnerability, especially in environments where the vLLM package is used in a shared engine setup. The vulnerability is confirmed in vLLM ≤ 0.25.1, with the issue fixed in version 0.30.0.

Defensive priority

Defenders should prioritize patching or mitigating this vulnerability, especially in environments where the vLLM package is used in a shared engine setup.

Recommended defensive actions

• Patch vLLM to version 0.30.0 or later
• Implement compensating controls to limit exposure
• Monitor for suspicious API requests
• Verify inventory for affected versions
• Review compensating controls for exposed systems while remediation is scheduled and verified
• Check relevant monitoring, detection, and logs for exposed assets that need extra review
• Track exceptions, retest remediated assets, and close the item only after evidence is documented

Evidence notes

The vulnerability is confirmed in vLLM ≤ 0.25.1, with the issue fixed in version 0.30.0. The root cause is the lack of a per-request exception boundary around structured-output grammar/token handling.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.