https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 00:39:19 +0000 https://vulnerability.circl.lu/vuln/brew-aider-cve-2026-84377 <p><strong>Affected:</strong> Homebrew: aider</p> <p>### Impact</p> <p>Any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination they control and cause the proxy to send its own configured provider credentials to that destination. The proxy&#39;s request-body validation was a denylist that did not cover every sensitive parameter and did not inspect parameters nested inside other request fields, so a caller could supply a routing or credential value that the proxy applied without clearing the operator&#39;s stored key. Any authenticated user could therefore exfiltrate the operator&#39;s upstream provider credentials and other configured secrets, and perform Server-Side Request Forgery against internal services reachable from the proxy.</p> <p>### Patches</p> <p>Fixed in 1.96.2, 1.95.1, 1.94.3, 1.93.2, 1.92.2, 1.91.5, 1.90.7, 1.89.7, and 1.88.6.</p> <p>### Workarounds</p> <p>Set `general_settings.allow_client_side_credentials` to `false` so callers cannot override connection parameters, restrict proxy keys to trusted callers, and block the affected parameters (`api_base`, `base_url`, `model_list`, `fallbacks`, provider credential fields) at a reverse proxy or API gateway.</p> <p><strong>Affected:</strong> Homebrew: aider</p> <p>### Impact</p> <p>Any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination they control and cause the proxy to send its own configured provider credentials to that destination. The proxy&#39;s request-body validation was a denylist that did not cover every sensitive parameter and did not inspect parameters nested inside other request fields, so a caller could supply a routing or credential value that the proxy applied without clearing the operator&#39;s stored key. Any authenticated user could therefore exfiltrate the operator&#39;s upstream provider credentials and other configured secrets, and perform Server-Side Request Forgery against internal services reachable from the proxy.</p> <p>### Patches</p> <p>Fixed in 1.96.2, 1.95.1, 1.94.3, 1.93.2, 1.92.2, 1.91.5, 1.90.7, 1.89.7, and 1.88.6.</p> <p>### Workarounds</p> <p>Set `general_settings.allow_client_side_credentials` to `false` so callers cannot override connection parameters, restrict proxy keys to trusted callers, and block the affected parameters (`api_base`, `base_url`, `model_list`, `fallbacks`, provider credential fields) at a reverse proxy or API gateway.</p> https://vulnerability.circl.lu/vuln/brew-aider-cve-2026-84377 https://vulnerability.circl.lu/vuln/cleanstart-2026-xq90781 <p><strong>Affected:</strong> CleanStart: airflow-3</p> <p>CVE-2026-84377 affects multiple packages. LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. See references for individual vulnerability details.</p> <p><strong>Affected:</strong> CleanStart: airflow-3</p> <p>CVE-2026-84377 affects multiple packages. LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. See references for individual vulnerability details.</p> https://vulnerability.circl.lu/vuln/cleanstart-2026-xq90781 https://vulnerability.circl.lu/vuln/fkie_cve-2026-84377 <p>LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to versions 1.88.6 and 1.96.2, any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination the user controls and cause the proxy to send its configured provider credentials to that destination. Request validation in litellm/proxy/auth/auth_utils.py, litellm/proxy/common_request_processing.py, litellm/proxy/health_endpoints/_health_endpoints.py, litellm/proxy/image_endpoints/endpoints.py, and litellm/proxy/litellm_pre_call_utils.py used incomplete checks that did not cover every sensitive parameter or inspect equivalent values across nested request fields, path values, and bracket-notation form data. Routing and credential parameters including api_base, base_url, model_list, fallbacks, and litellm_credential_name could therefore be applied without clearing the operator&#39;s stored key, exposing upstream provider credentials and other configured secrets and permitting server-side requests to internal services reachable by the proxy. This issue is fixed in versions 1.88.6 and 1.96.2.</p> <p>LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to versions 1.88.6 and 1.96.2, any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination the user controls and cause the proxy to send its configured provider credentials to that destination. Request validation in litellm/proxy/auth/auth_utils.py, litellm/proxy/common_request_processing.py, litellm/proxy/health_endpoints/_health_endpoints.py, litellm/proxy/image_endpoints/endpoints.py, and litellm/proxy/litellm_pre_call_utils.py used incomplete checks that did not cover every sensitive parameter or inspect equivalent values across nested request fields, path values, and bracket-notation form data. Routing and credential parameters including api_base, base_url, model_list, fallbacks, and litellm_credential_name could therefore be applied without clearing the operator&#39;s stored key, exposing upstream provider credentials and other configured secrets and permitting server-side requests to internal services reachable by the proxy. This issue is fixed in versions 1.88.6 and 1.96.2.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-84377 https://vulnerability.circl.lu/vuln/ghsa-3cv6-jpf6-8222 <p><strong>Affected:</strong> PyPI: litellm</p> <p>### Impact</p> <p>Any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination they control and cause the proxy to send its own configured provider credentials to that destination. The proxy&#39;s request-body validation was a denylist that did not cover every sensitive parameter and did not inspect parameters nested inside other request fields, so a caller could supply a routing or credential value that the proxy applied without clearing the operator&#39;s stored key. Any authenticated user could therefore exfiltrate the operator&#39;s upstream provider credentials and other configured secrets, and perform Server-Side Request Forgery against internal services reachable from the proxy.</p> <p>### Patches</p> <p>Fixed in 1.96.2, 1.95.1, 1.94.3, 1.93.2, 1.92.2, 1.91.5, 1.90.7, 1.89.7, and 1.88.6.</p> <p>### Workarounds</p> <p>Set `general_settings.allow_client_side_credentials` to `false` so callers cannot override connection parameters, restrict proxy keys to trusted callers, and block the affected parameters (`api_base`, `base_url`, `model_list`, `fallbacks`, provider credential fields) at a reverse proxy or API gateway.</p> <p><strong>Affected:</strong> PyPI: litellm</p> <p>### Impact</p> <p>Any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination they control and cause the proxy to send its own configured provider credentials to that destination. The proxy&#39;s request-body validation was a denylist that did not cover every sensitive parameter and did not inspect parameters nested inside other request fields, so a caller could supply a routing or credential value that the proxy applied without clearing the operator&#39;s stored key. Any authenticated user could therefore exfiltrate the operator&#39;s upstream provider credentials and other configured secrets, and perform Server-Side Request Forgery against internal services reachable from the proxy.</p> <p>### Patches</p> <p>Fixed in 1.96.2, 1.95.1, 1.94.3, 1.93.2, 1.92.2, 1.91.5, 1.90.7, 1.89.7, and 1.88.6.</p> <p>### Workarounds</p> <p>Set `general_settings.allow_client_side_credentials` to `false` so callers cannot override connection parameters, restrict proxy keys to trusted callers, and block the affected parameters (`api_base`, `base_url`, `model_list`, `fallbacks`, provider credential fields) at a reverse proxy or API gateway.</p> https://vulnerability.circl.lu/vuln/ghsa-3cv6-jpf6-8222 https://vulnerability.circl.lu/vuln/opensuse-su-2026:11800-1 <p>python313-litellm-1.101.0-1.1 on GA media</p> <p>python313-litellm-1.101.0-1.1 on GA media</p> https://vulnerability.circl.lu/vuln/opensuse-su-2026:11800-1 https://vulnerability.circl.lu/vuln/pysec-2026-4066 <p><strong>Affected:</strong> PyPI: litellm</p> <p>### Impact</p> <p>Any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination they control and cause the proxy to send its own configured provider credentials to that destination. The proxy&#39;s request-body validation was a denylist that did not cover every sensitive parameter and did not inspect parameters nested inside other request fields, so a caller could supply a routing or credential value that the proxy applied without clearing the operator&#39;s stored key. Any authenticated user could therefore exfiltrate the operator&#39;s upstream provider credentials and other configured secrets, and perform Server-Side Request Forgery against internal services reachable from the proxy.</p> <p>### Patches</p> <p>Fixed in 1.96.2, 1.95.1, 1.94.3, 1.93.2, 1.92.2, 1.91.5, 1.90.7, 1.89.7, and 1.88.6.</p> <p>### Workarounds</p> <p>Set `general_settings.allow_client_side_credentials` to `false` so callers cannot override connection parameters, restrict proxy keys to trusted callers, and block the affected parameters (`api_base`, `base_url`, `model_list`, `fallbacks`, provider credential fields) at a reverse proxy or API gateway.</p> <p><strong>Affected:</strong> PyPI: litellm</p> <p>### Impact</p> <p>Any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination they control and cause the proxy to send its own configured provider credentials to that destination. The proxy&#39;s request-body validation was a denylist that did not cover every sensitive parameter and did not inspect parameters nested inside other request fields, so a caller could supply a routing or credential value that the proxy applied without clearing the operator&#39;s stored key. Any authenticated user could therefore exfiltrate the operator&#39;s upstream provider credentials and other configured secrets, and perform Server-Side Request Forgery against internal services reachable from the proxy.</p> <p>### Patches</p> <p>Fixed in 1.96.2, 1.95.1, 1.94.3, 1.93.2, 1.92.2, 1.91.5, 1.90.7, 1.89.7, and 1.88.6.</p> <p>### Workarounds</p> <p>Set `general_settings.allow_client_side_credentials` to `false` so callers cannot override connection parameters, restrict proxy keys to trusted callers, and block the affected parameters (`api_base`, `base_url`, `model_list`, `fallbacks`, provider credential fields) at a reverse proxy or API gateway.</p> https://vulnerability.circl.lu/vuln/pysec-2026-4066