fix(deps): bump cryptography to 49.0.0 to clear osv-flagged CVEs

[davesheffer]

TLDR

Problem this solves:

• osv-scan fails on every branch since 2026-08-03
• Three cryptography CVEs flagged in uv.lock (two High, one Medium)

How it solves it:

• Bumps cryptography 48.0.1 to 49.0.0, clearing the two CVEs fixed there
• Time-boxed scanner ignore for the third; its fix (50.0.0) is blocked by mlflow's <50 cap

Relevant issues

Linear ticket

Pre-Submission checklist

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

• I have added meaningful tests (none added; this is a dependency bump, and the existing 148 crypto-path tests are the regression net)
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• 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

GHSA-g6cj-pr64-35w5 was published on 2026-08-03, which is why osv-scan went red on every branch at once; see for example this run on an unrelated PR. Reproduced locally with the exact scanner CI pins (osv-scanner v2.3.8, sha256-verified against the release's osv-scanner_SHA256SUMS)

Before, at 956d517:

$ osv-scanner scan source --config osv-scanner.toml -L uv.lock -L ui/litellm-dashboard/package-lock.json
Total 1 package affected by 3 known vulnerabilities (0 Critical, 2 High, 1 Medium, 0 Low, 0 Unknown) from 1 ecosystem.

+-------------------------------------+------+-----------+--------------+---------+---------------+---------+
| OSV URL                             | CVSS | ECOSYSTEM | PACKAGE      | VERSION | FIXED VERSION | SOURCE  |
+-------------------------------------+------+-----------+--------------+---------+---------------+---------+
| https://osv.dev/GHSA-g6cj-pr64-35w5 | 8.2  | PyPI      | cryptography | 48.0.1  | 50.0.0        | uv.lock |
| https://osv.dev/GHSA-jwv3-5hgf-82ww | 8.7  | PyPI      | cryptography | 48.0.1  | 49.0.0        | uv.lock |
| https://osv.dev/GHSA-m2h6-j472-rp4c | 6.9  | PyPI      | cryptography | 48.0.1  | 49.0.0        | uv.lock |
+-------------------------------------+------+-----------+--------------+---------+---------------+---------+

After, at a05f510:

$ osv-scanner scan source --config osv-scanner.toml -L uv.lock -L ui/litellm-dashboard/package-lock.json
GHSA-g6cj-pr64-35w5 and 1 alias have been filtered out because: PKCS#7 SMIME decryption timing oracle; litellm never calls that API and the fix (cryptography 50.0.0) is blocked by mlflow's <50 cap; bump cryptography to 50 and remove this once mlflow allows it
GHSA-w8v5-vhqr-4h9v and 2 aliases have been filtered out because: diskcache has no fixed release published; remove this entry once one exists

No issues found

The runtime code paths that exercise cryptography (JWT auth, license verification, credential encryption) pass against 49.0.0:

$ uv run pytest tests/test_litellm/proxy/auth/test_handle_jwt.py tests/test_litellm/proxy/auth/test_litellm_license.py tests/test_litellm/proxy/common_utils/test_encrypt_decrypt_utils.py -q
148 passed, 1 warning in 72.85s (0:01:12)

Type

🚄 Infrastructure

Changes

Bumps the cryptography constraint from >=48.0.1,<49.0 to >=49.0.0,<50.0, following the same pattern as #31122. That clears GHSA-jwv3-5hgf-82ww (8.7 High) and GHSA-m2h6-j472-rp4c (6.9 Medium), both fixed in 49.0.0

GHSA-g6cj-pr64-35w5 (8.2 High) is only fixed in 50.0.0, and every released mlflow caps cryptography at <50, so the workspace cannot resolve cryptography 50 yet. It gets a [[IgnoredVulns]] entry with a 2026-09-04 expiry, mirroring the existing diskcache entry. The exposure is limited: the advisory covers a timing oracle in PKCS#7/SMIME EnvelopedData decryption, an API litellm never calls (usage is AESGCM, RSA sign/verify for JWT and licensing, x509 parsing, and Fernet). When mlflow lifts its cap, cryptography moves to 50 and the entry goes away; the expiry date forces that follow-up

The relock also moves mlflow 3.14.0 to 3.15.0 and msal 1.36.0 to 1.37.0, since both older versions cap cryptography below 49. No other packages changed

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

[greptile-apps]

Greptile Summary

This PR updates the proxy’s cryptography dependency and refreshes the lockfile to adopt compatible transitive releases, while adding a time-limited scanner exception for the remaining unreachable advisory.

• Raises the proxy cryptography range to 49.x.
• Relocks cryptography, MLflow, MSAL, and associated resolution metadata.
• Adds an expiring vulnerability-scanner exception with follow-up guidance.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete blocking or non-blocking defect identified in the dependency update or temporary scanner configuration.

The upgraded dependency resolves successfully with compatible transitive versions, existing cryptographic paths are reported as tested, lockfile marker changes preserve target-specific resolution, and the remaining scanner exception covers an operation with no repository call path and has a fixed expiry.

Important Files Changed

Filename	Overview
osv-scanner.toml	Adds a narrowly documented, expiring scanner exception for an affected API not used by the repository.
pyproject.toml	Raises the proxy cryptography dependency range from 48.x to 49.x.
uv.lock	Relocks cryptography at 49.0.0 and compatible transitive dependencies; the broader marker changes are canonicalization within unchanged resolution partitions.

_{Reviews (1): Last reviewed commit: "fix(deps): bump cryptography to 49.0.0 t..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[davesheffer]

For maintainers: the Block fork dependency changes check rejects uv.lock edits from fork PRs by design, so this PR cannot go green from my fork no matter what. The fix itself is ready and CI-verified up to that gate

Two ways to land it. Either adopt this branch into the canonical repo unchanged:

git fetch https://github.com/davesheffer/litellm.git litellm_bump_cryptography_50
git push origin FETCH_HEAD:refs/heads/litellm_bump_cryptography_50

or, if you prefer not to trust a fork's lockfile bytes (fair, that is what the guard is for), recreate it in under a minute: change the cryptography constraint in pyproject.toml to >=49.0.0,<50.0, add the GHSA-g6cj-pr64-35w5 entry from this PR's osv-scanner.toml diff, and run uv lock. The relock moves exactly five packages: cryptography 49.0.0, mlflow/mlflow-skinny/mlflow-tracing 3.15.0, msal 1.37.0

Context for the ignore entry: GHSA-g6cj-pr64-35w5 was published 2026-08-03, which is why osv-scan went red on every branch at once. Its fix is cryptography 50.0.0, but every released mlflow caps cryptography below 50, so 49.0.0 plus a time-boxed ignore is the best reachable state. The advisory covers PKCS#7 SMIME EnvelopedData decryption, an API litellm never calls. The other two advisories (8.7 High, 6.9 Medium) are fixed by 49.0.0 directly

Happy for this PR to be closed in favor of the adopted branch

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing davesheffer:litellm_bump_cryptography_50 (a05f510) with litellm_internal_staging (956d517)}