vLLM
vLLM ProjectAI API6 credentials
Unauthenticated OpenAI-compatible Server
vllm / unauthenticated-openai-server
vLLM serves an OpenAI-compatible HTTP API. Authentication is only enforced when API keys are configured with --api-key or VLLM_API_KEY, so many local or internal deployments expose /v1 endpoints without a credential.
Unauthenticated access
open defaultno authentication required- username
- none
- password
- none
Location
/v1/models, /v1/chat/completions, /v1/completions, /v1/embeddings, /v1/audio/transcriptions, /v1/audio/translations, /health, /metricsvLLM OpenAI-compatible API and health/metrics endpoint contexts
VLLM_API_KEY, VLLM_HOST_IPdocker-compose.yml, compose.yml, values.yaml, deployment.yaml, service.yaml, ingress.yaml, .env, .env.productionContainer and Kubernetes deployment files that may expose an unauthenticated vLLM service
vLLM server logs, access logs, reverse-proxy logs, Kubernetes logs, and gateway traces
Notes
This represents absence of authentication, not a secret value. It is useful for scanners because externally reachable unauthenticated inference APIs can leak data, incur compute cost, or allow model abuse.
vLLM API Key
vllm / api-key
vLLM supports API-key authentication for the OpenAI-compatible server. The CLI --api-key option takes precedence over VLLM_API_KEY, and clients send the configured key as a bearer token in the Authorization header.
Location
AuthorizationBearer token used by OpenAI-compatible vLLM clients
VLLM_API_KEY, OPENAI_API_KEY.env, .env.local, .env.production, docker-compose.yml, compose.yml, values.yaml, deployment.yaml, service.yaml, config.yaml, config.ymlProject-local, container, Kubernetes, and gateway configuration files containing API keys or --api-key arguments
Kubernetes Secrets, Docker secrets, CI/CD variables, cloud secret managers, inference-platform secrets, and password vaults
OpenAI SDK clients, notebooks, agent configs, tests, examples, MCP servers, and committed application code
API debug logs, proxy logs, request traces, notebook output, CI traces, and exception reports
Notes
vLLM API keys are user-chosen opaque values; no stable upstream prefix is documented. Detect them by env/header/CLI context rather than value shape.
Hugging Face Model Access Token
vllm / huggingface-model-token
vLLM commonly downloads models from Hugging Face. Gated or private models require Hugging Face access tokens passed through environment variables, CLI arguments, cache files, or deployment secret stores.
Looks like
examplehf_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXLocation
HF_TOKEN, HUGGING_FACE_HUB_TOKEN~/.cache/huggingface/token, ~/.cache/huggingface/stored_tokens, /root/.cache/huggingface/token, /root/.cache/huggingface/stored_tokens, /home/vllm/.cache/huggingface/token, /home/vllm/.cache/huggingface/stored_tokensLinux Hugging Face token cache files used inside hosts and containers
%USERPROFILE%\\.cache\\huggingface\\token, %USERPROFILE%\\.huggingface\\tokenWindows Hugging Face token cache files used by development hosts
.env, docker-compose.yml, compose.yml, values.yaml, deployment.yaml, config.yaml, config.ymlDeployment configuration that injects Hugging Face tokens for vLLM workers
Kubernetes Secrets, Docker secrets, CI/CD variables, cloud secret managers, model-registry secrets, and password vaults
model-serving scripts, notebooks, CI workflows, examples, and committed deployment code
model download logs, CI traces, container logs, failed authentication messages, and support bundles
Notes
A Hugging Face token can grant access to private or gated model artifacts and may be reused outside vLLM. HUGGINGFACEHUB_API_TOKEN was omitted from the environment location because current official Hugging Face Hub source/docs checked in this session use HF_TOKEN and HUGGING_FACE_HUB_TOKEN for token material.
OpenAI-compatible Client / Gateway Secret
vllm / openai-compatible-client-secret
vLLM deployments frequently sit behind OpenAI-compatible gateways, proxies, service meshes, or multi-tenant routers. These layers may use their own API keys, master keys, proxy authorization tokens, or OAuth bearer tokens before forwarding traffic to vLLM.
Location
Authorization, X-API-Key, Proxy-AuthorizationHeaders commonly used by OpenAI-compatible clients, gateways, and reverse proxies in front of vLLM
/v1/chat/completions, /v1/completions, /v1/embeddings, /v1/modelsOpenAI-compatible endpoint contexts served by vLLM or a gateway
OPENAI_API_KEY, VLLM_API_KEY, LITELLM_MASTER_KEY, WEBUI_SECRET_KEY, OPEN_WEBUI_SECRET_KEY.env, .env.local, docker-compose.yml, compose.yml, values.yaml, litellm.yaml, config.yaml, config.yml, deployment.yaml, ingress.yamlGateway, proxy, OpenAI-compatible client, and Kubernetes/container deployment configuration files
Kubernetes Secrets, Docker secrets, CI/CD variables, cloud secret managers, API gateway secret stores, and password vaults
agent frameworks, notebooks, demos, tests, SDK clients, MCP servers, and committed gateway code
gateway logs, proxy logs, API client traces, notebook output, and CI logs
Notes
This block is product-focused because vLLM's native OpenAI-compatible API is commonly protected by external auth rather than a built-in user database.
TLS Private Key / Certificate Material
vllm / tls-private-key
vLLM's OpenAI-compatible server supports TLS-related server options and is often deployed behind TLS-terminating ingress or reverse proxies. Private keys used for vLLM or its gateway are sensitive.
Looks like
pattern-----BEGIN (?:RSA |EC |)PRIVATE KEY-----Location
tls.key, server.key, privkey.pem, fullchain.pem, cert.pem, /etc/tls/tls.key, /etc/ssl/private/server.keyCommon TLS key/certificate files used by vLLM servers, containers, and reverse proxies Let's Encrypt live certificate directories are deployment-specific and omitted from path to avoid globs.
docker-compose.yml, compose.yml, values.yaml, deployment.yaml, ingress.yaml, nginx.conf, traefik.yml, caddy.json, CaddyfileDeployment and reverse-proxy configuration referencing TLS secrets
Kubernetes TLS Secrets, Docker secrets, cloud certificate stores, cloud secret managers, and password vaults
container images, Helm chart packages, deployment bundles, VM snapshots, and support bundles
TLS startup errors, ingress/controller logs, reverse-proxy logs, and deployment traces
Notes
Certificate public chains are not secrets; private keys and any passphrases protecting them are secrets.
Prompt / Request / Model Artifact Leakage
vllm / prompt-request-and-model-leakage
vLLM request bodies, OpenAI-compatible traces, chat templates, model paths, LoRA/adapters, and downloaded model caches can contain proprietary prompts, copied secrets, private model artifacts, or sensitive tenant data.
Location
/v1/chat/completions, /v1/completions, /v1/embeddings, /metricsEndpoint contexts where prompts, embeddings, and metrics can expose sensitive request or tenant data
VLLM_CONFIG_ROOT, VLLM_USAGE_SOURCE, VLLM_LOGGING_LEVEL, VLLM_HOST_IP, VLLM_DEBUG_LOG_API_SERVER_RESPONSE.env, config.yaml, config.yml, chat_template.jinja, chat_template.jsonProject-local vLLM deployment configuration and chat template files. VLLM_CONFIG_ROOT defaults to ~/.config/vllm, but exact files under that directory are deployment-defined.
~/.cache/huggingface/hub, /root/.cache/huggingface/hub, /home/vllm/.cache/huggingface/hub, /models, /mnt/models, /data/modelsModel cache and mounted model artifact paths used by vLLM deployments
vLLM request logs, gateway logs, OpenAI SDK debug traces, distributed worker logs, Ray logs, Kubernetes logs, and notebook output
model cache archives, LoRA adapter bundles, container images, volume snapshots, notebook exports, and support bundles
Notes
This block is context-dependent: model files are often legitimate artifacts, but scanner hits in request logs, chat templates, model caches, and adapter bundles may expose prompts, tenant data, copied secrets, or proprietary models.
Scope
Authorized use
LOLCreds helps map the credential surface of real products: known defaults, generated values, credential locations, and exposure patterns.