What happened
Opening a scan report for a local stdio server (e.g. everything-server via npx @modelcontextprotocol/server-everything) shows, in the Cisco MCP Scanner execution log section of the Web UI, a line like:
"server_url": "https://mcp.deepwiki.com/mcp"
The server being scanned has no relationship to mcp.deepwiki.com. The Cisco scanner ran fully offline (NetworkReq: false, --analyzers yara,readiness static --tools tools.json) against tool definitions exported locally. No network request to deepwiki was made. This looks alarming — users reasonably assume mcpproxy is exfiltrating tool definitions to an unrelated third-party URL.
Root cause
The upstream cisco-ai-mcp-scanner PyPI package (wrapped by docker/scanners/cisco/Dockerfile) hardcodes server_url: https://mcp.deepwiki.com/mcp as a header line in its raw-format stdout regardless of the actual scan target. mcpproxy captures scanner stdout verbatim into ScannerReport.Stdout (internal/security/scanner/types.go:154) and renders it in the scan report UI per-scanner execution logs, so the bogus string leaks through.
Our own parser parseCiscoScannerOutput in internal/security/scanner/engine.go:707 correctly ignores this field — it only reads scan_results[].tool_name and findings — so findings are unaffected. This is strictly a cosmetic / trust-regression issue.
This is already noted as a known limitation in docs/features/security-scanner-plugins.md:316:
Cisco scanner output has a hardcoded server_url header in its stdout (https://mcp.deepwiki.com/mcp). Cosmetic, does not affect findings.
…but no tracking issue existed until now.
Impact
- False alarm for users: Security tooling must not display output that looks like it sent sensitive data to an unrelated third-party URL. Serious trust regression for a security feature.
- Does NOT affect findings: Parser ignores the header; only the raw-output viewer surfaces it.
Reproduction
- Add any stdio server (e.g.
everything-server via npx @modelcontextprotocol/server-everything).
- Enable the
cisco-mcp-scanner plugin.
- Run a scan from the Web UI or CLI:
mcpproxy security scan everything-server --scanner cisco-mcp-scanner.
- Open the scan report in the Web UI; expand the Cisco scanner execution log.
- Observe the hardcoded
"server_url": "https://mcp.deepwiki.com/mcp" line.
Log evidence (scan fully offline, no deepwiki network traffic)
~/Library/Logs/mcpproxy/main.log:
2026-04-11T21:17:25.931+03:00 | INFO | scanner/source_resolver.go:1047 | Resolved source from npx cache | {"server": "everything-server", "package": "@modelcontextprotocol/server-everything", "path": "/Users/user/.npm/_npx/5b2dd62b9d0bddd4/node_modules/@modelcontextprotocol/server-everything"}
2026-04-11T21:17:35.570+03:00 | INFO | scanner/engine.go:459 | Running scanner container | {"name": "mcpproxy-scanner-cisco-mcp-scanner-everything-server-6000", "image": "ghcr.io/smart-mcp-proxy/scanner-cisco:latest", "command": ["--analyzers", "yara,readiness", "--format", "raw", "static", "--tools", "/scan/source/tools.json"]}
No network activity to mcp.deepwiki.com in any log.
Proposed fixes
Option A — Sanitize on the mcpproxy side (recommended, small, local).
Before populating ScannerReport.Stdout for the cisco-mcp-scanner scanner, strip or rewrite any server_url / deepwiki header lines in the raw output and replace with a short annotation noting that the upstream scanner hardcodes a placeholder URL. Keep the rest of the raw output intact for debugging. ~20 lines in internal/security/scanner/engine.go.
Option B — Overlay actual scan target in the UI.
In frontend/src/views/ScanReport.vue, display the actual resolved source (e.g. npx_cache: /Users/.../server-everything) prominently above each scanner's raw log, and add a warning on the Cisco section explaining the placeholder URL.
Option C — File upstream bug at cisco-ai-defense/mcp-scanner.
Report to Cisco and wait for a release. Slow, and leaves the issue visible in the meantime.
Recommendation: Option A + Option C. Option A eliminates the false alarm immediately; C fixes it at the source long-term.
Relevant files
internal/security/scanner/registry_bundled.go:17-36 — Cisco scanner command and flagsinternal/security/scanner/engine.go:696-800 — Cisco output detection and parserinternal/security/scanner/types.go:154-155 — ScannerReport.Stdout / Stderrdocker/scanners/cisco/Dockerfile — thin wrapper around the upstream PyPI packagedocs/features/security-scanner-plugins.md:316 — already-documented "known limitation"frontend/src/views/ScanReport.vue — scan report viewer (Option B)
What happened
Opening a scan report for a local stdio server (e.g.
everything-servervianpx @modelcontextprotocol/server-everything) shows, in the Cisco MCP Scanner execution log section of the Web UI, a line like:The server being scanned has no relationship to
mcp.deepwiki.com. The Cisco scanner ran fully offline (NetworkReq: false,--analyzers yara,readiness static --tools tools.json) against tool definitions exported locally. No network request to deepwiki was made. This looks alarming — users reasonably assume mcpproxy is exfiltrating tool definitions to an unrelated third-party URL.Root cause
The upstream
cisco-ai-mcp-scannerPyPI package (wrapped bydocker/scanners/cisco/Dockerfile) hardcodesserver_url: https://mcp.deepwiki.com/mcpas a header line in its raw-format stdout regardless of the actual scan target. mcpproxy captures scanner stdout verbatim intoScannerReport.Stdout(internal/security/scanner/types.go:154) and renders it in the scan report UI per-scanner execution logs, so the bogus string leaks through.Our own parser
parseCiscoScannerOutputininternal/security/scanner/engine.go:707correctly ignores this field — it only readsscan_results[].tool_nameandfindings— so findings are unaffected. This is strictly a cosmetic / trust-regression issue.This is already noted as a known limitation in
docs/features/security-scanner-plugins.md:316:Impact
Reproduction
everything-servervianpx @modelcontextprotocol/server-everything).cisco-mcp-scannerplugin.mcpproxy security scan everything-server --scanner cisco-mcp-scanner."server_url": "https://mcp.deepwiki.com/mcp"line.Log evidence (scan fully offline, no deepwiki network traffic)
~/Library/Logs/mcpproxy/main.log:No network activity to
mcp.deepwiki.comin any log.Proposed fixes
Option A — Sanitize on the mcpproxy side (recommended, small, local).
Before populating
ScannerReport.Stdoutfor thecisco-mcp-scannerscanner, strip or rewrite anyserver_url/ deepwiki header lines in the raw output and replace with a short annotation noting that the upstream scanner hardcodes a placeholder URL. Keep the rest of the raw output intact for debugging. ~20 lines ininternal/security/scanner/engine.go.Option B — Overlay actual scan target in the UI.
In
frontend/src/views/ScanReport.vue, display the actual resolved source (e.g.npx_cache: /Users/.../server-everything) prominently above each scanner's raw log, and add a warning on the Cisco section explaining the placeholder URL.Option C — File upstream bug at
cisco-ai-defense/mcp-scanner.Report to Cisco and wait for a release. Slow, and leaves the issue visible in the meantime.
Recommendation: Option A + Option C. Option A eliminates the false alarm immediately; C fixes it at the source long-term.
Relevant files
internal/security/scanner/registry_bundled.go:17-36— Cisco scanner command and flagsinternal/security/scanner/engine.go:696-800— Cisco output detection and parserinternal/security/scanner/types.go:154-155—ScannerReport.Stdout/Stderrdocker/scanners/cisco/Dockerfile— thin wrapper around the upstream PyPI packagedocs/features/security-scanner-plugins.md:316— already-documented "known limitation"frontend/src/views/ScanReport.vue— scan report viewer (Option B)