Notifications
Clear all
Topic starter
11/08/2026 3:18 pm
TL;DR: A modified otto-support MCP server can be discovered with nmap and a Nuclei template, then abused through direct MCP Inspector tool calls to delete another user’s ticket because authorization checks were missing, according to Bishop Fox. The lesson is that MCP adds a new interface, not new security physics, so web app fundamentals still decide exposure.
NHIMG editorial — based on content published by Bishop Fox: a modified otto-support MCP server analysis showing unauthorized ticket deletion through missing authorization controls
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams secure a remote MCP server?
A: Security teams should place an authentication and authorization layer in front of the MCP server, keep the tool service private where possible, and validate every request before it reaches connected tools.
Q: Why do MCP servers increase the risk of agentic access abuse?
A: MCP servers connect agents to real systems, so a weakly controlled server becomes a privilege bridge rather than a simple integration layer.
Q: What breaks when MCP tool permissions are scoped too broadly?
A: Broad scoping breaks least-privilege governance because the same workload can invoke tools and reach resources far beyond its actual role.
Practitioner guidance
- Inventory every exposed MCP endpoint Treat /mcp, /sse, and any similar tool endpoints as externally reachable application surfaces.
- Enforce server-side authorization on each tool call Require an explicit authorization decision before any tool can read, modify, or delete state.
- Map state-changing tools to identity scopes Assign each privileged tool to a service identity, a scope, and a logged action class.
What's in the full article
Bishop Fox's full post covers the operational detail this post intentionally leaves for the source:
- The exact nmap and Nuclei workflow used to fingerprint the MCP service in a lab environment
- The JSON-RPC request and response structure for direct MCP tool invocation through MCP Inspector
- The specific delete_ticket call pattern that bypassed intended authorization boundaries
- The end-to-end blog series context that connects discovery, interaction, and exploitation paths
👉 Read Bishop Fox's analysis of MCP server discovery and authorization gaps →
MCP server authorization gaps: are your controls keeping up?
Explore further
11/08/2026 3:30 pm
MCP does not create new security physics, it reuses old web application failure modes. The article’s core lesson is that an MCP server exposed to the network behaves like any other privileged API endpoint when an attacker can reach it directly. That means authentication, authorization, validation, and auditability remain the decisive controls. Practitioners should treat MCP as an application security problem with identity consequences, not as a special-case AI exception.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- Another 53% of MCP servers expose credentials through hard-coded values in configuration files, which makes tool exposure and credential exposure reinforce each other.
A question worth separating out:
Q: Who is accountable when an MCP server authorises the wrong action?
A: Accountability sits with the teams that designed and operated the consent, token validation, and scope controls, because MCP makes authorisation decisions part of the system boundary. In regulated environments, the question is not only who clicked approve but who allowed client identity, audience, and delegation checks to remain incomplete.
👉 Read our full editorial: MCP server authorization gaps expose familiar web app failures
