Insecure transport

What mcp-scan saw

The transport scanner found ws:// at the start of a string argument or at the start of server.url. Only the unencrypted WebSocket scheme triggers it; wss:// does not. The finding is marked fixable with confidence 95.

Why it fires

A WebSocket carries the whole MCP session, so ws:// puts every tool call, every argument, and every result on the wire in the clear, for the full life of the connection rather than one request. It is also the transport most likely to cross a network boundary without anyone noticing, because the URL is written once at setup and never appears in a log.

When this is a false positive

• There is no loopback exemption. ws://localhost:8765 or ws://127.0.0.1:9000 for a server on the same machine reports at HIGH, even though nothing leaves the host.
• A container-internal or pod-internal address on a private network, where the encryption boundary is the mesh rather than the connection, still matches on scheme alone.
• A ws:// string that appears in a description or a documentation argument rather than as an actual endpoint. The check tests startsWith on arguments, so this only bites when the doc text is itself the whole argument.

How to fix it

1. Run mcp-scan fix. It rewrites ws:// to wss:// in args and url.
2. Verify the server terminates TLS on that port first. Rewriting the scheme against a plaintext listener breaks the connection rather than securing it.
3. For a loopback endpoint you intend to keep, add 'insecure-transport' to suppressRules in .mcp-scan.json, or add the server's config key to .mcp-scan-ignore to downgrade all its findings to INFO.
4. If the endpoint is remote and has no TLS listener, front it with a TLS terminator before changing the config.