vLLM is the inference engine a large share of self-hosted stacks run
behind their agents. That makes its 2026 CVE run everyone's problem,
not just the maintainers'. Two themes carry through the whole cluster:
one critical authentication bypass, and a trust_remote_code problem
that keeps resurfacing in a new file each release. Here is the honest
accounting, with the version you need to be on and the settings to
lock down.
## The one that matters most: the auth bypass
CVE-2026-48746 is the critical one, CVSS 9.1. The
AuthenticationMiddleware on vLLM's OpenAI-compatible API can be
bypassed. The mechanism is a trust problem between layers: the
middleware trusts data handed to it by the ASGI web server, and
starlette in turn trusts those servers, so a caller can reach the API
without presenting the configured VLLM_API_KEY. The affected range
is wide — 0.3.0 up to 0.22.0 — which is most of the versions in
production right now.
The practical failure is blunt. If you set VLLM_API_KEY and assumed
that made your endpoint safe to expose, it did not. An unauthenticated
caller can drive your model, burn your GPU, read completions, and use
the server as an open relay. Fixed in 0.22.1. If you take one thing
from this article: get to 0.22.1 or later, and until you have, treat
the API as if the key does not exist — because for an attacker who
knows this bug, it does not.
## The trust_remote_code problem that will not die
vLLM inherits HuggingFace's trust_remote_code mechanism, which lets
a model repository ship Python that runs on load. The safe default is
--trust-remote-code=False. Three separate CVEs in 2026 undermined
that default in three different ways.
CVE-2026-4944 (HIGH, 8.8) is the plainest. Two model files in 0.14.1,
nemotron_vl.py and kimi_k25.py, hardcoded trust_remote_code=True.
If you loaded either model, your explicit --trust-remote-code=False
was silently overridden and the model's code ran anyway. The user's
security choice was ignored by the code path itself.
CVE-2026-5817 (HIGH, 8.2) is the same class in a different backend.
The vllm-metal backend, as shipped in Docker Model Runner on macOS,
unconditionally sets trust_remote_code=True and runs without a
sandbox. AutoTokenizer will then execute arbitrary Python from any
model pulled from an OCI registry. Pull a poisoned image, tokenise a
prompt, and the model author owns your machine. This is the
supply-chain attack the security playbook keeps warning about, made
concrete: see /guides/self-hosted-ai-security-playbook-2026.
CVE-2026-41523 (HIGH, 7.5) is the subtlest and my favourite kind of
bug to point at. A security check in activation-function loading was
written as a Python assert. Under Python's optimised mode — -O,
which strips every assert from the bytecode — that check simply does
not exist. Run vLLM under python -O and an unauthenticated attacker
gets arbitrary code execution by publishing a malicious HuggingFace
model. It was present prior to 0.22.0. The lesson is general and
worth internalising: a security invariant enforced by assert is not
enforced in production if anyone ever runs the interpreter optimised.
## The build chain and the memory-safety cluster
CVE-2026-54232 (HIGH, 8.8) moves the attack to build time. vLLM's
Dockerfile installed flashinfer-jit-cache from a custom index using
--extra-index-url without pinning. That is a textbook
dependency-confusion setup: pip can resolve the name against the wrong
index and pull an attacker's package into your image. Fixed prior to
0.22.1. If you build vLLM images yourself, pin your build dependencies
by version and, ideally, by hash — do not let --extra-index-url
decide what "latest" means.
The rest are memory-safety and denial-of-service issues that matter most if you accept requests from anyone you do not fully trust.
- CVE-2026-53923 (HIGH, 7.5): integer truncation of tensor dimensions
- CVE-2026-56340 (HIGH, 8.8): missing sparse-tensor validation in the
- CVE-2026-5497 (HIGH, 7.5): an out-of-memory denial of service via
## What to do right now
The remediation is boring, which is the point.
- Upgrade to at least 0.22.1, and prefer the latest release. 0.22.1
- Never run vLLM under
python -O. Check your container entrypoints - Keep
--trust-remote-code=Falseand understand it is not - Do not expose the OpenAI-compatible API to the internet
- Pin build dependencies. If you build your own images, version-pin
- If you take untrusted multimodal or prompt-embeds input, the DoS and
The through-line is the one we keep landing on: a model is code, an
inference server is an application with an attack surface, and a
config default only protects you if the code respects it. vLLM's 2026
run is a case study in all three. Get to 0.22.1 or later, drop -O,
and stop trusting model repositories you have not read. If you want to
track vLLM disclosures as they land rather than reading advisories one
at a time, the free tracker is at /cves, and /scanner will check a
requirements.txt or docker-compose.yml against this list for you.