chore: sync LiteLLM fork to upstream main 1.82.6

[nieta-zjj]

Summary

• fast-forward the fork branch to upstream main
• bring the fork in sync with LiteLLM 1.82.6 and the upstream responses/reasoning fixes landed before and around 2026-03-22

Verification

• upstream divergence check: git rev-list --left-right --count HEAD...upstream/main -> 0 0

In general, the problem is fixed by explicitly declaring a permissions block either at the top level of the workflow (applying to all jobs) or per job, and granting only the minimal required scopes. This workflow only needs to read from and write to repository contents to create and push new branches, so contents: write is sufficient. No other scopes (like issues, pull-requests, or packages) are required.

The best fix with no behavior change is to add a workflow-level permissions block just under the name: line. This will apply to both create-staging-branch and create-internal-dev-branch without repeating configuration, and will keep the ability to push branches (which requires contents: write). Concretely, in .github/workflows/create_daily_staging_branch.yml, after line 1 (name: Create Daily Staging Branch), insert:

permissions:
  contents: write

No additional imports or methods are needed, as this is purely a YAML configuration change for GitHub Actions.

To fix this, explicitly declare minimal GITHUB_TOKEN permissions in the workflow. Since the job only needs to read repository contents (for actions/checkout) and does not push code, manage releases, or modify issues/PRs, we can safely set contents: read. This should be done at the workflow (root) level so it applies to all jobs unless overridden.

Concretely, in .github/workflows/test-proxy-e2e-azure-batches.yml, add a top-level permissions: block after the on: section and before concurrency: (or before jobs:). The block should specify contents: read, which corresponds to GitHub’s suggested minimal starting point and is sufficient for actions/checkout@v4. No other steps in the shown snippet require additional scopes, so we avoid granting unnecessary write permissions. No code logic or job behavior changes; we only constrain the ambient token.

To fix this, we should ensure that only safe, same-origin paths are used for client-side redirects and that the redirect is performed via a trusted base URL rather than the raw user-controlled value.

General approach:

• Treat values derived from window.location.search as untrusted.
• Before redirecting, parse returnUrl and enforce:
  • Protocol is http: or https: (and ideally matches current).
  • Origin matches window.location.origin.
  • Or, more simply, only allow path-relative URLs (starting with /) and never absolute external URLs.
• Combine the validated path with the current origin when calling window.location.replace.

Concrete change in this code:

• In ui/litellm-dashboard/src/app/page.tsx, right before using window.location.replace(returnUrl), derive a safe redirect URL:
  • If returnUrl starts with /, keep it (path-only redirect).
  • Else, try to new URL(returnUrl, window.location.origin) and enforce url.origin === window.location.origin; if not, skip redirect.
• Call window.location.replace(safeUrl) instead of the raw returnUrl.

This change is local to the useEffect that performs the post-authentication redirect (lines 265–289) and does not require new imports or changes elsewhere. It preserves intended functionality (redirecting back within the same app) while blocking open redirects / potential client-side XSS via hostile URLs.

---

General fix: Ensure that any client-side redirect constructed from user-influenced data is constrained to safe destinations (typically same-origin, relative paths) or is chosen from a server-/code-defined allowlist. Never pass a raw query parameter or cookie value directly to window.location or window.location.replace without enforcing such constraints.

Best fix here without changing behavior: Keep using consumeReturnUrl() but, right before redirecting, normalize the URL into a safe, same-origin path. If returnUrl is absolute and same-origin, we can safely use its path/search/hash. If it is relative, we can construct a URL with window.location.origin as the base and again only use the path/search/hash. If the URL is invalid or cross-origin, we simply do not redirect. This both hardens the redirect and satisfies CodeQL by ensuring that the tainted string is not directly used as the redirect target.

Concretely in ui/litellm-dashboard/src/app/page.tsx:

• In the useEffect that currently does:

  const returnUrl = consumeReturnUrl();
  ...
  if (normalizedReturnUrl !== normalizedCurrentUrl) {
    window.location.replace(returnUrl);
  }

  change it to:

  1. Parse returnUrl using the URL constructor with window.location.origin as a base (to handle relative URLs).
  2. Check that url.origin === window.location.origin. If not, skip redirect.
  3. Build a safe redirect target from url.pathname + url.search + url.hash.
  4. Optionally compare normalized versions using this safe target instead of the raw returnUrl.
  5. Call window.location.replace(safeTarget).

No new methods or imports are required; we use the standard URL API and existing normalizeUrlForCompare. All changes stay within the shown useEffect in page.tsx. We do not need to modify returnUrlUtils.ts for this fix.

---