Self-hosted model servers make it easier to keep prompts inside an organization's network and to control model deployment. vLLM's OpenAI-compatible server is one common choice. Its API key option is useful, but the vendor's own security documentation makes an important qualification: the key authenticates requests under specific path prefixes, not every endpoint the server exposes. Network and reverse-proxy policy still matter.
At about 23:48 UTC on 29 October 2026, count-only ZoomEye SDK queries with sub_type=all and page size 1 returned 383 matches for app="vLLM" and 121 for title="vLLM". The app query is the primary observation, but the product name can appear in banners and page content in different ways. These are not counts of unauthenticated model servers or confirmed vulnerable versions.
Read the endpoint map
Deploy the server behind a reverse proxy that knows which routes are intended for clients. Require authentication at the proxy for the public API path, and keep administrative, rendering, metrics, or health routes on a private listener where possible. The API key setting is a useful control, but it should not be the only reason an environment is considered authenticated.
The current vLLM security documentation says the --api-key option authenticates endpoints under the /v1, /v2, /inference, and /cohere prefixes. Other routes may have different behavior. Read the documentation for the exact deployed version and enumerate the routes in a test environment. Do not infer a security property from the fact that the chat completion call returned 401.
Constrain cross-origin access
The project has published an advisory about permissive default CORS origins for the HTTP server. CORS is a browser policy and does not replace authentication, but a permissive origin list can increase the chance that a browser-based integration sends credentials or requests in an unintended context. Configure an explicit origin allow list for the client applications you control, and test preflight and failure behavior.
Network egress from the model server should be restricted to the model files, package mirrors, and observability endpoints it actually needs. A model server that accepts a remote URL or plugin path can turn a request into a fetch or execution primitive if the feature is exposed to untrusted users. Disable unnecessary endpoints and keep model files on an approved storage path.
Inventory the serving layer
For each vLLM instance, record the model name and hash, server version, GPU host, API route, authentication policy, request limits, and allowed origins. Determine whether the endpoint is exposed to the internet, a shared corporate network, or only an application subnet. Compare that intended exposure with public fingerprint data from ZoomEye and with cloud load-balancer configuration.
A matching fingerprint may be a legitimate public demo, a managed service, or an internal service visible through a misconfigured route. Verify ownership before performing any authenticated test. Do not send prompts containing secrets or attempt to extract model data from a system you do not own.
Test the negative paths
Use a controlled deployment and verify that an unauthenticated request to each known client endpoint is rejected. Request a resource outside the allowed path. Send an unapproved origin header and check whether the response policy matches the design. Apply a request-size and concurrency limit, then confirm that an oversized request fails without consuming unbounded memory.
Inspect logs for the model identifier, route, response code, request duration, and caller identity where the gateway supplies one. Do not log full prompts by default. Prompt data can contain customer information and credentials, and a model server's diagnostic value does not justify storing it indefinitely.
The key option is a helpful baseline. The complete boundary includes the route map, reverse proxy, origin policy, model file integrity, network egress, and resource limits. A team should be able to explain each of those before it treats a vLLM endpoint as production-ready.
References
[1] vLLM security documentation