merge main

[Sameerlite]

Title

Relevant issues

Pre-Submission checklist

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

• I have Added testing in the tests/litellm/ directory, Adding at least 1 test is a hard requirement - see details
• I have added a screenshot of my new test passing locally
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible, it only solves 1 specific problem

Type

🆕 New Feature
🐛 Bug Fix
🧹 Refactoring
📖 Documentation
🚄 Infrastructure
✅ Test

Changes

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
litellm	Ready	Preview	Comment	Nov 26, 2025 4:18pm

To fix this problem, the code should avoid logging any part of the authentication header dictionary which may contain sensitive information, even its keys (since they may contain identifying data or can be used to enumerate the types of auth mechanisms present).
The best way to fix is to either remove the log statement at line 466 entirely, or replace it with a generic message that does not output any data from mcp_server_auth_headers. If visibility is required for debugging, log only that auth headers are present, or the count (number of headers), without listing names or values.
Edit only line 466 of litellm/proxy/_experimental/mcp_server/server.py to remove the risky log statement or make it generic, ensuring you do not log sensitive data.

No new imports or methods are needed.

---

The best way to fix the issue is to avoid logging the full contents of mcp_servers directly. Instead, log only non-sensitive, high-level information, such as the count of items, or specific non-sensitive attributes if required (e.g., server "aliases" but never credentials/keys/hostnames). This can be performed by changing the affected verbose_logger.debug call on line 463 in litellm/proxy/_experimental/mcp_server/server.py to redact sensitive details, such as logging only the type of value (if present), or the count/summary information, rather than the full data structure.

Specific steps:

• Edit the affected debug line (verbose_logger.debug(...)) in the list_resource_templates endpoint.
• Replace it with a log statement that does NOT include the full content of mcp_servers, but instead logs, e.g., the number of servers (len(mcp_servers) if a list), or "present/absent" if None.
• No changes to imports or additional methods are necessary.
• This change ensures sensitive details are never written to logs, following the project logging convention.

---

To fix clear-text logging of sensitive information, you should never log raw authentication objects or credentials. Instead:

1. Identify the region to fix:
   In litellm/proxy/_experimental/mcp_server/server.py, at line 460, the code logs the entire user_api_key_auth object.
2. Best way:
   Only log non-sensitive, high-level information. For example, if user_api_key_auth contains or has an identifier (such as a username, safe account id, or just that the key exists), log only that non-sensitive part—or omit the log altogether if it is not necessary.
3. Implement:
   Change the logging statement at line 460 to either:
   • Not log the user_api_key_auth at all, or
   • Log a sanitized/minimal/safe detail (e.g., type, presence, or a masked identifier).
   • This does not require new library imports since you already use logging and string formatting.
   • If the class has something like .user_id or .username, use that; otherwise log only that key is present.

To fix this problem, we should avoid logging any part of the mcp_server_auth_headers dictionary that could contain sensitive information. The best approach is to remove this debug log line entirely, or to ensure only sanitized, non-sensitive, static data is logged instead (such as indicating presence of headers, how many keys, or listing only known-safe key names). Specifically, replace or remove line 428 in list_resources() to ensure no sensitive data—header keys or values—are ever written to logs.

Implementation:

• Remove or heavily sanitize line 428 of list_resources in litellm/proxy/_experimental/mcp_server/server.py.
• If logging presence of headers is helpful, you may log the number of headers or a static string instead.
• No additional imports or dependencies are required.

To address the clear-text logging of potentially sensitive data, we should avoid printing the full contents of mcp_servers directly. Instead, we should:

1. Log only the count (number of elements) or a generic placeholder if mcp_servers is present, rather than printing full values.
2. Optionally, if needed for diagnostics, ensure that only non-sensitive attributes (e.g., server aliases, not auth data) are logged.
3. The fix is specific to line 425, where the log statement should be updated.
4. No additional imports or methods are needed, only an edit to the log statement.

---

The best way to fix this problem is to avoid logging sensitive details. Instead, log only non-sensitive metadata such as existence, type, or user id—never the actual key or credential values.

• In file litellm/proxy/_experimental/mcp_server/server.py, in the list_prompts async function, change the log statement at line 342 to redact the sensitive details, e.g., log only whether user_api_key_auth exists or (if it has a user_id or similar attribute) log that instead.
• Do not log the string representation of the full object.
• No changes elsewhere or additional imports are needed.

---

To fix this, we should parse the endpoint URL using Python's urllib.parse.urlparse, extract its hostname, and check if it matches the trusted host (app.phoenix.arize.com) or its allowed subdomains (using explicit matching). The substring check ("app.phoenix.arize.com" in endpoint) should be replaced with code that parses endpoint and performs the check on the hostname field. The only lines to change are those that check for "app.phoenix.arize.com" in the endpoint string, which is line 61 and 86 in your code. We'll import urllib.parse.urlparse at the top, and replace both usages with parsed hostname checks.

---

To fix this issue, we need to parse collector_endpoint as a URL, extract its hostname, and then check if it matches or ends with the expected domain (e.g., "app.phoenix.arize.com"). We should do this instead of using the string containment (in) check. We'll use Python's standard urllib.parse library for this purpose, as it provides a safe way to extract the hostname. The change applies to line 61 in litellm/integrations/arize/arize_phoenix.py and any other "app.phoenix.arize.com" in ... checks, specifically line 86 for the value in endpoint. We'll need to import urlparse at the top. Only these spots are in scope for the change.

To fix the problem, we should prevent logging of API URLs that may contain sensitive or secret information, especially those derived from environment variables or secret managers. Concretely, in transform_delete_skill_request (and similar places), where the full URL including api_base is logged, we need to mask or avoid logging the actual value. A good approach is to redact the sensitive part:

• Never log the api_base directly.
• If logging is essential for debugging, log only the endpoint path or use a string like [REDACTED] in place of secrets.
• Update the logger line on line 195 and line 166 to either remove the variable or mask it appropriately (e.g., "Delete skill request - URL: [REDACTED]").
• Similarly update any other debug logs which output sensitive URLs, such as line 166 (Get skill request - URL: %s) if it uses the same mechanism.

No additional methods or imports are needed, just a change in the arguments to the logger.

To fix the problem, avoid logging the entire request URL with potential secrets in logs. Instead, log only non-sensitive components (such as endpoint names, IDs, or operation types), or redact the sensitive api_base portion. Specifically, in transform_get_skill_request, on line 166, replace the logging of url with either a redacted version or log only the endpoint/skill ID. Other places in the code (shown here) do not log sensitive endpoints directly.

No additional dependencies are required; only update or replace the logging statement on line 166 to ensure no clear-text sensitive values are written to logs. For example, log "Get skill request" with just the endpoint and skill ID, and replace any logging of the full URL.

---

[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.
11 out of 12 committers have signed the CLA.

✅ Sameerlite
✅ krrishdholakia
✅ ishaan-jaff
✅ uc4w6c
✅ reflection
✅ CAFxX
✅ AlexsanderHamir
✅ otaviofbrito
✅ eagle-p
✅ choigawoon
✅ yuneng-jiang
❌ KeremTurgutlu
_{You have signed the CLA already but the status is still pending? Let us recheck it.}