build(deps): bump soupsieve from 2.8.4 to 2.9.2

[dependabot]

TLDR

Problem this solves:

• osv-scan fails on every PR into main: uv.lock pins soupsieve 2.8.4
• GHSA-gjv8-xp57-g29c and GHSA-j934-xhv5-fg8f (ReDoS), fixed in soupsieve 2.9.0
• Dependabot's own commit rewrote 388 unrelated lock lines in a newer uv format

How it solves it:

• Relock soupsieve to 2.9.2 with the repo's pinned uv 0.10.9, 10 lock lines
• Raise the [tool.uv] CVE floor to soupsieve>=2.9 so no relock returns to 2.8.4
• Keep Dependabot's PR as the vehicle so its security alert closes on merge

User Flow

Before: a contributor opens any PR into main and osv-scan turns red for a dependency they never touched

1. They push a branch and open a PR against main from main...their-branch
2. On https://github.com/BerriAI/litellm/pull/NNNNN/checks the osv-scan check fails within two minutes: "Total 1 package affected by 2 known vulnerabilities", soupsieve 2.8.4 in uv.lock, fixed version 2.9.0
3. Their diff never touched uv.lock, so they explain the red check to reviewers, and every other open PR into main shows the same failure

After: the same PR gets a green osv-scan

1. They push a branch and open a PR against main from main...their-branch
2. On https://github.com/BerriAI/litellm/pull/NNNNN/checks the osv-scan check passes with "No issues found"
3. Reviewers see only checks that reflect the PR's own change

Relevant issues

Affected release

Linear ticket

Pre-Submission checklist

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

• I have added meaningful tests (not applicable: a dependency relock with no code change, osv-scan at the tip is the check)
• 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 (not applicable: no test file covers a lock bump, the import smoke below runs the only in-repo consumer against the new version)
• 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) (5/5 at 66cdc8e)

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

Shared setup: osv-scanner v2.3.8, the version .github/workflows/osv-scan.yml pins, checksum-verified against its SHA256SUMS, run from the repo root with CI's exact command

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

Before (bc9f4fe)

osv-scanner on uv.lock, same command as CI

1. git checkout bc9f4fec5b, then the command above
2. Output ends with the two soupsieve rows and exit code 1:

Scanned ./uv.lock file and found 458 packages
Total 1 package affected by 2 known vulnerabilities (0 Critical, 0 High, 2 Medium, 0 Low, 0 Unknown) from 1 ecosystem.
2 vulnerabilities can be fixed.
| https://osv.dev/GHSA-gjv8-xp57-g29c | 5.3  | PyPI      | soupsieve | 2.8.4   | 2.9.0         | uv.lock |
| https://osv.dev/GHSA-j934-xhv5-fg8f | 5.3  | PyPI      | soupsieve | 2.8.4   | 2.9.0         | uv.lock |
exit=1

osv-scan check on a PR into main

1. Open https://github.com/BerriAI/litellm/actions/runs/35280567843/job/105401259023, the osv-scan job of PR fix(license): let a wildcard allowed_features license grant the auto_router feature #41684 at c2fbb11, whose uv.lock is main's
2. The job log ends with the same two GHSA rows and ##[error]Process completed with exit code 1., and the check is red on the PR

soupsieve through beautifulsoup4, the only in-repo consumer

1. uv sync --frozen --group ci --inexact, then uv run --frozen --no-sync python -c 'import soupsieve, bs4; print("soupsieve", soupsieve.__version__, "bs4", bs4.__version__); print(bs4.BeautifulSoup("<ul><li class=a>one</li><li>two</li></ul>", "html.parser").select_one("li.a").text)'
2. Prints soupsieve 2.8.4 bs4 4.14.3 and one

After (66cdc8e)

osv-scanner on uv.lock, same command as CI

1. git checkout 66cdc8e4d0, then the command above
2. Output ends clean with exit code 0 (the 4 filtered entries are the diskcache and mlflow advisories osv-scanner.toml already ignores on main, unchanged here):

Scanned ./uv.lock file and found 458 packages
Filtered 4 vulnerabilities from output
No issues found
exit=0

osv-scan check on a PR into main

1. Open https://github.com/BerriAI/litellm/actions/runs/35288989390/job/105427506138, this PR's osv-scan job at 66cdc8e
2. The job log ends with Scanned .../uv.lock file and found 458 packages, Filtered 4 vulnerabilities from output, No issues found, and the check is green on the PR

soupsieve through beautifulsoup4, the only in-repo consumer

1. Same two commands as Before
2. Prints soupsieve 2.9.2 bs4 4.14.3 and one

Type

🚄 Infrastructure

Caveats (if any)

Low

• The CVE floor moved to soupsieve>=2.9 in [tool.uv] constraint-dependencies, the same way the 2.8.4 floor was added
  • The lock-only alternative was rejected because a later uv lock could resolve back below the fixed version
• exclude-newer in uv.lock moved from 2026-09-14T20:32Z to 2026-09-14T23:48Z: uv 0.10.9 refreshes its rolling window on every relock, and no other package moved
• Dependabot's first commit was rewritten into main's lock format: the repo's pinned uv (>=0.10.9) flips those 388 lines back on the next relock, so they never land
• soupsieve is a transitive dependency of beautifulsoup4 in the ci group only, the proxy runtime never imports it, so no user-facing behavior changes
• Other open PRs that relocked soupsieve in their own uv.lock will conflict on it after this lands and need a merge of main
• Dependabot stops rebasing this PR now that it carries a human commit, so it lands through the normal review path

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 (not applicable: no test code in this PR)

---

Note

Low Risk
Lockfile and uv constraint bump only; no runtime or auth code changes, and soupsieve is used only transitively in CI test dependencies.

Overview
Fixes osv-scan failures on every PR into main by resolving two medium ReDoS advisories (GHSA-gjv8-xp57-g29c, GHSA-j934-xhv5-fg8f) that affect soupsieve 2.8.4 and are patched in 2.9.0+.

The lockfile pins soupsieve 2.9.2 (was 2.8.4), and [tool.uv] constraint-dependencies raises the floor from soupsieve>=2.8.4 to soupsieve>=2.9 so future uv lock runs cannot drift back below the fixed version. The exclude-newer timestamp in uv.lock shifts slightly as part of the same relock; no other packages change.

soupsieve remains a transitive dependency of beautifulsoup4 in the ci dependency group only—not the proxy runtime—so this is a supply-chain / CI hygiene change with no application code edits.

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

• 66cdc8e passes /live-pr-risk

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ mateo-berri
❌ dependabot[bot]
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[codspeed]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing dependabot/uv/soupsieve-2.9 (66cdc8e) with main (deb9d8a)}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[mateo-berri]

@greptileai

[greptile-apps]

Confidence Score: 5/5

The dependency-only change appears safe to merge, with compatible constraints and internally consistent lock metadata.

Summary

This PR updates the locked soupsieve dependency and raises its resolution floor as dependency security hardening.

• Resolves soupsieve to 2.9.2 with updated artifact hashes.
• Keeps the pyproject.toml and uv.lock constraints synchronized at >=2.9.
• Refreshes the lockfile’s rolling exclude-newer timestamp without moving other packages.

_{Reviews (1) · Last reviewed commit: "build(deps): relock soupsieve to 2.9.2 w..."}

[mateo-berri]

bugbot 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 66cdc8e. Configure here.}

[mateo-berri]

Closing as superseded: #41703 landed the same soupsieve 2.9.2 bump on main first, so this PR now conflicts on uv.lock

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.