fix(deps): raise the gitpython floor to 3.1.59 for four new advisories

[mateo-berri]

TLDR

Problem this solves:

• osv-scan went red on every PR at 2026-09-03 11:00Z
• Four new gitpython advisories flag 3.1.58 in uv.lock
• One is Critical (9.3), the other three are High
• All four are fixed in 3.1.59

How it solves it:

• Adds a gitpython>=3.1.59 uv constraint floor, the same shape as the tornado floor in fix(deps): raise the tornado and pypdf floors for six new advisories #39188
• Re-locks so uv.lock resolves gitpython 3.1.61
• Staging has since picked up 3.1.61 on its own through the re-lock in test(harness): add OCR parity with migration strategy runners #38765, with no floor behind it, so what this PR lands now is the floor that keeps a later re-lock from resolving below 3.1.59

User Flow

Before: a contributor sees a red check on their PR that they did not cause and cannot fix from their own diff

1. They open a PR against litellm_internal_staging touching anything at all
2. They watch the checks and see osv-scan red, reporting Total 1 package affected by 4 known vulnerabilities (1 Critical, 3 High, 0 Medium, 0 Low, 0 Unknown)
3. They open the run log and the table names gitpython 3.1.58 with fixed version 3.1.59, sourced from uv.lock, a file their PR never touched: https://osv.dev/PYSEC-2026-3785 (CVSS 7.8), https://osv.dev/PYSEC-2026-3786 (9.3), https://osv.dev/PYSEC-2026-3787 (8.7) and https://osv.dev/PYSEC-2026-3788 (7.1)
4. Nothing in their diff can clear it, so they either wait or learn to ignore the check
5. An operator running a vulnerability scanner against their litellm environment gets the same four findings

After: the same check comes back green, so a red there again means something the PR actually introduced

1. They open a PR against litellm_internal_staging touching anything at all
2. They watch the checks and see osv-scan green, reporting No issues found
3. They open the run log and there is no gitpython row in it
4. Nothing about their diff is in question, so the next red check they see is one they caused
5. The operator's scanner sees gitpython 3.1.61, which none of the four advisories cover

Relevant issues

Linear ticket

Resolves LIT-6840

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests (n/a: dependency floor bump, verified by the osv-scan CI check and the local scan below)
• The handful of test files covering my change pass locally, e.g. uv run pytest tests/test_litellm/<your_test_file>.py -v. Leave the suites (make test-unit-*, make test-unit) to CI: it finishes in ~15 minutes where a laptop takes an hour or more
• My PR passes all required CI/CD checks (e.g., lint, schema.d.ts sync check, etc.)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

gitpython is not a direct dependency: it reaches the lock only through mlflow-skinny, under the optional mlflow extra, so the floor goes in [tool.uv] constraint-dependencies the same way tornado's did in #39188. uv lock --upgrade-package gitpython then moves gitpython alone, and the whole lock diff is that package's three lines, the new constraints entry, and the relative exclude-newer stamp. The package count stays at 453 on both sides. Nothing in the repo imports git, and the extras the Docker images build install no gitpython at all (uv sync --frozen over that extra set resolves without it, while --extra mlflow resolves gitpython==3.1.61), so the change is confined to the lockfile and to anyone installing the optional mlflow extra from it.

Both local legs run the scanner the workflow pins (osv-scanner v2.3.8, sha256 verified against the release's osv-scanner_SHA256SUMS) with the repo's osv-scanner.toml, the same command .github/workflows/osv-scan.yml runs:

osv-scanner scan source --config osv-scanner.toml -L uv.lock -L ui/litellm-dashboard/package-lock.json

Before (658f506)

1. The osv-scan check on an unrelated PR at that base fails with the four findings (run):

Total 1 package affected by 4 known vulnerabilities (1 Critical, 3 High, 0 Medium, 0 Low, 0 Unknown) from 1 ecosystem.
4 vulnerabilities can be fixed.

+---------------------------------+------+-----------+-----------+---------+---------------+---------+
| OSV URL                         | CVSS | ECOSYSTEM | PACKAGE   | VERSION | FIXED VERSION | SOURCE  |
+---------------------------------+------+-----------+-----------+---------+---------------+---------+
| https://osv.dev/PYSEC-2026-3785 | 7.8  | PyPI      | gitpython | 3.1.58  | 3.1.59        | uv.lock |
| https://osv.dev/PYSEC-2026-3786 | 9.3  | PyPI      | gitpython | 3.1.58  | 3.1.59        | uv.lock |
| https://osv.dev/PYSEC-2026-3787 | 8.7  | PyPI      | gitpython | 3.1.58  | 3.1.59        | uv.lock |
| https://osv.dev/PYSEC-2026-3788 | 7.1  | PyPI      | gitpython | 3.1.58  | 3.1.59        | uv.lock |
+---------------------------------+------+-----------+-----------+---------+---------------+---------+

2. The same scan run locally over that commit's lockfiles exits 1 with the identical table

After (d0935f6)

1. uv lock --upgrade-package gitpython with the raised floor:

Resolved 453 packages in 974ms
Updated gitpython v3.1.58 -> v3.1.61

2. The same scan exits 0:

Scanned uv.lock file and found 453 packages
Scanned ui/litellm-dashboard/package-lock.json file and found 879 packages
GHSA-w8v5-vhqr-4h9v and 2 aliases have been filtered out because: diskcache has no fixed release published; remove this entry once one exists
GHSA-h7x2-h6g9-p789 and 1 alias have been filtered out because: mlflow has no fixed release published; remove this entry once one exists
Filtered 3 vulnerabilities from output

No issues found

3. This PR's own osv-scan check passes at this commit (run)

After (104ad1c, staging merged in to clear the uv.lock conflict)

1. uv lock --check at the merged tip:

Resolved 455 packages in 53ms

2. The resolved package set is identical to current staging (gitpython 3.1.61 on both sides), so the merge changes nothing at runtime and the PR's net diff stays the one constraint line:

$ python3 - <<'PY'
import re,subprocess
def pairs(ref):
    txt=subprocess.run(['git','show',f'{ref}:uv.lock'],capture_output=True,text=True).stdout
    return set(re.findall(r'\[\[package\]\]\nname = "([^"]+)"\nversion = "([^"]+)"',txt))
a=pairs('origin/litellm_internal_staging'); b=pairs('HEAD')
print('staging-only:',sorted(a-b)); print('head-only:',sorted(b-a)); print('total head packages:',len(b))
PY
staging-only: []
head-only: []
total head packages: 455

3. This PR's own osv-scan check passes at this commit (run)

4. Re-checked on 2026-09-04 with a local three-way merge of this tip into staging at b3c867c (which has moved uv.lock again since, for the uvloop bump): uv lock --check resolves 455 packages, the package set is identical to staging's, and the same osv-scanner v2.3.8 scan of the merged lockfiles ends in No issues found

5. The floor is what this PR still lands, so here it is biting. Staging at b3c867c has no floor and lets a re-lock walk gitpython back to the vulnerable version:

$ uv lock --dry-run -P 'gitpython==3.1.58'
Resolved 455 packages in 211ms
Update gitpython v3.1.61 -> v3.1.58

The same command at this tip refuses with exit 1. The >=3.1.59 uv attributes to mlflow-skinny is the workspace constraint applied on that edge; mlflow-skinny 3.15.0's own metadata on PyPI is gitpython<4,>=3.1.9:

$ uv lock --dry-run -P 'gitpython==3.1.58'
  × No solution found when resolving dependencies for split (markers:
  │ python_full_version == '3.14.*'):
  ╰─▶ Because mlflow-skinny>=3.11.1 depends on gitpython>=3.1.59 and
      gitpython==3.1.58, we can conclude that mlflow-skinny>=3.11.1 cannot be
      used. (1)

After (b5e5212, staging merged in again after the MongoDB Atlas vector store PR re-locked uv.lock)

1. uv lock --check at the merged tip:

Resolved 456 packages in 4ms

2. The uv.lock diff against the merge target (staging at e733ca1) is the relative stamp plus the manifest constraint line, so the resolved set is identical to staging's, 456 packages on both sides:

$ git diff origin/litellm_internal_staging -- uv.lock | grep -E '^[-+]' | grep -vE '^(\+\+\+|---)'
-exclude-newer = "2026-09-01T21:00:02.682921Z"
+exclude-newer = "2026-09-02T01:24:49.423924Z"
+    { name = "gitpython", specifier = ">=3.1.59" },

3. The same osv-scanner v2.3.8 scan of the merged lockfiles:

$ osv-scanner scan source --config osv-scanner.toml -L uv.lock -L ui/litellm-dashboard/package-lock.json
Filtered 3 vulnerabilities from output

No issues found

4. This PR's own osv-scan check passes at this commit (run)

5. The floor-bite dry-run from the previous section holds here: uv lock --dry-run -P 'gitpython==3.1.58' refuses with exit 1 and the same mlflow-skinny conflict

6. /live-pr-risk carries over from 104ad1c: this commit only merges staging and moves the lock stamp, and with the resolved set identical to staging's it cannot change runtime behavior

7. All 33 required checks pass on the merge of this tip onto staging df3b8a6 (run 33941905182), which carries the two staging fixes (fix(proxy): strip every TypedDict qualifier before numeric form-field detection #39780, fix(datadog_llm_obs): keep guardrail_cost_by_unit on redacted spans #39848) behind the earlier proxy-infra and integrations reds; the 01:31Z and 03:07Z runs had both checked out the same stale Merge b5e5212f3b into e2741b5643 commit, so a close and reopen at 03:27Z was needed to test the current base

After (ee1bca4, staging merged in a third time after the enterprise and proxy-extras version bump re-locked uv.lock)

1. uv lock --check at the merged tip:

Resolved 456 packages in 7ms

2. The uv.lock diff against the merge target (staging at bf51dea) is the relative stamp plus the manifest constraint line, so the resolved set is identical to staging's, 456 packages on both sides:

$ git diff origin/litellm_internal_staging -- uv.lock | grep -E '^[-+]' | grep -vE '^(\+\+\+|---)'
-exclude-newer = "2026-09-02T16:58:34.594994Z"
+exclude-newer = "2026-09-02T22:30:10.532114Z"
+    { name = "gitpython", specifier = ">=3.1.59" },

3. The same osv-scanner v2.3.8 scan of the merged lockfiles:

$ osv-scanner scan source --config osv-scanner.toml -L uv.lock -L ui/litellm-dashboard/package-lock.json
Scanned /Users/mateo/Development/litellm-worktrees/lit6840/ui/litellm-dashboard/package-lock.json file and found 879 packages
Filtered 3 vulnerabilities from output

No issues found

4. This PR's own osv-scan check passes at this commit (run)

5. The floor-bite dry-run holds here too, exit 1 with the same mlflow-skinny conflict:

$ uv lock --dry-run -P 'gitpython==3.1.58'
  × No solution found when resolving dependencies for split (markers:
  ╰─▶ Because mlflow-skinny>=3.11.1 depends on gitpython>=3.1.59 and
      gitpython==3.1.58, we can conclude that mlflow-skinny>=3.11.1 cannot be
      used.

6. /live-pr-risk carries over from 104ad1c: this commit only merges staging and moves the lock stamp, and with the resolved set identical to staging's it cannot change runtime behavior

Type

🐛 Bug Fix

Caveats (if any)

Low

• The lock resolves 3.1.61, not 3.1.59, because uv takes the newest release inside the lockfile's 3-day exclude-newer window. 3.1.60 and 3.1.61 are upstream's fixes for regressions 3.1.59 shipped (git config escape semantics, repository discovery precedence), so pinning the floor exactly would be the worse of the two
• Against the current merge base the lock diff is the relative exclude-newer stamp moving from 2026-09-02T16:58:34Z to 2026-09-02T22:30:10Z plus the manifest constraint line: 456 packages on both sides and no resolved version changes, since staging already carries gitpython 3.1.61. The stamp comes from exclude-newer-span = "P3D"; pinning it back with --exclude-newer on the command line drops the span entry from the lock and fails uv lock --check, so it moves with every re-lock
• [tool.uv] constraint-dependencies is workspace-local, so the published litellm metadata is unchanged and pip install litellm[mlflow] still resolves gitpython through mlflow-skinny's own gitpython<4,>=3.1.9 (3.1.61 today). Binding that too would mean adding a direct dependency on a package litellm never imports
• Low: the non-required CircleCI job proxy_store_model_in_db_tests is red at this tip on tests/store_model_in_db_tests/test_openai_error_handling.py::test_chat_completion_bad_model_with_spend_logs (assert '' == 'non-existent-model'). It is red on 10 of the 15 run-ci PRs updated today and has its own fix in test(store_model_in_db): assert the 400 contract in the unknown-model spend log test #39842, so it is unrelated to the dependency bump
• Five non-required checks are red at ee1bca4 for reasons that reproduce on staging's own bf51dea, whose litellm/, tests/, and enterprise/ trees are byte-identical to this branch's: misc / Run tests fails test_star_import_exports_public_api on every Python version there too, and the CircleCI jobs batches_testing, auth_ui_unit_tests, litellm_utils_testing, and google_generate_content_endpoint_testing fail the same tests as staging's scheduled pipeline 89211. The circular imports and that test both arrive with staging commit c091dd4 (perf: lazy-load SDK symbols so import litellm stays under 60 MB RSS #39121); a live import probe at its parent 17e1312 passes and at c091dd4 fails. The fix belongs on staging, not in a dependency floor bump: LIT-7083 tracks it and test(lazy_imports): check star-import exports against globals(), not dir() #39958 covers the star-import test

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

---

Note

Low Risk
Lockfile and uv workspace constraints only; no application code changes, and gitpython is optional via the mlflow extra.

Overview
Adds a gitpython>=3.1.59 entry to [tool.uv] constraint-dependencies (same pattern as the existing tornado floor) and records that constraint in uv.lock, so future resolves cannot pull gitpython 3.1.58, which osv-scan flags for four advisories (one Critical).

gitpython is only pulled in transitively when installing the optional mlflow extra; default/proxy installs are unchanged. Against current staging the resolved set already uses 3.1.61—this PR mainly enforces the minimum version on re-lock, not a broad runtime behavior change.

^{Reviewed by Cursor Bugbot for commit ee1bca4. Bugbot is set up for automated code reviews on this repo. Configure here.}

• 104ad1c passes /live-pr-risk: no code symbol changes; the only runtime dependent is gitpython via mlflow-skinny under the optional mlflow extra, and the resolved set is identical to staging

[greptile-apps]

Greptile Summary

Raises the workspace GitPython dependency floor and synchronizes the lockfile manifest so future resolutions retain the security-hardened minimum version.

• Adds gitpython>=3.1.59 to the uv workspace constraints.
• Updates the corresponding uv.lock manifest constraint.
• Refreshes lockfile resolution metadata without changing the resolved package set.

Confidence Score: 5/5

The PR appears safe to merge because the dependency floor and lockfile manifest are consistent and no actionable regressions remain.

The current PR diff is limited to a compatible minimum dependency constraint and synchronized lock metadata; no resolved package changes, rule violations, or new correctness issues were identified.

Important Files Changed

Filename	Overview
pyproject.toml	Adds a valid workspace-level minimum GitPython constraint alongside existing dependency floors.
uv.lock	Mirrors the new constraint and refreshes the relative resolution timestamp without changing package versions.

_{Reviews (6): Last reviewed commit: "Merge remote-tracking branch 'origin/lit..." | Re-trigger Greptile}

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_bump_gitpython_3159 (ee1bca4) with litellm_internal_staging (bf51dea)}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[mateo-berri]

bugbot run

[cursor]

Stale Bugbot comment from a previous run.

[mateo-berri]

@greptileai

[mateo-berri]

bugbot run

[cursor]

Stale Bugbot comment from a previous run.

[mateo-berri]

@greptileai

[mateo-berri]

bugbot run

[cursor]

Stale Bugbot comment from a previous run.

[mateo-berri]

@greptileai

[mateo-berri]

bugbot run

[github-actions]

LiteLLM Rust workflow

Workflow completed successfully for ee1bca43291bdeb92b37c748282d52364ecc7dea

View workflow run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit ee1bca4. Configure here.}