LiteLLM 1.98

Last reviewed Oct 28, 2026

Export as PDF

Prompt Details

Prompt Composition

2prompts
  1. Python 3155 lines · 3.8K tokens
  2. LiteLLM 1.9875 lines · 3.5K tokens
Total230 lines · 7.3K tokens

CWE Coverage

  • 20
  • 23
  • 36
  • 59
  • 78
  • 89
  • 95
  • 117
  • 208
  • 209
  • 214
  • 250
  • 287
  • 295
  • 306
  • 319
  • 328
  • 338
  • 347
  • 367
  • 379
  • 409
  • 416
  • 426
  • 427
  • 470
  • 494
  • 502
  • 522
  • 524
  • 532
  • 611
  • 636
  • 639
  • 674
  • 732
  • 770
  • 772
  • 776
  • 807
  • 829
  • 862
  • 863
  • 916
  • 918
  • 942
  • 1104
  • 1250
  • 1333
  • 1395
  • 1426
  • 1427

Prompt Preview

Apply the Python 3 prompt first. These rules cover LiteLLM 1.98.0 SDK and proxy use on Python 3.10–3.14. Configure SDK applications explicitly; calling completion(), acompletion(), or Router directly does not inherit a separately deployed proxy's authentication, budgets, or guardrails.

Release and credential lifecycle

  • On LiteLLM 1.98.0, which predates the 1.100.4 fix for GHSA-7hp6-4w63-5g45, set EXPERIMENTAL_UI_LOGIN=false explicitly on every proxy replica as containment for the affected login path. Leaving it unset does not disable that path. This also disables CLI SSO and gateway logins; restrict internal_user keys and operator routes while moving to a supported line.
  • Pin the SDK, proxy image, and optional proxy dependencies to a reviewed compatible build. Verify the release's Docker signature with the independently pinned official signing key and deploy an immutable image digest; floating tags can change the running security behavior.
  • Check the current stable release and official advisories before deploying 1.98.0; an existing release tag is not a promise of continued security maintenance for that line.
  • Set a strong LITELLM_MASTER_KEY through protected runtime configuration before accepting traffic. Reserve this proxy-administrator credential for administration and issue separate virtual keys to applications.
  • Set and securely back up LITELLM_SALT_KEY before storing provider credentials in the database. Keep it consistent across replicas and restores; changing it without migrating encrypted records makes existing credentials unreadable.