mitigate CVE-2025-62727 for starlette

[nagmesh]

Motivation and Context

The following dependencies contain High or Critical CVEs:

• starlette (affected version 0.47.3):
  • CVE-2025-62727 → Fixed in dependency version: v0.49.1

https://www.cve.org/CVERecord?id=CVE-2025-62727

How Has This Been Tested?

Package bumped to have version higher than 0.49.1

Breaking Changes

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[maxisbey]

This CVE doesn't affect this SDK as we don't use the FileResponse object. For now I'm marking this as "Request changes" so we don't add such a strict minimum version and break a downstream applications/services.

Would be keen to hear what others think (especially @Kludex ), but I'm thinking we don't need to update this version as it doesn't affect the MCP Python SDK directly, and leave it up to users of this library to change the Starlette version used in their projects if needed.

[Kludex]

This is not necessary.

---

Exact same discussion on bump of vulnerable package versions: Kludex/uvicorn#2643

I've also reached a security expert, and this is not necessary, or wanted.

[ColeMurray]

@Kludex the vulnerable starlette version is pinned in the uv.lock and is causing downstream consumers to pull it in as a transitive dependency.

Surely we aren't suggesting that everyone downstream of MCP should explicitly add the updated starlette version to resolve this since we're not willing to update the lock file, right?

I agree with the non-pinned update in the pyproject.toml, but not updating the lock seems not ideal

[maxisbey]

@ColeMurray Which downstream consumers rely on the uv.lock file of this repo? From my understanding the uv.lock file is only used to create a reproducible environment for developers of this repo, and only the pyproject.toml is taken into account when actually building and publishing the sdk as a package.