CVE-2026-25960 is a high severity server-side request forgery bypass (CVSS 7.1) in vLLM, the LLM inference server. The earlier SSRF fix can be sidestepped because validation and the real request parse URLs differently. Upgrade to vLLM 0.17.0, which carries the fix. The record does not list it in CISA's KEV catalog, and the advisory we read does not report exploitation.
What's affected
- vLLM 0.15.1 and later, before 0.17.0
- Fixed in vLLM 0.17.0 (pull request 34743)
This issue is a bypass of the fix for CVE-2026-24779, which the earlier advisory lists as fixed in 0.14.1. So being on a version that has the first fix does not mean you are safe from this one. The advisory lists no workaround.
How to check if you're exposed
vLLM is a Python package, so ask pip:
pip show vllm
Compare the version with 0.17.0. If vLLM runs in a container or a managed platform, check the image tag or ask the platform owner which version is deployed. Pinned requirements files and lockfiles are the other place to look, since a project can lag its documentation.
Safeguard has a free in-browser dependency scan at https://gold.safeguard.sh/scan that reads a manifest or lockfile and flags known vulnerable packages, with no repository access needed.
What to do now
- Upgrade vLLM to 0.17.0 or later and redeploy every service that serves models.
- Confirm the version inside each running environment, not only in the requirements file.
- Restrict outbound traffic from inference hosts so a forged request cannot reach internal services or cloud metadata endpoints. This is general hardening, not advice from the advisory.
- Review which endpoints accept media by URL and who can call them.
- Record the CVE in your tracker with the fixed version so the check can be repeated.
Why it matters
CWE-918 is server-side request forgery: the server is persuaded to fetch a URL the attacker picked, from the server's own network position. The advisory says the first fix validated the host with urllib3.util.parse_url(), while load_from_url_async makes the real request through aiohttp, which parses URLs with the yarl library. The two disagree about how to read a backslash, so a URL can look harmless to the checker and point somewhere else for the client.
The CWE list also includes CWE-474, use of a function with inconsistent implementations. That is the real lesson. When validation and use rely on different parsers, the validator is only a guess about what the client will do. The sturdier pattern is to parse once and reuse the parsed result for both the check and the request.
The score is 7.1 because it needs a low privilege account and has high confidentiality impact: internal resources can be read.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
My earlier upgrade fixed CVE-2026-24779. Am I done?
No. This CVE is a bypass of that fix. The advisory says the affected range starts at 0.15.1 and the fix is 0.17.0, so you need the newer release.
Is there a workaround?
The advisory lists none. Upgrading is the remedy it names.
Sources
- https://github.com/vllm-project/vllm/security/advisories/GHSA-v359-jj2v-j536
- https://github.com/vllm-project/vllm/security/advisories/GHSA-qh4c-xf7m-gxfc
Last reviewed: 19 October 2026.
