check_resource_allowed(): path matching skips dot-segment/percent-encoding normalization (auth-boundary bypass)

Start in src/mcp/shared/auth_utils.py at check_resource_allowed() and reproduce the dot-segment and percent-encoded examples from the issue. Verify that normalized requested paths cannot escape the configured resource while trailing-slash semantics remain intact, then run the relevant authentication utility tests.

Summary

check_resource_allowed() in src/mcp/shared/auth_utils.py performs hierarchical path matching with str.startswith() after only trailing-slash normalization. It does not resolve dot-segments (.., .) or decode percent-encoding, so a requested resource can satisfy startswith(configured) while resolving to a path outside the configured resource.

This is a confused-deputy / path-traversal gap at the resource-authorization boundary: any downstream resource server that normalizes paths (most do) will serve a different resource than the one the SDK authorized.

Reproduction

from mcp.shared.auth_utils import check_resource_allowed

# Access to /api is configured; /admin is NOT
configured = "https://mcp.example.com/api"
requested  = "https://mcp.example.com/api/../admin"

print(check_resource_allowed(requested, configured))  # -> True (should be False)

The current code normalizes to /api/../admin/ vs /api/, and "/api/../admin/".startswith("/api/") is True. The resolved path is /admin. Percent-encoded variants (%2e%2e) bypass it the same way.

Impact

Where the result gates access to a protected resource, a caller can craft a resource indicator that passes the check but points elsewhere. Severity depends on deployment, but it's an auth-boundary correctness bug, not cosmetic.

Fix

Decode percent-encoding and resolve dot-segments (posixpath.normpath after unquote) on both paths before the startswith comparison, preserving trailing-slash semantics. A patch implementing exactly this was opened as #2585 and closed in the post-v2 backlog sweep with the note to reopen if still relevant against v2 — filing this issue per CONTRIBUTING so it can be triaged. The bug is present verbatim on current main. Happy to refresh the PR against v2 once triaged.