fix(proxy): cache invalidation double-hashes token in bulk update and key rotation

[dkindlund]

Summary

• Two remaining hash_token() calls in cache invalidation paths double-hash pre-hashed token IDs, causing cache invalidation to silently fail
• Fix: use _hash_token_if_needed() (which passes pre-hashed tokens through unchanged), matching the pattern established by PR fix: allow hashed token_id in /key/update endpoint #24969

Root cause

When /key/update or /key/bulk_update is called with a pre-hashed token ID (not an sk- prefixed key), hash_token() produces a hash-of-hash that does not match the actual cache key. The _delete_cache_key_object call deletes nothing, and the stale cached key object (with outdated fields) remains.

This is compounded by update_cache() in proxy_server.py, which writes the stale cached key object back to user_api_key_cache with a fresh 60s TTL after every successful LLM request. As long as requests keep flowing, the stale entry never expires — the updated fields (e.g. max_budget, models, metadata) are never picked up.

PR #24969 fixed this in update_key_fn but missed two other call sites:

Location	Line	Before	After
_process_single_key_update	1852	hash_token(key_update_item.key)	_hash_token_if_needed(key_update_item.key)
_execute_virtual_key_regeneration	3724	hash_token(key)	_hash_token_if_needed(key)

Reproduction steps

1. Create a virtual key and note the token hash from the response
2. Update the key using the token hash (not the sk- key):

   curl -X POST http://localhost:4000/key/update \
     -H "Authorization: Bearer sk-master" \
     -d '{"key": "<token_hash>", "max_budget": 100}'

3. Verify via /key/info that the DB was updated (shows max_budget: 100)
4. Send requests using the key — the budget is not enforced because the cached key object still has max_budget: null
5. The stale cache entry persists indefinitely as long as requests keep flowing (each successful request refreshes the TTL via update_cache)

Related

• fix: allow hashed token_id in /key/update endpoint #24969 — fixed the same bug in update_key_fn (merged April 3, 2026)
• [Bug]: Virtual key/generate returns 403 with stale team MCP access groups immediately after team update #25286 — similar stale-cache issue for team objects

Test plan

• New test: test_process_single_key_update_cache_invalidation_with_token_hash — verifies the token hash is passed as-is (not double-hashed) to _delete_cache_key_object
• Existing test_process_single_key_update continues to pass

Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Apr 11, 2026 4:54am

[codspeed-hq]

Merging this PR will not alter performance

✅ 16 untouched benchmarks

---

_{Comparing dkindlund:fix/cache-invalidation-hash-token (82f2006) with main (4e12d3c)}

[greptile-apps]

Greptile Summary

This PR fixes two remaining double-hashing bugs in cache invalidation paths that were missed by PR #24969. When a pre-hashed token ID (not sk- prefixed) is passed to /key/bulk_update or /key/regenerate, the old hash_token() call would produce a hash-of-hash that doesn't match any cache key, leaving stale entries to persist indefinitely. Replacing both with _hash_token_if_needed() (which passes pre-hashed tokens through unchanged) is the correct fix, consistent with the pattern already applied elsewhere in the file. Tests are added for both fixed call sites.

Confidence Score: 5/5

Safe to merge — minimal, correct fix with no behavioural change for the happy path and proper test coverage for both fixed call sites.

The two-line production change is a precise, well-scoped fix that mirrors the pattern already applied in PR #24969. Both fixed call sites now have dedicated unit tests asserting the token is passed through unchanged. No regressions are introduced; the fix only affects callers supplying pre-hashed tokens (the previously broken path). All remaining observations are P2 or lower.

No files require special attention.

Important Files Changed

Filename	Overview
litellm/proxy/management_endpoints/key_management_endpoints.py	Replaces hash_token() with _hash_token_if_needed() in two cache invalidation call sites (_process_single_key_update L1852 and _execute_virtual_key_regeneration L3724), correctly fixing double-hashing of pre-hashed tokens
tests/test_litellm/proxy/management_endpoints/test_key_management_endpoints.py	Adds two async unit tests verifying both fixed call sites pass pre-hashed tokens through to _delete_cache_key_object unchanged; no real network calls; all mocked correctly

Sequence Diagram

sequenceDiagram
    participant Client
    participant BulkUpdate as _process_single_key_update
    participant Regen as _execute_virtual_key_regeneration
    participant DB as Prisma DB
    participant Cache as user_api_key_cache

    Note over Client,Cache: /key/bulk_update with pre-hashed token ID

    Client->>BulkUpdate: key is pre-hashed token
    BulkUpdate->>DB: update_data with token
    Note over BulkUpdate: _hash_token_if_needed(key) returns token as-is
    BulkUpdate->>Cache: _delete_cache_key_object with correct hash

    Note over Client,Cache: /key/regenerate with pre-hashed token ID

    Client->>Regen: key is pre-hashed token
    Regen->>DB: update verificationtoken record
    Note over Regen: _hash_token_if_needed(key) returns token as-is
    Regen->>Cache: _delete_cache_key_object with correct hash

    Note over Client,Cache: Before fix: hash_token produced wrong hash, cache miss, stale entry persisted

Loading

_{Reviews (2): Last reviewed commit: "fix(proxy): use _hash_token_if_needed fo..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!