Code Vulnerabilities

1 findingMCP03MCP05MCP07ASI02ASI05CoSAI-T3MAESTRO-L3EU-AI-Act-Art-15AML.T0054#

Server-Hardening Failures

1 finding
E1

No Authentication Required

MediumMCP07-insecure-config

MCP server accepts initialize handshake without any authentication token or API key

  1. 1Connect to the MCP server transport (streamable-http) without providing any credentials (no Authorization header, no API key query parameter, no mTLS certificate). Issue the `initialize` request followed by `tools/list`. If both succeed, authentication is genuinely absent.capability:toolsExpect: Server responds 200/OK to `initialize` and returns the tool list without a 401/403 or any WWW-Authenticate challenge.
  2. 2If the MCP server is fronted by a reverse proxy (nginx / envoy / Traefik / IAP), inspect the proxy configuration and confirm whether auth is terminated at that layer. If yes, document the proxy's auth strategy in an audit note; the finding can then be dismissed with provenance. If no, the server is the auth boundary and E1 stands.nginx.conf/server/locationExpect: Either the proxy enforces auth (dismiss with audit trail) or no proxy exists (E1 stands).
  3. 3Verify the server's bind address. A 127.0.0.1 bind is not a substitute for authentication — DNS rebinding (Jackson/Bortz/Boneh 2007) makes localhost reachable from any web page the user visits. Unauthenticated localhost MCP servers have been demonstrated-exploited in the wild.capability:toolsExpect: Bind address is 0.0.0.0 / a routable IP (direct network exposure) OR 127.0.0.1 (still exposed via DNS rebinding from a malicious web page).
sourceenvironment
capability:tools
Live connection to the MCP server over streamable-http succeeded with no credentials. `initialize` + `tools/list` returned without any WWW-Authenticate challenge.

An MCP server that answers tool enumeration without authentication trusts the network. Under modern threat models (CCS 2007 DNS rebinding, open cloud networking) no network is trustworthy.

sinkprivilege-grant
capability:tools
Full tool authority exposed without identity verification. Any client that reaches the transport can enumerate and (on systems that expose invocation) call every tool.
mitigationauth-checkabsent
capability:tools

No authentication mechanism present at the MCP server layer. Reverse-proxy-terminated auth may exist at a layer the scanner cannot observe; reviewer must confirm via the deployment diagram.

impactprivilege-escalation
server-host

Any network-reachable client can connect and invoke tools with the server's delegated authority. For localhost-bound servers, a malicious web page can still reach the server via DNS rebinding (Jackson/Bortz/Boneh 2007), making localhost no better than 0.0.0.0.

trivial
Confidence75%MCP-Authorization-2025MCP Authorization Specification (mid-2025 adoption)
2 confidence factors
  • +0.1auth-check absentNo auth-check found — No authentication mechanism present at the MCP server layer. Reverse-proxy-terminated auth may exist at a layer the scanner cannot observe; reviewer must confirm via the deployment diagram.
  • +0.2no_auth_confirmed_runtimeLive runtime observation: connection over streamable-http succeeded without credentials. This is not a heuristic — the scanner demonstrated the unauth posture directly.
Methodology3 tests · 6 frameworks
Technique
structural
Tests (3)
  1. null-connection-skip
  2. localhost-does-not-count
  3. proxy-layer-reviewer-note
Lethal edge cases (5)
  • Localhost-only binding is NOT a substitute for auth. Many MCP servers bind to 127.0.0.1 and assume that is sufficient. DNS rebinding makes localhost reachable from any tab in the user's browser. The rule fires on auth_required=false regardless of transport or bind address; the localhost assumption is called out in the impact narrative.
  • stdio transport. An MCP server running over stdio (the process launches the server and pipes to it) inherits the parent process's security boundary. For stdio-launched servers E1 is arguably not material — the parent process is the authentication. The connection metadata populated by the scanner only reaches E1 when a live network connection was made; for stdio-only servers E1 skips silently (connection_metadata=null).
  • "auth_required: false" but auth happens at a higher layer. Some deployments front the MCP server with a reverse proxy that terminates OAuth before the request reaches the server. The scanner cannot see the proxy; a false positive is possible. The verification step explicitly instructs the reviewer to confirm proxy-layer auth before dismissing.
  • connection_metadata is null. When no live connection was made, the rule cannot assert anything about the runtime auth posture. It MUST skip silently (AnalysisCoverage records the gap).
  • auth_required=true but auth is trivially bypassable. The scanner observes whether the server rejects unauthenticated connections, not whether the auth itself is strong. This rule does NOT cover weak-auth cases — that is outside E1's surface (H1 covers OAuth specifically; K6/K7/K8 cover token lifecycle).
Confidence cap
unbounded
Frameworks (6)
  • EU AI ActArt.15Accuracy, Robustness, and Cybersecurity
  • ISO 27001A.5.15Access Control
  • OWASP MCPMCP07Insecure Configuration
  • OWASP ASIASI03Identity & Privilege Abuse
  • CoSAI MCPCoSAI-T1Identity & Authentication Abuse
  • MITRE ATLASAML.T0055Unsecured Credentials
Backing
  • Precision: —
  • Recall: —
  • Red-team fixtures: 3
  • CVE replays: none
  • Last validated: —

Tested cleanly

  • Prompt Injection24 rules tested cleanly
  • Tool Poisoning17 rules tested cleanly
  • Data Exfiltration15 rules tested cleanly
  • Authentication & Identity9 rules tested cleanly
  • Supply Chain Security23 rules tested cleanly
  • Human Oversight6 rules tested cleanly
  • Audit & Logging5 rules tested cleanly
  • Multi-Agent Security1 rule tested cleanly
  • Protocol & Transport15 rules tested cleanly
  • Denial of Service7 rules tested cleanly
  • Container & Runtime10 rules tested cleanly
  • Model Manipulation8 rules tested cleanly
tomba-mcp-server security findings — MCP Sentinel