Migrate FastMCP to v3.2.0 (CVE-2026-32871)#19
Conversation
Upgrade fastmcp dependency to >=3.2.0 to patch critical SSRF and Path Traversal vulnerability (CVE-2026-32871). Fixes deprecated import paths and removed API patterns where applicable.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Remove invalid fastmcp version string from [tool.uv.sources] sections. uv.sources requires source maps (git/path/url), not version specifiers.
Remove invalid fastmcp version string from [tool.uv.sources] sections. uv.sources requires source maps (git/path/url), not version specifiers.
| "datadog-api-client>=2.44.0", | ||
| "fastapi>=0.121.1", | ||
| "fastmcp>=2.12.4", | ||
| "fastmcp>=3.2.0", |
There was a problem hiding this comment.
Lock files not updated, still pin FastMCP v2
High Severity
The pyproject.toml files were bumped to fastmcp>=3.2.0, but agents/uv.lock still locks fastmcp to 2.13.2 and environment/uv.lock still locks to 2.13.0.2. The lock file metadata also retains the old >=2.12.4 specifier. Since the environment/Dockerfile copies uv.lock and runs uv sync --all-groups, uv will detect the mismatch between the lock file and pyproject.toml and fail, breaking Docker builds. The CVE-2026-32871 security patch won't actually be applied in these packages because the locked versions are still v2.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 956939f. Configure here.
FastMCP v3 renamed batch getters: - get_tools() -> list_tools() - get_resources() -> list_resources() Also removes invalid fastmcp entries from [tool.uv.sources] where applicable.
FastMCP v3 list_tools() returns list[Tool] instead of dict[str,Tool]. - Remove .values() calls on list_tools() results - Change for name,tool in tools.items() to for tool in tools
FastMCP v3 removed _tool_manager. Tools are now in _local_provider._components. Also fixes description -> instructions kwarg in FastMCP() constructor.
| tools = await mcp_instance.list_tools() | ||
| server_tools = [] | ||
| for tool in tools.values(): | ||
| for tool in tools: |
There was a problem hiding this comment.
Tool extraction scripts produce entries without schemas
Medium Severity
All extract_tools.py scripts check hasattr(tool, "parameters") and hasattr(tool, "output_schema"), but mcp.types.Tool returned by list_tools() has neither attribute — it uses inputSchema instead. Both conditions evaluate to False, so every extracted tool entry will contain only name and description, with inputSchema silently omitted. This affects all 8 extract scripts across calendar, chat, code, documents, filesystem, mail, pdfs, presentations, and spreadsheets.
Additional Locations (2)
Reviewed by Cursor Bugbot for commit 07b97d7. Configure here.
… mutations FastMCP v3 list_tools() returns fresh objects each call, so schema mutations via list_tools() dont persist. Use _local_provider._components which returns the stored tool objects directly.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
There are 3 total unresolved issues (including 2 from previous reviews).
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 5983d46. Configure here.
|
|
||
| async def _flatten_tool_schemas(): | ||
| for tool in (await mcp.get_tools()).values(): | ||
| for tool in mcp._local_provider._components.values(): |
There was a problem hiding this comment.
Fragile private API access for component iteration
Medium Severity
mcp._local_provider._components is a private API accessing internal FastMCP internals. In v3, _components is a unified dictionary containing all registered component types (tools, resources, prompts) with type-prefixed keys — not just tools. While only tools are currently registered and the getattr guard provides safety, this approach is tightly coupled to undocumented internals and will break silently if the internal storage structure changes in a future FastMCP release.
Additional Locations (2)
Reviewed by Cursor Bugbot for commit 5983d46. Configure here.
The /arco/validate endpoint was moved to /services/validate behind MERCOR_INTELLIGENCE_API_KEY in biome PR #6570.
jwstanly
left a comment
jwstanly
left a comment
There was a problem hiding this comment.
Approve: FastMCP v3.2.0 migration; validate workflow uses https://api.studio.mercor.com/services/validate with MERCOR_INTELLIGENCE_API_KEY where applicable.
|
Approval is for the FastMCP v3.2.0 CVE bump. This PR diff does not change an ArCo validate workflow. If you add CI that calls Studio validate, use POST https://api.studio.mercor.com/services/validate with header X-API-Key: ${{ secrets.MERCOR_INTELLIGENCE_API_KEY }}. |
2 participants
Summary
Changed files
agents/pyproject.tomlenvironment/pyproject.tomlmcp_servers/calendar/pyproject.tomlmcp_servers/calendar/smoke_test/pyproject.tomlmcp_servers/chat/pyproject.tomlmcp_servers/chat/smoke_test/pyproject.tomlmcp_servers/code/pyproject.tomlmcp_servers/code/smoke_test/pyproject.tomlmcp_servers/documents/pyproject.tomlmcp_servers/documents/smoke_test/pyproject.tomlmcp_servers/filesystem/pyproject.tomlmcp_servers/filesystem/smoke_test/pyproject.tomlmcp_servers/mail/pyproject.tomlmcp_servers/mail/smoke_test/pyproject.tomlmcp_servers/pdfs/pyproject.tomlmcp_servers/pdfs/smoke_test/pyproject.tomlmcp_servers/presentations/pyproject.tomlmcp_servers/presentations/smoke_test/pyproject.tomlmcp_servers/spreadsheets/pyproject.tomlmcp_servers/spreadsheets/smoke_test/pyproject.tomlTest plan
🤖 Generated with Claude Code