vLLM audit exposes a critical auth bypass and four denial-of-service paths

An independent security audit of vLLM found five vulnerabilities: one rated Critical and four rated High. The audit covered vLLM 0.14.0 and retested its findings against 0.29.0; the audit firm’s summary says the remaining four security findings could let attackers exhaust resources and stop the API without recovery.

The Critical finding is the broader concern. X41 D-Sec identified BadHost, tracked as CVE-2026-48710, while reviewing vLLM’s API-key middleware. The flaw affected Starlette versions before 1.0.1 and allowed a crafted Host header to make authentication middleware see one path while the application router handled another, according to X41’s technical account.

Why this matters now

In vLLM, the mismatch could bypass API-key checks on /v1 endpoints. X41 says the vulnerable pattern also appeared across FastAPI and Starlette applications, including LiteLLM, MCP servers and AI-agent frameworks. The same account says CISA added CVE-2026-48710 to its Known Exploited Vulnerabilities catalog in September after malicious actors chained it with other flaws.

The four High findings are different forms of denial of service. X41 says an attacker could consume resources through requests containing many anyOf branches in a guided_json schema, or by asking vLLM to load very large files through image_embeds, prompt_embeds or multimodal media inputs. The audit also recorded 15 findings without direct security impact, covering SSRF, information disclosure, denial-of-service and hardening recommendations, according to the published audit summary.

What operators should do

The Open Source Technology Improvement Fund, which organized the audit, says vLLM maintainers addressed the reported issues and advises operators to update to the current release. Because the audit’s retest baseline was vLLM 0.29.0, teams should not read that version number alone as a permanent safe harbor; they should follow the current supported vLLM release and verify the resolved dependency set in the deployment they actually ship.

Teams running vLLM behind a reverse proxy should not assume that boundary removes BadHost exposure. X41 says some deployments pass X-Forwarded-Host through as Host, potentially defeating validation performed earlier in the request path. The practical check is therefore end to end: update vLLM and Starlette dependencies, confirm proxy header handling, and retest that unauthenticated requests cannot reach protected /v1 routes.

This is a security story because the audit’s Critical finding is also documented as exploited in the wild. The broader lesson is architectural: authentication should not depend on two components deriving a request path differently.