Critical LiteLLM Admin API Flaw Lets Attackers Steal Secrets, Target AI Gateway Servers

Key Takeaways

• A critical authorization bypass vulnerability (CVE-2026-35029) in LiteLLM’s Admin API allows low-privilege users to gain full administrative control.
• The flaw impacts LiteLLM versions prior to 1.83.0, enabling attackers to steal sensitive secrets like API keys and cloud credentials, or hijack the administration interface.
• Active exploitation has been observed, with threat actors attempting to read environment files and manipulate configuration settings on exposed AI gateway deployments.
• A patch is available in LiteLLM version 1.83.0 and later, which enforces proper authorization for the affected API endpoint.

Cybersecurity researchers have detected active exploitation attempts targeting a critical authorization bypass vulnerability within LiteLLM AI gateway deployments. This flaw, identified as CVE-2026-35029, permits authenticated users with limited privileges to escalate their access to full administrative control, potentially leading to the theft of sensitive data or complete compromise of the AI gateway.

LiteLLM functions as a crucial intermediary, connecting enterprise applications with various AI model providers. In this role, it often manages and stores highly sensitive information, including provider API keys, database connection details, user data, financial records, and core administrative credentials. The exposure of its control plane, therefore, presents a significant risk, offering attackers a direct path to cloud credentials, AI service keys, or deeper infiltration into connected infrastructure.

The Authorization Bypass Explained

The vulnerability, present in LiteLLM versions preceding 1.83.0, stems from an inadequate authorization check on the /config/update API endpoint. This oversight allows any authenticated account, even one with a restricted role such as proxy_admin_viewer (intended for read-only access), to modify critical configuration settings that should be exclusive to full administrators.

LiteLLM addressed this security lapse in version 1.83.0 by implementing the necessary authorization enforcement, requiring the proxy_admin role for any configuration changes.

Exploitation Techniques and Impact

Attackers have been observed leveraging this flaw to manipulate environment variables and configuration values. One documented method involves altering the UI_LOGO_PATH setting, which specifies the path to the dashboard’s logo file. By substituting the legitimate image path with a sensitive server-side file path, such as /app/.env or /proc/self/environ, an attacker can trick LiteLLM into reading the contents of these files.

The contents of these sensitive files can then be retrieved via the /get_image endpoint, which, in vulnerable deployments, reportedly does not require authentication. This technique can reveal a wealth of secrets, including model-provider API keys, the LiteLLM master key, database URLs, AWS credentials, and tokens for observability platforms.

Beyond data exfiltration, the vulnerability also enables attackers to overwrite environment variables like UI_USERNAME and UI_PASSWORD. This allows them to replace the legitimate dashboard credentials, effectively hijacking the administration interface.

The security implications extend further. Advisories indicate that malicious actors can register harmful pass-through endpoint handlers by modifying configuration. These handlers could redirect to attacker-controlled code or infrastructure, potentially leading to remote code execution or further secret exfiltration.

Observed Attack Activity

Zenity honeypot telemetry recorded approximately 3,900 requests targeting LiteLLM administrative API endpoints between February and June 2026. A significant portion of this activity, around 1,000 requests, specifically targeted the vulnerable /config/update endpoint.

The initial probes aimed at configuration updates began on April 7, just one day after CVE-2026-35029 was publicly disclosed. Subsequently, researchers documented direct file-read payloads attempting to access common secret locations, including /app/.env, /home/litellm/.env, /app/config.yaml, and /app/proxy_server_config.yaml.

Additional malicious activities observed included attempts to guess master keys (e.g., “sk-1234,” “sk-litellm-master-key”), generate new API keys, create administrator accounts, enumerate users and keys, probe SCIM provisioning routes, and delete models. This extensive activity indicates that threat actors are not merely scanning for the vulnerability but are actively attempting to map and gain control over exposed AI gateway environments.

What You Should Do

• Upgrade Immediately: All organizations utilizing LiteLLM must promptly upgrade to version 1.83.0 or later. This version incorporates the essential authorization enforcement for the /config/update endpoint.
• Restrict Network Exposure: Remove LiteLLM control-plane services from public internet exposure. Place the Admin UI and all administrative endpoints behind an authenticated reverse proxy or restrict access to internal networks.
• Strengthen Master Key: Ensure a robust and unique master key is configured for LiteLLM. Avoid using default or documentation-example values.
• Review Logs for Suspicious Activity: Security teams should meticulously review logs for any unusual requests to /config/update, /get_image, /key/generate, /user/new, /model/delete, and /scim/. Specifically, requests that attempt to set UI_LOGO_PATH to local file paths should be treated as high-probability exploitation attempts.
• Rotate All Exposed Secrets: If your organization operated an exposed LiteLLM instance running a version prior to 1.83.0, immediately rotate all potentially compromised secrets. This includes LiteLLM master keys, LLM provider API keys, database passwords, cloud credentials, and third-party monitoring tokens, as these values could have been exposed through configuration manipulation or arbitrary file reads.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.