1MCP Agent Flaw Lets a Single-Tag Token Reach MCP Servers Outside Its Scope

A newly published vulnerability in 1MCP Agent, an open-source gateway that aggregates many Model Context Protocol servers behind one HTTP API, lets an authenticated client reach backend servers its OAuth token was never meant to touch. Tracked as CVE-2026-108586 and published on October 10, 2026, the flaw affects the @1mcp/agent package from version 0.20.0 through 0.39.0. The CVE record, assigned by VulnCheck, classifies it as CWE-863 Incorrect Authorization and rates it 5.3 (Medium) under CVSS 4.0 and 5.4 under CVSS 3.1.

At the time of publication, 0.39.0, released on October 9, was the latest tagged version of the project and falls inside the affected range. No fixed release was listed in the CVE record, so the guidance below is limited to mitigation.

A Gateway That Fences MCP Servers by Tag

1MCP Agent, hosted at 1mcp-app/agent on GitHub under the Apache 2.0 license, describes itself as “a unified Model Context Protocol server implementation that aggregates multiple MCP servers into one.” Teams use gateways like it to give AI agents and coding assistants a single endpoint for many tools, such as file systems, databases, cloud services and internal APIs.

To control who sees what, 1MCP tags each backend server and issues OAuth tokens that are granted specific tags. The project documents those tag scopes as a fine-grained access boundary. A token granted only an “internal” tag, for example, should be able to list and call tools on internal backends and nothing else.

How the boundary fails

According to the CVE description, authenticated clients holding a single-tag token can bypass that enforcement by sending a negated advanced tag-filter expression. The gateway’s HTTP API accepts boolean filter expressions, and the researcher who reported the issue, HaiND (Nguyen Dinh Hai) of the Post and Telecommunication Institute of Technology, traced the problem to how the authorization check and the filter interact.

In the researcher’s write-up, the scope check confirms that every tag named in an expression belongs to the token. It does not confirm that the servers the expression selects stay within that grant. A negated expression names only a tag the caller is allowed to use, so it passes authorization, but then selects every backend that does not carry that tag, which is precisely the set the token was excluded from. Because the same selection drives both the tool listing and the tool-invocation path, and invocation adds no second scope check, the out-of-scope tools are not just visible but callable.

The researcher verified the behavior at the function level using the project’s real parser and evaluator, and states that a full live deployment with issued OAuth tokens and real backends was not stood up. It does not claim unauthenticated access or token theft. The practical impact depends on what the out-of-scope backends can do. In a multi-tenant deployment where tenants hold different tags, it would amount to one tenant reaching another tenant’s tools. In a tiered single-tenant setup, a low-tier token could reach higher-tier backends.

Only Tag-Scoped Deployments Are at Risk

The issue matters only in a specific configuration: authentication and scope validation are enabled, tag scopes are used as the access boundary, a caller holds a token with at least one granted tag, and at least one backend carries a tag outside that grant. Deployments that issue every client full access, or that do not rely on tags for separation, gain no new exposure from this bug.

Mitigation until a fix ships

With no patched release listed, operators running 1MCP Agent in the affected range can reduce risk with configuration and deployment changes:

• Do not treat tag scopes as a tenant boundary for now. Where different tenants or privilege tiers need isolation, run separate 1MCP instances per tenant or tier so that each gateway only aggregates backends that every one of its callers is allowed to use.
• Move sensitive backends off shared gateways. Servers that expose file systems, databases, cloud credentials or administrative tools should not sit behind a gateway that also serves lower-privilege tokens.
• Limit who can obtain tokens and reach the API. Restrict the HTTP API to trusted networks, keep token issuance tight, and revoke tokens that are no longer needed.
• Watch request logs for advanced filter use. Unexpected tag-filter expressions, especially negations, from restricted tokens are worth investigating.
• Track the project’s releases. The researcher’s write-up proposes intersecting every filter result with the token’s granted tags and re-checking scope at invocation time. Operators should upgrade once a release that addresses CVE-2026-108586 is published and confirm the fix in the release notes.

The disclosure is a reminder that MCP gateways concentrate access. When one endpoint fronts many tools, a single authorization gap in its filtering logic can widen what every connected agent is able to do.