LiteLLM Security Hardening Guide

When you deploy a self-hosted LLM gateway, it quickly becomes the most sensitive node in your infrastructure. It holds API keys for every model provider your team uses, from OpenAI and Anthropic to local endpoints running on vLLM. However, several out-of-the-box defaults in self-hosted setups can surprise administrators and expose critical attack surfaces.

To help developers and platform engineers secure their deployments, this guide compiles insights directly from LiteLLM's documentation, source code, and recent security advisories. If you are managing multiple enterprise LLM endpoints and need high availability alongside robust security, integrating with a reliable aggregator like n1n.ai can significantly reduce the operational overhead of managing raw provider keys.

Understanding Recent Vulnerabilities

Standard vulnerability scanners rely heavily on CVE identifiers. However, recent security disclosures affecting self-hosted LLM infrastructure demonstrate that relying solely on a CVE database is insufficient.

Two critical issues discovered highlight why proactive hardening is mandatory:

1. GHSA-7hp6-4w63-5g45 (CVSS 9.9): Affecting versions from 1.91.0 up to 1.100.4 (along with specific 1.101, 1.102, and 1.03 releases), this vulnerability allowed any user with the internal_user role to escalate their privileges to proxy admin. The root cause lay in the proxy using a single key for both encrypting stored secrets and minting session tokens, causing an encrypted secret to double as a valid admin token.
2. GHSA-g5ff-637f-6q2m (High Severity): Prior to version 1.95.0, users assigned the read-only internal_user_viewer role could leverage vertex_ai_credentials to read arbitrary local files on the proxy host.

Because these types of architectural flaws often evade standard pip-audit runs early on, manual configuration hardening is non-negotiable.

Step 1: Fixing the Master Key Admin UI Overlap

By default, the LiteLLM admin UI at /ui logs in using UI_USERNAME (which defaults to admin) and UI_PASSWORD. If UI_PASSWORD is left unset, the master key itself is accepted as the password. Anyone who signs in using this fallback mechanism automatically receives full proxy admin privileges. LiteLLM documents this shared cleartext credential as being meant strictly for initial bootstrapping.

To close this security gap, follow this sequence precisely:

1. Log into your UI and create a dedicated proxy_admin user with its own secure, unique password.
2. Verify that you can successfully sign in using this new user account.
3. Update your configuration to disable environment credential logins:

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  disable_env_credential_login: true

Pro Tip: If you skip the user creation step before setting disable_env_credential_login: true, you will permanently lock yourself out of the management UI.

Step 2: Isolating the Salt Key

LiteLLM encrypts provider API keys stored within its internal database, including models added via the UI, credentials, and Model Context Protocol (MCP) server configurations. In the source code, get_salt_key() reads LITELLM_SALT_KEY, but it falls back to the master key if the salt key is absent.

• For New Installations: Generate both environment variables before adding any models to your deployment.
• For Existing Installations Without a Salt Key: Do not introduce one retroactively. Doing so will render all previously stored credentials unreadable because the decryption mechanism will look for a dedicated salt that wasn't used during encryption.

To generate secure production keys, run the following commands on your host:

printf 'LITELLM_MASTER_KEY=sk-%s
LITELLM_SALT_KEY=sk-%s
' "$(openssl rand -hex 32)