Obfuscated endpoint

What mcp-scan saw

The scanner looked for three encodings of a URL prefix: base64 of http or https (strings starting aHR0c or c2h0dH), hex of the ASCII for http (68747470 followed by hex), and a reversed scheme (//:ptth or //:sptth). Any hit records a synthetic endpoint and pushes this finding.

Why it fires

None of the three encodings survives a human reading the config, and none of them is a format any MCP client asks for. A URL is a URL in a config file, so an encoded one exists specifically to get past a reviewer or a string-matching policy. The check is prefix-anchored rather than generic base64, which is why it does not fire on every long token.

When this is a false positive

• A base64 blob that legitimately contains a URL near its start decodes to something beginning http and therefore begins aHR0c. A base64-encoded JSON config, a data URI, or an OAuth state parameter carrying a redirect_uri all do this.
• A hex-encoded payload for an unrelated reason, for example a checksum or a serialized protobuf, that happens to contain the byte sequence 68 74 74 70.
• A base64-encoded webhook or callback URL that your own tooling encodes on purpose to keep it out of a query string.

How to fix it

1. Decode the value yourself before deciding anything. For base64, echo the string and pipe it through base64 -d; for hex, use xxd -r -p.
2. If it decodes to a host you do not recognize, remove the server and rotate every credential in its env block.
3. If it decodes to a host you expect, replace the encoded form with the plain URL in the config and add the host to allowedDomains in .mcp-scan.json.
4. If the encoding is required by the downstream service, move it out of the config: pass the plain URL and have the server encode it at call time.
5. Re-scan and confirm the finding is gone rather than assuming the decode explained it.