The least exotic risk on the list and the one that actually shows up. Most exposed MCP servers are not subtly flawed — they answer tools/list to anyone who asks.
Paste a server URL for a free, unauthenticated scan — 27+ checks, graded report, no sign-up.
The free scan only sees what an anonymous caller sees. Authenticated and agentic depth lives in the dashboard scanner.
MCP servers tend to be built inward-out: the tools come first, the auth layer gets added at the end, and the metadata endpoints are forgotten entirely. The result is a server where calling a tool is gated but enumerating tools is not, which hands an attacker a complete map of your capabilities and argument schemas for free. Layered on top are the failures that look like auth but are not: a 401 returned for a missing token but a 200 for a malformed one, an OAuth resource that never validates the issuer, a CORS policy that reflects whatever Origin it is given and turns every browser on the internet into a confused deputy holding your user's cookies. None of these require a clever exploit chain. They require someone to send one request.
$ curl -s https://mcp.example.com/mcp \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
{"jsonrpc":"2.0","id":1,"result":{"tools":[
{"name":"query_database","description":"Run a read query against production..."},
{"name":"send_email","description":"Send email as the workspace..."},
{"name":"delete_record","description":"Delete a record by id..."}
]}}No Authorization header, no session, full capability disclosure. Tool invocation may still be gated — but the attacker now knows exactly what to target and with what arguments.
This is the deepest-covered category in the scanner: seventeen mapped checks spanning transport (TLS version, certificate validity, HSTS, HTTP→HTTPS upgrade), the auth boundary itself (whether unauthenticated requests are refused, whether tools/list and resources/list leak, whether an invalid token is actually rejected rather than merely a missing one), OAuth metadata advertisement, CORS policy and origin reflection, and the three 2026-07-28 hardening requirements — issuer binding, dynamic client registration and protocol header consistency.
What this cannot tell you
Everything here is observed from outside with no credentials, so it establishes whether a boundary exists — not whether it is correct for a given user. Per-user authorization is invisible to an unauthenticated probe: the IDOR check reads tool schemas and documentation for signs that resource identifiers are accepted without an ownership check, which is a documentation heuristic and capped low on purpose. Confirming that user A cannot read user B's records requires an authenticated scan with two real principals.
tools/list, resources/list and prompts/list must sit behind the same check as tools/call. If your framework wires auth as per-tool middleware, the list endpoints almost certainly bypass it — that is the default failure mode, not an unusual one.
Verify signature, expiry, issuer and audience. A surprising number of servers branch on whether an Authorization header is present and never validate its contents, which means any string at all is a valid credential.
Echoing the request Origin into Access-Control-Allow-Origin with credentials enabled defeats the same-origin policy entirely. Use a fixed allowlist. For a genuinely public, unauthenticated server a wildcard is fine — what is never fine is reflection plus credentials.
Under 2026-07-28, validate that the token was issued for your server and by your expected issuer. Without audience binding, a token minted for any other MCP server in your org is accepted by yours, which turns one compromised integration into all of them.
Background reading on this risk: How to Add Authentication to Your MCP Server — OAuth 2.1, Bearer Tokens, and What the Spec Requires.
This category is reported as verified evidence and needs at least passive scan depth to produce a real result.
Not necessarily — plenty of legitimate servers are deliberately open. What matters is that the exposure is intentional and that the tools behind it are safe to offer anonymously. The finding is only a finding when tools that act on private data or mutate state answer to anyone.
It converts a blind target into a mapped one. Descriptions and input schemas tell an attacker which tools touch production, what arguments they take and what the valid ranges are. It also leaks business information — your tool list is a fairly precise description of what your product does internally.
The revision tightened three things the scanner checks separately: issuer validation became explicit, dynamic client registration requirements changed, and protocol header handling was made consistent so a client and server cannot silently disagree about which revision they are speaking.
No — and that is deliberate. The free scan sees exactly what an anonymous attacker sees, which is the right perspective for this category. Authenticated scanning, which can test authorization between real principals, lives in the dashboard scanner.