MCP protocol fingerprint responds without an authentication challenge
ShipReady found an MCP protocol marker in a bounded unauthenticated GET response from a known MCP path.
Why it matters
An MCP endpoint should have an intentional access model because it may expose tools or information to clients that can reach it.
How ShipReady detects it
What it inspects
ShipReady sends a bounded plain GET without credentials to a small set of known MCP paths and reads only a limited response prefix for MCP protocol markers.
What triggers a finding
The rule triggers when a response other than 401, 403, or 404 contains a supported MCP fingerprint.
What the evidence shows
A known path returned a response matching the scanner's MCP fingerprint without an HTTP authentication challenge to its plain GET.
Limits of this check
ShipReady does not negotiate an MCP session, list tools, invoke tools, read resources, test authorization inside the protocol, or determine what the endpoint permits. The fingerprint is not proof that tools can be used anonymously.
How to fix it
Define the endpoint access model
Require the intended authentication and authorization controls before exposing MCP capabilities to untrusted clients.
Test the actual protocol flow
Verify that unauthenticated clients cannot establish or use capabilities and that authenticated clients receive only their allowed tools and resources.
How to verify the change
Test unauthenticated MCP behavior
Use a controlled MCP client without credentials to validate the endpoint's intended challenge and authorization behavior.
Expected: Unauthenticated clients cannot access MCP capabilities unless that access is explicitly intended.