Background
fastmcp reaches our dependency tree transitively via rf-mcp, which RoboScope auto-starts on 127.0.0.1:9090 to power keyword discovery, library recommendations, and the AI .roboscope ↔ .robot generation flow.
backend/pyproject.toml currently pins fastmcp<3. rf-mcp 0.31.2 declares only fastmcp>=2.8.0 (no upper bound), but fastmcp 3.x ships API breaks that rf-mcp does not yet support. Removing our pin without an rf-mcp update would risk runtime breakage in the keyword palette + AI generation paths.
Open Dependabot alerts on fastmcp < 3.2.0
Why we ship 0.9.0 with this open
None of the three vulnerable APIs are reached through RoboScope's usage of rf-mcp:
OpenAPIProvider — rf-mcp exposes keyword-discovery tools, it never spins up an OpenAPI-derived MCP server.
OAuthProxy — rf-mcp has no OAuth proxy flow.
gemini-cli — RoboScope calls LLM providers directly via httpx; no gemini-cli integration.
The rf-mcp server also binds to 127.0.0.1 only by default. Documented in SECURITY.md under "Known Third-Party Advisories".
Plan
- Watch
rf-mcp releases for a build that declares fastmcp >= 3.2.0.
- When that release lands:
- Bump
rf-mcp in backend/pyproject.toml to that version.
- Drop the
fastmcp<3 pin (or relax to >=3.2.0,<4).
- Run the
tests/recording/, tests/ai/, and tests/recording/test_v2_* suites to confirm rf-mcp keyword discovery + AI generation still work end-to-end.
- Smoke-test the Flow Editor's Keyword Palette in a live browser — that's the most user-visible rf-mcp consumer.
- Ship the bump in 0.9.1.
Workaround for operators
If you bind rf-mcp to a non-loopback interface, manually pin fastmcp >= 3.2.0 in your overrides and accept the (small) rf-mcp compatibility risk until 0.9.1 ships.
References
- Bundled
rf-mcp version: 0.31.2
- Bundled
fastmcp version (current): 2.14.7
- Pin location:
backend/pyproject.toml
- Manager module:
backend/src/ai/rf_mcp_manager.py
Background
fastmcpreaches our dependency tree transitively viarf-mcp, which RoboScope auto-starts on127.0.0.1:9090to power keyword discovery, library recommendations, and the AI.roboscope ↔ .robotgeneration flow.backend/pyproject.tomlcurrently pinsfastmcp<3.rf-mcp 0.31.2declares onlyfastmcp>=2.8.0(no upper bound), butfastmcp 3.xships API breaks thatrf-mcpdoes not yet support. Removing our pin without anrf-mcpupdate would risk runtime breakage in the keyword palette + AI generation paths.Open Dependabot alerts on
fastmcp < 3.2.0OpenAPIProvider(SSRF + Path Traversal)OAuthProxycallback (Confused Deputy)gemini-cliMCP-tool injectionWhy we ship 0.9.0 with this open
None of the three vulnerable APIs are reached through RoboScope's usage of
rf-mcp:OpenAPIProvider—rf-mcpexposes keyword-discovery tools, it never spins up an OpenAPI-derived MCP server.OAuthProxy—rf-mcphas no OAuth proxy flow.gemini-cli— RoboScope calls LLM providers directly viahttpx; no gemini-cli integration.The
rf-mcpserver also binds to127.0.0.1only by default. Documented in SECURITY.md under "Known Third-Party Advisories".Plan
rf-mcpreleases for a build that declaresfastmcp >= 3.2.0.rf-mcpinbackend/pyproject.tomlto that version.fastmcp<3pin (or relax to>=3.2.0,<4).tests/recording/,tests/ai/, andtests/recording/test_v2_*suites to confirm rf-mcp keyword discovery + AI generation still work end-to-end.Workaround for operators
If you bind
rf-mcpto a non-loopback interface, manually pinfastmcp >= 3.2.0in your overrides and accept the (small) rf-mcp compatibility risk until 0.9.1 ships.References
rf-mcpversion: 0.31.2fastmcpversion (current): 2.14.7backend/pyproject.tomlbackend/src/ai/rf_mcp_manager.py