Description

1MCP Agent (@1mcp/agent) 0.20.0 through 0.39.0 contains an incorrect authorization vulnerability that allows authenticated clients to bypass OAuth tag-scope enforcement using negated advanced tag-filter expressions. Attackers holding a single-tag token can send a filter like not <granted-tag> to list and invoke tools on backend MCP servers outside their granted scopes.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-10-10T17:17:00.593Z",
  "pubdate": "2026-10-10T17:17:00.593Z",
  "executiveSummary": "The 1MCP Agent, versions 0.20.0 through 0.39.0, is affected by an incorrect authorization vulnerability related to the enforcement of OAuth tag-scopes.\nThis vulnerability allows an authenticated client, possessing a token restricted to a specific set of tags, to circumvent intended authorization constraints.\nBy utilizing crafted, negated advanced tag-filter expressions, an attacker can effectively negate their restricted scope, resulting in unauthorized access to tools and data hosted on backend MCP servers.\nThe core issue lies in the improper processing of logic within the tag-filter engine, which fails to restrict the evaluation of NOT operators in a manner that respects original scope assignments.\nThis permits attackers to list and invoke tools that should be strictly prohibited based on their granted permissions.\nThe risk implication is significant as it facilitates unauthorized interaction with backend services, potentially leading to unauthorized data exfiltration, system manipulation, or further escalation within the MCP ecosystem.\nExploitation requires the attacker to hold an existing, albeit limited, authenticated token to initiate requests against the MCP agent.",
  "technicalDetails": "The vulnerability originates in the logic utilized by the 1MCP Agent to validate client requests against assigned OAuth tag-scopes. When a client requests interaction with a backend MCP server, the agent applies a filter to verify that the request is authorized based on the tags embedded within the user's authentication token.\nThe root cause is an insecure implementation of the advanced tag-filter parser, which inadequately sanitizes or restricts the use of negation operators (specifically the 'not' keyword) in filter expressions. Instead of restricting the scope to the intersection of the token's granted tags and the requested resource, the agent evaluates the filter expression as a logical condition that the token must satisfy.\nBy submitting a payload that incorporates a negation operator—such as 'not <granted-tag>'—an attacker manipulates the filter evaluation engine. If the attacker is granted a specific 'low-privilege' tag, they can construct a query that evaluates to true for unauthorized resources by asserting that the resource does not possess the granted tag, or by negating the constraint entirely to bypass the membership check.\nThe attack flow follows these steps: 1) The attacker authenticates to the 1MCP Agent with a token scoped to a limited subset of tags. 2) The attacker identifies a target tool or backend MCP server that is currently restricted from their access level. 3) The attacker submits an RPC or tool invocation request containing a manipulated tag-filter expression using the 'not' operator. 4) The agent's authorization component processes the negated filter expression without enforcing that the logical result must remain within the user's original scope boundary. 5) The filter engine incorrectly returns a 'permitted' status for the unauthorized resource. 6) The backend MCP server executes the requested tool or returns the requested data to the attacker.\nThis vulnerability allows authenticated users to effectively expand their privilege set, moving from a restricted context to an unconstrained one relative to the backend MCP infrastructure. Because the agent acts as a gateway, the scope bypass remains transparent to the downstream MCP servers, which rely on the agent to perform primary authorization checks. The exposure is limited to authenticated clients, but the privilege escalation within the agent's internal authorization logic is critical for any multi-tenant deployment."
}