[Fix] Extend request body parameter restrictions to cloud provider auth fields

[yuneng-berri]

Summary

is_request_body_safe() blocked api_base and base_url from request bodies but did not cover cloud-provider-specific authentication parameters. This PR adds aws_sts_endpoint, aws_web_identity_token, aws_role_name, and vertex_credentials to the existing banned_params list in that function, bringing them in line with the existing restriction pattern.

The existing escape hatches (allow_client_side_credentials: true in general_settings, or model-level configurable_clientside_auth_params) continue to apply for deployments that explicitly opt in to client-side credential passing.

Changes

Added four parameters to the banned_params list in is_request_body_safe() in litellm/proxy/auth/auth_utils.py. No other logic was modified.

Testing

• Verified each newly banned parameter is rejected with a 401 when passed in a request body (5 checks)
• Verified that normal requests and existing banned params (api_base, base_url) continue to behave correctly (5 checks)
• pytest tests/test_litellm/proxy/auth/test_auth_utils.py — 56 passed

Type

🐛 Bug Fix
✅ Test

[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.

✅ yuneng-berri
❌ shin-berri
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[greptile-apps]

Greptile Summary

This PR extends is_request_body_safe() by appending aws_sts_endpoint, aws_web_identity_token, aws_role_name, and vertex_credentials to banned_params, closing cloud-provider-specific auth-field injection vectors analogous to the existing api_base/base_url blocks. The existing opt-in escape hatches (allow_client_side_credentials, configurable_clientside_auth_params) are preserved.

Confidence Score: 4/5

Safe to merge; all findings are P2 and do not block correctness of the new restrictions.

The one-line list expansion is correct and low-risk. Two P2 concerns remain: no new test cases were added to verify the new entries, and sibling AWS credential params (aws_access_key_id, aws_secret_access_key, aws_session_token) are still not banned, leaving coverage incomplete.

litellm/proxy/auth/auth_utils.py — banned_params list and its test coverage in tests/proxy_unit_tests/test_proxy_utils.py

Important Files Changed

Filename	Overview
litellm/proxy/auth/auth_utils.py	Adds aws_sts_endpoint, aws_web_identity_token, aws_role_name, and vertex_credentials to the banned_params list in is_request_body_safe(); change is minimal and correct but leaves aws_access_key_id/aws_secret_access_key/aws_session_token uncovered and ships no new tests.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Incoming Request Body] --> B{banned param present?}
    B -- No --> Z[Return True - safe]
    B -- Yes --> C{check_complete_credentials?}
    C -- True --> Z
    C -- False --> D{allow_client_side_credentials == True?}
    D -- Yes --> Z
    D -- No --> E{_allow_model_level_clientside_configurable_parameters?}
    E -- Yes --> Z
    E -- No --> F[Raise ValueError - 401 Rejected]

    subgraph banned_params
        P1[api_base]
        P2[base_url]
        P3[user_config]
        P4[aws_sts_endpoint new]
        P5[aws_web_identity_token new]
        P6[aws_role_name new]
        P7[vertex_credentials new]
    end

Loading

_{Reviews (1): Last reviewed commit: "fix: extend request body parameter restr..." | Re-trigger Greptile}

[greptile-apps]

No new tests for newly banned params

The PR description claims five per-param rejection checks, but no test cases covering aws_sts_endpoint, aws_web_identity_token, aws_role_name, or vertex_credentials appear in tests/proxy_unit_tests/test_proxy_utils.py (the only file that calls is_request_body_safe). The existing 56 passing tests don't exercise the new entries, so a future regression could silently remove these protections undetected.

[greptile-apps]

Other sensitive AWS credential params not yet banned

aws_access_key_id, aws_secret_access_key, and aws_session_token are accepted by bedrock's credential helper (see litellm/llms/bedrock/common_utils.py lines 257–297) but are absent from banned_params. A client that passes these fields forces the proxy to authenticate to AWS with caller-controlled credentials, potentially bypassing per-model access controls or audit boundaries. The existing escape hatches (allow_client_side_credentials, configurable_clientside_auth_params) already give operators an explicit opt-in path — consider extending the ban to these fields as well for consistency.

[veria-ai]

High: Incomplete restriction of cloud provider parameters allows SSRF via aws_bedrock_runtime_endpoint

This PR extends the request body parameter blocklist to cover several AWS and Vertex AI auth fields. However, aws_bedrock_runtime_endpoint is not included. This parameter controls the destination URL for Bedrock API calls and is functionally equivalent to api_base — an authenticated user can set it to redirect requests (carrying the operator's SigV4-signed AWS credentials) to an attacker-controlled endpoint. Additionally, vertex_ai_credentials is an alias for vertex_credentials that bypasses the ban.

• high: SSRF via unbanned aws_bedrock_runtime_endpoint — litellm/proxy/auth/auth_utils.py
• medium: ban bypass via vertex_ai_credentials alias — litellm/proxy/auth/auth_utils.py

[veria-ai]

High: SSRF via unbanned aws_bedrock_runtime_endpoint

aws_bedrock_runtime_endpoint controls the destination URL for all Bedrock API calls (see base_aws_llm.py:1114-1150). It's functionally equivalent to api_base for Bedrock models. An authenticated user can set this in the request body to redirect the proxy's SigV4-signed request to an attacker-controlled server, leaking the operator's AWS credentials.

Also missing: vertex_ai_credentials (alias for vertex_credentials — see vertex_llm_base.py:748-753).

Suggested change

	"vertex_credentials",
	"vertex_credentials",
	"vertex_ai_credentials",
	"aws_bedrock_runtime_endpoint",
	]

[codecov]

Codecov Report

❌ Patch coverage is 84.04344% with 191 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
litellm/llms/custom_httpx/llm_http_handler.py	49.60%	63 Missing ⚠️
...m/integrations/compression_interception/handler.py	83.43%	27 Missing ⚠️
...llm/integrations/websearch_interception/handler.py	50.94%	26 Missing ⚠️
...m/router_strategy/quality_router/quality_router.py	86.93%	23 Missing ⚠️
litellm/compression/compress.py	92.77%	12 Missing ⚠️
...lms/scaleway/audio_transcription/transformation.py	89.47%	6 Missing ⚠️
litellm/llms/bedrock/chat/mantle/transformation.py	75.00%	5 Missing ⚠️
...ass_through/messages/agentic_streaming_iterator.py	97.54%	4 Missing ⚠️
...llm/llms/bedrock/messages/mantle_transformation.py	71.42%	4 Missing ⚠️
litellm/proxy/hooks/max_budget_limiter.py	42.85%	4 Missing ⚠️
... and 9 more

📢 Thoughts on this report? Let us know!