insecure by designRSS
critical

Active Exploitation of LiteLLM Broken Access Control Exposes Secrets and Dashboard Controls

Attackers are actively targeting LiteLLM proxy deployments by leveraging an authorization bypass tracked as CVE-2026-35029. Prior to version 1.83.0, the administrative API failed to enforce sufficient privilege checks on the `/config/update` endpoint, permitting low-privileged, read-only accounts to make arbitrary configuration changes. Telemetry from Zenity Labs revealed approximately 3,900 requests targeting LiteLLM management endpoints across 73 distinct IP addresses between February and June 2026, with nearly 1,000 specifically probing the vulnerable update route. Initial exploitation attempts surfaced on April 7, mere hours after public disclosure. Threat actors leveraged write access to settings such as `UI_LOGO_PATH` to point the dashboard logo to sensitive server paths, including local `.env` files, configuration YAMLs, and `/proc/self/environ`. These local artifacts could then be fetched remotely without authentication via the `/get_image` endpoint. Beyond reading local files, an attacker could abuse LiteLLM's internal parsing of `os.environ/VARIABLE` directives or overwrite dashboard login environment settings directly. Altering these variables allowed adversaries to authenticate as full administrators on the UI. With full administrative access, adversaries could generate fresh API keys, manipulate underlying models, spin up new users, or dump downstream provider credentials and cloud access tokens. Observed malicious activity also included attempts to invoke `/user/new`, brute-force default master keys, delete models, and test unviable JavaScript prototype pollution payloads against the Python codebase. The vulnerability was resolved with the release of LiteLLM version 1.83.0.

Commentary

Centralized AI gateways like LiteLLM have become prime targets because they act as high-value secret aggregators—often holding raw API keys for OpenAI, Anthropic, AWS bedrock, as well as database strings and internal routing logic in a single memory space. This flaw highlights how dangerous broken authorization is when paired with endpoints that can manipulate file pointers or runtime environment variables. Any team deploying self-hosted LiteLLM instances prior to version 1.83.0 must treat read-only tokens as fully compromised if the management plane was network-exposed. Beyond updating to >=1.83.0 immediately, incident responders should audit access logs for anomalous `POST` calls to `/config/update` followed by `GET` requests to `/get_image`. Organizations must rotate all upstream AI provider keys, cloud credentials, and database connection strings stored in the deployment's environment, while locking down management APIs behind internal ingress controllers or zero-trust reverse proxies.

The Quote to Remember

“LiteLLM versions before 1.83.0 did not properly verify whether callers had administrator privileges before allowing changes to high-impact proxy settings.”

“The first probes targeting `/config/update` were detected by researchers on April 7, just one day after the CVE was published.”

← all articles