Category

Code Vulnerabilities

MCP03MCP05MCP07ASI02ASI05CoSAI-T3MAESTRO-L3EU-AI-Act-Art-15AML.T0054#

Exploitable flaws in MCP server source code — classical injection, deserialization, dynamic-code-evaluation, and configuration sinks that arbitrary tool input reaches without sanitization.

1medium
Sub-category

Server-Hardening Failures

11 rule1 finding

Defenses that should be on by default and aren't: error leakage in responses, wildcard CORS, network bind without auth, and ReDoS-prone regex on user input.

Rule
E1

No Authentication Required

MediumMCP07-insecure-config

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

Tests3 strategies

How this rule decides. Each strategy below is a deterministic analysis the detector runs against the MCP server's static metadata, source code, and (when present) live connection handshake.

Primary techniquestructural
  1. 1

    Null Connection Skip

    null-connection-skip
  2. 2

    Localhost Does Not Count

    localhost-does-not-count
  3. 3

    Proxy Layer Reviewer Note

    proxy-layer-reviewer-note
Evidence1 finding

What we found. Each finding below carries a structured proof chain from source (where untrusted data enters) through propagation (how it flows) to a sink (where the dangerous operation occurs), including any mitigations checked for and the potential impact if exploited. Every link is independently verifiable against the cited location.

Proof chain

4 steps from untrusted source to potential impact. Each step is independently verifiable against the cited location.

  1. SourceEnvironment
    Where
    capability:tools
    Observed
    Live connection to the MCP server over streamable-http succeeded with no credentials. `initialize` + `tools/list` returned without any WWW-Authenticate challenge.
    Why untrusted
    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.
  2. SinkPrivilege Grant
    Where
    capability:tools
    Observed
    Full tool authority exposed without identity verification. Any client that reaches the transport can enumerate and (on systems that expose invocation) call every tool.
  3. MitigationAuth CheckAbsent
    Where
    capability:tools
    Detail
    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.
  4. ImpactPrivilege Escalation
    Scope
    server-host
    Exploitability
    Trivial
    Scenario
    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.
Confidence75%
  • +0.1
    auth-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.2
    no_auth_confirmed_runtimeLive runtime observation: connection over streamable-http succeeded without credentials. This is not a heuristic — the scanner demonstrated the unauth posture directly.
Real-world precedent
MCP-Authorization-2025

MCP Authorization Specification (mid-2025 adoption)

The MCP Authorization spec requires OAuth 2.0 (RFC 9700) or equivalent for remote servers. A server that serves initialize + tools/list unauthenticated is out of spec conformance.

How to verify this finding3 steps
  1. 1
    test-input

    Connect 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.

    Target: capability:tools

    Expect: Server responds 200/OK to `initialize` and returns the tool list without a 401/403 or any WWW-Authenticate challenge.

  2. 2
    check-config

    If 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.

    Target: nginx.conf/server/location

    Expect: Either the proxy enforces auth (dismiss with audit trail) or no proxy exists (E1 stands).

  3. 3
    check-config

    Verify 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.

    Target: capability:tools

    Expect: 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).

More — frameworks, edge cases, backing5 edge cases · 6 frameworks
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
Linear security findings — MCP Sentinel