litellm - 💡(How to fix) Fix Bedrock retry can replay stale SigV4 headers after signing [1 pull requests]

Summary

In the Bedrock SigV4 request path, LiteLLM signs the current request body with sigv4.add_auth(request), then replays caller headers back onto the signed request.

On retry/fallback paths, those caller headers can include stale SigV4 headers from a previous request, such as Authorization, x-amz-date, or x-amz-security-token. Replaying them after signing can make AWS validate a different canonical request than the one LiteLLM signed.

Trigger

We observed this in a Claude CLI session using LiteLLM routing/fallbacks.

The conversation history included Anthropic thinking blocks. A request hit the invalid-thinking-signature retry path, where LiteLLM stripped historical thinking / redacted_thinking blocks before retrying. The retried request then reached a Claude model routed through Bedrock, for example:

ageneric_api_call_with_fallbacks(model=claude-haiku-4-5-20251001)

The Bedrock request was freshly signed, but stale SigV4-related headers from the caller headers were replayed onto the signed request afterward. AWS then validated the actual request headers against the current body and rejected the signature.

This was not caused by invalid AWS credentials. The AWS error included the canonical request it expected for the current body.

Error

LiteLLM Router:INFO: router.py:3934 - ageneric_api_call_with_fallbacks(model=claude-haiku-4-5-20251001) Exception {"message":"The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.\n\nThe Canonical String for this request should have been\n'POST\n/model/us.anthropic.claude-haiku-4-5-20251001-v1%3A0/invoke-with-response-stream\n\ncontent-type:application/json\nhost:bedrock-runtime.us-west-2.amazonaws.com\nx-amz-date:20260508T104334Z\nx-amz-security-token:REDACTED\n\ncontent-type;host;x-amz-date;x-amz-security-token\nPAYLOAD_HASH_REDACTED'\n\nThe String-to-Sign should have been\n'AWS4-HMAC-SHA256\n20260508T104334Z\n20260508/us-west-2/bedrock/aws4_request\nSTRING_TO_SIGN_HASH_REDACTED'\n"}

Expected behavior

After generating a fresh SigV4 signature, LiteLLM should not replay caller headers that are bound to the current signature.

Unsigned forwarded/custom headers should still be preserved.

Proposed fix

Parse SignedHeaders from the freshly generated Authorization header and skip replaying caller headers whose names are part of the current signature.