CVE-2026-25960
7.1vLLM Project · vLLM
A Server-Side Request Forgery vulnerability exists in vLLM due to inconsistent URL parsing between the validation and request layers, allowing attackers to bypass SSRF protections.
Executive summary
A Server-Side Request Forgery vulnerability in vLLM versions 0.15.1 through 0.16.9 allows authenticated attackers to bypass security controls and potentially access internal network resources.
Vulnerability
This is a Server-Side Request Forgery (CWE-918) vulnerability occurring in the load_from_url_async method. It stems from a discrepancy in how user-provided URLs are parsed by the validation library versus the aiohttp client, allowing an authenticated user to reach unintended internal endpoints.
Business impact
The vulnerability carries a CVSS score of 7.1, indicating high severity. Successful exploitation allows an attacker to interact with internal services that are not exposed to the public internet, potentially leading to unauthorized data access or the exposure of sensitive internal infrastructure information. The risk is compounded by the role of vLLM in handling large language model deployments, which often reside in sensitive environments.
Remediation
Immediate Action: Upgrade to vLLM version 0.17.0 or later to resolve the parsing inconsistency and patch the SSRF vulnerability.
Proactive Monitoring: Monitor application logs for unusual outbound connection patterns or requests directed toward internal IP addresses or private network segments originating from the vLLM instance.
Compensating Controls: Implement strict egress filtering on the server hosting vLLM to prevent unauthorized outbound connections to internal network segments, effectively neutralizing the impact of the SSRF.
Exploitation status
Public Exploit Available: No — no confirmed public exploit exists.
Analyst recommendation
Given the potential for internal network discovery and unauthorized interaction with sensitive services, organizations should prioritize the update to version 0.17.0. Verify all deployments of the vLLM engine and ensure that patching schedules are updated to include this version immediately to mitigate the risk of internal network exposure.