Deploying vLLM in Production: Security Hardening for Self-Hosted LLM Inference

vLLM's HTTP server, gRPC listener, and distributed communication layer were built to run fast inside a cluster you already control. That assumption is stated directly in vLLM's own security documentation: internal communications between nodes in a multi-node deployment are insecure by default and must be protected by placing the nodes on an isolated network, PyTorch Distributed features are intended for internal communication only and are not built for use in untrusted environments, and the gRPC listener binds to the same host address as the HTTP server with no authentication or encryption. None of that is a defect. It is a deliberate tradeoff for performance, and it becomes a real exposure only when a team assumes that the same server is safe to bind to a public interface, expose behind a load balancer without a proxy in front of it, or share across tenants without additional isolation.

The most common real-world version of this problem is simple: an engineer follows a quickstart, runs vllm serve <model>, opens the port to make the API reachable from another service or from the internet, and never revisits the question of what exactly is reachable on that port. The answer, on an unhardened deployment, is more than the chat completions endpoint.

The --api-key flag (or the VLLM_API_KEY environment variable) is vLLM's built-in authentication mechanism for the OpenAI-compatible server, and it is easy to assume it covers the whole HTTP surface. According to vLLM's own documentation, it does not. It authenticates only requests to endpoints under the /v1, /v2, and /inference path prefixes. Several other endpoints on the same server, reachable on the same port, are not covered:

The practical conclusion, stated plainly in vLLM's own guidance: do not rely on --api-key alone to secure a vLLM deployment. It is one control among several, not a perimeter.

Confirm these before starting the procedure below. Skipping this inventory step is the most common reason a hardening pass misses something.

First, know your vLLM version and check it against current advisories, since several of the CVEs covered later in this guide are fixed only in specific version ranges and an outdated deployment may already be exploitable regardless of any configuration change. Second, know your deployment topology: a single-node, single-tenant deployment behind an internal load balancer has a materially smaller attack surface than a multi-node deployment using Ray or PyTorch Distributed, or one serving multiple models or tenants from a shared instance. Third, know whether trust_remote_code is set anywhere in your serving configuration, and if so, whether the model repository it applies to is one your organization controls or merely trusts. Fourth, know where your model weights actually came from: a named, verifiable source (a vendor's official Hugging Face org, an internal artifact registry) versus a community mirror with no provenance chain changes the answer to several steps below. Fifth, know what already sits in front of vLLM on the network path: nothing, a plain load balancer, or a reverse proxy capable of enforcing its own auth and routing rules. That last fact determines how much of this procedure vLLM itself has to do versus how much a proxy layer can do for it.

Work through these in order. Each step assumes the previous one is done; skipping the reverse proxy step and going straight to API keys, for example, leaves the unauthenticated endpoints in the reference table above fully exposed regardless of how well the key is managed.

The network and authentication steps above close the perimeter. These steps address what happens once a request is already inside it, whether from a legitimate but noisy tenant, a malicious prompt, or a compromised model artifact.

Do not consider this procedure done until each control has been checked from outside the deployment, not just configured. Run these checks from a network position equivalent to a real attacker, meaning outside your own trusted subnet where possible.

Confirm the unauthenticated endpoints are unreachable, not merely unauthenticated: attempt a request to /invocations, /pause, and /abort_requests directly against the vLLM host's port (bypassing the proxy if you can reach it) and confirm the request is refused at the network layer, not just returned a 401 by vLLM itself, since a 401 means the request reached vLLM at all, which the proxy allowlist in Step 1 should have prevented. Confirm a request to a protected /v1 endpoint without a valid key is rejected, and separately confirm a request with a spoofed Host header does not bypass that rejection, directly testing the failure mode behind CVE-2026-48746. Confirm the gRPC port and any PyTorch Distributed or KV-cache-transfer ports are not reachable from outside the isolated cluster network established in Step 6, using a port scan from a host outside that segment. Confirm VLLM_SERVER_DEV_MODE is unset by checking the running container or process environment directly, not just the deployment manifest, since a manifest can be correct while a manually patched running instance drifts from it. Finally, confirm the vLLM version running in production matches a version you have checked against current advisories, not the version that was current when the deployment was first built.

A configuration-only pass, even a thorough one, does not close everything. Known public vulnerabilities against vLLM show up in categories that hardening steps mitigate but do not always fully eliminate on their own.

CVE-2025-62164 is an unsafe deserialization vulnerability that can be abused to cause denial of service and potentially remote code execution in the vLLM server process, affecting deployments that deserialize untrusted or model-provided payloads; this is a code-level fix, not a configuration workaround, so the only real mitigation is running a patched version. CVE-2026-22778 is a remote code execution vulnerability reachable by sending a malicious video link to a vLLM API, combining an information-disclosure flaw in error handling with a heap buffer overflow in a bundled video-decoding dependency, affecting versions 0.8.3 through 0.14.0; a reverse proxy and firewall reduce exposure but do not patch the underlying decoder bug. CVE-2025-48956 allowed denial-of-service attacks via unlimited HTTP header sizes and is fixed in vLLM 0.10.1.1. CVE-2025-66448 is a remote code execution path via an auto_map entry in a model's configuration, affecting all versions before 0.11.1, which is really a specific, dangerous instance of the trust_remote_code and model-provenance risk covered in Step 10, arriving through the model's own config file rather than through a CLI flag.

The pattern across all four: version currency is not optional. A perfectly configured reverse proxy, a correctly scoped API key, and a fully isolated network segment do not protect against a code-level vulnerability in a version you have not upgraded past. Treat vLLM version tracking as an ongoing operational task, not a one-time step in this procedure.

Every control above has a cost, and a team should decide these deliberately rather than discover them after the fact. A reverse proxy with a strict allowlist adds a network hop and a piece of infrastructure to operate and patch in its own right, and an overly narrow allowlist can silently break a legitimate endpoint your application actually needs, which is why Step 1 has to be validated against real traffic, not just a guess at which routes matter. Disabling VLLM_SERVER_DEV_MODE removes a genuinely useful debugging surface for engineers troubleshooting a production issue, which is the correct tradeoff for a production instance but means teams need a separate, explicitly non-production environment where that mode is intentionally left on for diagnosis. Per-tenant cache segmentation (Step 8) and per-tenant network isolation both improve on the security of a shared instance but move a deployment toward the operational and GPU-utilization cost profile of dedicated instances per tenant, which is a real capacity-planning tradeoff, not a free win. Tight resource ceilings on n and media size (Step 7) reduce DoS exposure but can also reject a legitimate high-volume batch workload if the limits are copied from a general guideline instead of sized against your own actual traffic. And avoiding trust_remote_code and pickle-format weights (Step 10) sometimes means you cannot use a specific community model at all until its maintainers or your own team package it in a safer form, which is a real capability tradeoff a team should make with eyes open rather than discover by working around the restriction under deadline pressure.