MCPProxy Security Scanner QA Report

Threat classification: 247 dangerous, 473 warnings, 1,179 informational

File: internal/httpapi/security_scanner.go

When a scan is already running for a server and another scan is triggered, the API now returns HTTP 409 Conflict instead of 500 Internal Server Error.

Validated: POST /scan returns 409 with "scan already in progress" message

File: internal/security/scanner/service.go

When merging Pass 1 (security scan) and Pass 2 (supply chain audit) reports, duplicate findings (same scanner + rule + title) are now removed. Pass 1 findings take priority.

Example: Perplexity had 4 findings (2 duplicated). Now correctly shows 2.

Validated: perplexity report shows 2 findings (was 4)

File: internal/security/scanner/service.go

The global security overview now correctly counts findings by threat level (dangerous, warnings, info_level). Previously these were all zero because ClassifyFinding() wasn't called during overview aggregation.

Validated: Overview shows dangerous=247, warnings=473, info_level=1179 (was all 0)

File: frontend/src/views/ServerDetail.vue

Added a "Cancel" button that appears during active scans. Calls the existing cancelScan API endpoint, stops polling, and resets scan state.

Validated: Cancel button renders, calls API correctly

File: frontend/src/views/ServerDetail.vue

The Scanned Files collapsible section is now hidden for HTTP servers and tool_definitions_only source methods (no filesystem to show files for).

Validated: Section hidden for url, url_full, and tool_definitions_only

File: frontend/src/views/ServerDetail.vue

Added a "Retry" button to the scan error alert, allowing users to easily re-trigger a scan after failure without refreshing the page.

Validated: Retry button clears error and re-triggers scan

Scanner: cisco-mcp-scanner | Findings: 2

What was flagged:

Analysis: This is standard MCP tool description pattern. Context7 instructs the LLM to call resolve-library-id before query-docs. The phrase "You MUST call" triggers the prompt injection detector, but this is normal tool orchestration guidance, not malicious prompt injection.

Verdict: FALSE POSITIVE — Cisco scanner is too aggressive with imperative language in tool descriptions.

Scanner: cisco-mcp-scanner | Findings: 16 (2 dangerous + 14 warning)

What was flagged: All audio tools (text_to_speech, speech_to_text, text_to_sound_effects, isolate_audio, speech_to_speech, etc.) flagged as "SYSTEM MANIPULATION"

Analysis: ElevenLabs is a legitimate audio processing API. Its tools interact with audio data, not system resources. The scanner's description of system manipulation ("unsolicited modification or deletion of files, registries") does not match what these tools do.

Verdict: FALSE POSITIVE — Cisco scanner misclassifies media processing as system manipulation.

The quarantined malicious-demo server can't have its tool definitions exported because it fails to connect (MCP initialize timeout). The cisco-mcp-scanner, which is the primary tool poisoning detector, requires /scan/source/tools.json which can't be created without a connection.

Impact: Quarantined servers that are truly malicious can't be scanned for tool poisoning — the exact scenario this feature is designed for.

Suggested fix: Cache tool definitions when they are first discovered (before quarantine), so scanning can use cached definitions even when the server refuses to connect.

Some servers get 6 scanners, others only 1-3. The scanner selection logic doesn't match scanner capabilities to source types. For example, hugginface (HTTP, 8 tools) only ran semgrep, while context7 (HTTP, 2 tools) ran all 6.

Impact: Inconsistent security coverage across servers.

Suggested fix: Implement scanner-to-source capability matching based on scanner input requirements.

The Cisco MCP Scanner produces a high false positive rate for standard MCP tool descriptions. Imperative language ("You MUST call", "always use") and media processing tools are incorrectly flagged.

Impact: Risk score of 60-100 for legitimate servers, eroding user trust.

Suggested fix: Implement scanner result post-processing to filter known false positive patterns, or adjust cisco scanner configuration thresholds.

Priority 1 (Next Sprint)

• Cache tool definitions for quarantined servers to enable tool poisoning detection
• Implement scanner-source capability matching to avoid running irrelevant scanners
• Add false positive suppression rules for cisco-mcp-scanner (imperative language patterns)
• Fix CancelScan to actually terminate Docker containers
• Fix Pass 1/Pass 2 race condition (Pass 2 starts before Pass 1 cleanup)

Priority 2 (Future)

• Add report directory cleanup (TTL-based or max-size)
• Add Risk Score explanation tooltip in the UI
• Show "last scanned" timestamp prominently
• Add scan history view (past scans comparison)
• Improve error handling for nonexistent servers (404 instead of 500)
• Add scanner input/output type enforcement during installation

Priority 3 (Polish)

• Standardize risk score color thresholds across all pages
• Add debounce to Scan Now button
• Add polling error limit (stop after N consecutive failures)
• Show scanner capability badges in the scanner list
• Improve progress bar to distinguish failed vs completed scanners