# 2026-05-13

- 分析 CloudBase-MCP `downloadRemoteFile` SSRF 报告：确认 `mcp/src/tools/download.ts` 先 `http.get/https.get` 再做 `isUrlAndContentTypeSafe` 校验，属于真实的 pre-connect 校验顺序缺陷。
- 本地复现实锤：对 `127.0.0.1:18090` 调用时本地监听端收到真实 GET 请求，但工具返回“目标为内网地址”；对关闭端口 `127.0.0.1:18091` 返回 `ECONNREFUSED`，形成 blind SSRF / 端口探测原语。
- 结论建议：不要用“本地 npx 启动/云模式可关闭工具”否定漏洞成立；更准确的表述是本地 MCP 宿主侧 SSRF，影响边界低于云端服务端 SSRF，但仍应修复并在工单里强调前提与影响边界。
- 补充输出：为用户起草了面向 TSRC 的回复口径，主张不否认技术缺陷成立，但强调其为本地宿主侧风险、利用前提较高、增量攻击面有限，不应按高危云端 SSRF 定级。
- 继续收敛表述：建议用户在工单中只陈述“校验时机不够前置、请求可能先于拦截发生、影响限于本地宿主侧”三点，并配合生活化类比说明“先放行后拦截”与“本地宿主侧≠云端暴露面”的区别。
- 从利用方视角补充分析：该问题更像低能力、盲打型本地宿主侧网络触达原语，攻击收益受限于触发链、工具权限、仅 GET 下载语义、结果不可直接回显等条件；适合用“增量能力有限、更多是便利化而非决定性突破”来压低定级。
- 继续为用户润色正式工单口径：重点强化“本地开发/调试场景、攻击面在本地宿主网络而非云端公网服务、利用需满足工具启用与触发链前提、收益主要是有限探测能力”四个点，避免主动下重攻击定性。
- 针对“利用面”表述继续细化：建议把利用拆成前提、能力、收益、边界四段写清，避免只写“有限”但不解释为何有限。
- 新增表述建议：用户希望突出“Agent/MCP 主要运行在本地，且在具备 shell/代码执行能力的使用场景下，其利用价值与 AI 直接诱导发起 curl/自定义请求接近，因此该工具带来的新增攻击能力有限”这一论点。
- 用户进一步希望直接采用“不是 SSRF”口径；建议改写为“本问题不认定为典型 SSRF 类漏洞，更接近本地 Agent/MCP 工具的校验时机问题”，以降低被抓绝对表述漏洞的风险。
