Cve 2026 103758 · AI Security

Obot MCP Gateway Flaw CVE-2026-103758 Lets Basic Users Reach Restricted MCP Servers

Data graphic: a charcoal cover with a large red 8.6 for CVSS v4.0 High 8.1 under CVSS v3.1 and an ACR BYPASS stamp. The headline reads: Any login opens restricted MCP servers CVE-2026-103758 . Obot 0.21.1 to 0.24.1 is affected, v0.25.0 is the fix per Obot release notes, and no exploitation has been reported.
NS

Identity security analyst · Updated Oct 2, 2026, 5:02 PM EDT

Obot 0.21.1–0.24.1 skips its ACR check on the composite MCP route, so any signed-in user can reach restricted servers. Obot says v0.25.0 fixes it.

Obot versions 0.21.1 through 0.24.1 have an authorization bypass in the MCP gateway, tracked as CVE-2026-103758. Any signed-in user, including one with the Basic role, can connect to MCP servers that access control rules (ACRs) restrict to other users by going through the /mcp-connect-composite/ route. Obot's release notes say v0.25.0 fixed it. No source reports exploitation, and the CVE is not in CISA's Known Exploited Vulnerabilities catalog.

What happened

VulnCheck, the CNA, published CVE-2026-103758 on 1 October 2026. Obot had already disclosed the flaw on 17 September 2026 as GitHub advisory GHSA-6fwv-3h4c-37j9, alongside its v0.26.0 release. Both give the same affected range, 0.21.1 through 0.24.1. The advisory credits the report to GitHub user arpitjain099.

The CVE record carries two scores, both High:

  • CVSS v4.0: 8.6 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N)
  • CVSS v3.1: 8.1 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N)

The weakness is CWE-863 (Incorrect Authorization). GitHub also lists CWE-1289. NVD lists the record as "Awaiting Analysis" and has not published its own score.

Why it matters

Obot sits between users and MCP servers. Those servers expose tools to AI clients and agents, and the tools often reach internal systems, data stores and credentials. Administrators use ACRs to decide which users and groups may connect to which servers. The bypass breaks that control: on an affected deployment, any account can use a server the administrator meant to keep for a smaller group.

The exposed deployments are shared Obot instances that rely on ACRs to restrict MCP servers, for example a company gateway where only one team should use a server holding production credentials. The scores mark confidentiality and integrity impact as high and availability impact as none.

The attacker needs a valid Obot account and the ID of a composite MCP server. If every user on an instance is already allowed to use every server, the bypass gives nobody new access.

Technical details

Data graphic: flow diagram of CVE-2026-103758 in the Obot MCP gateway. A Basic-role user's request to /mcp-connect/ matches the ACR deny check and is blocked. The same user's request to /mcp-connect-composite/ misses the prefix, falls through to default allow and reaches a restricted MCP server. Affected 0.21.1 to 0.24.1; fixed in v0.25.0 per Obot release notes; no exploitation reported.

The deny check matched only the /mcp-connect/ prefix, so requests to /mcp-connect-composite/ fell through to default allow. Sources: GHSA-6fwv-3h4c-37j9, Obot v0.26.0 release notes.

Obot blocks lower-privileged users from certain gateway paths with a path-prefix deny list. According to GitHub's advisory, the check matched the prefix /mcp-connect/, with a trailing slash. The composite route is /mcp-connect-composite/{mcp_id}, which does not start with that string. The check therefore did not match, and the authorization function fell through to its default, which allows the request. VulnCheck describes the same gap as the composite route missing from the checkUI deny list.

The flaw is the second half of an earlier fix. Obot's v0.26.0 release notes say the fix for an earlier advisory, GHSA-vw82-7fv8-r6gp, guarded /mcp-connect/ but not the sibling composite route, which reaches the same gateway handler. The notes add that upgrading in response to GHSA-vw82-7fv8-r6gp does not by itself cover this issue.

GitHub's advisory suggests dropping the trailing slash from the prefix or moving the authorization function to deny unknown routes by default. Other gateway and reverse-proxy rule sets have the same weakness: a deny list keyed on path prefixes fails open when someone adds a sibling route.

What defenders should do

  • Upgrade to v0.25.0 or later. Obot's v0.26.0 release notes state that the issue "was fixed in v0.25.0", which shipped on 31 July 2026. The GitHub advisory's patched-version field is empty, and VulnCheck lists no fixed version, so the release notes are the only source for the fix.
  • Plan a move to v0.26 carefully. v0.26.0 replaces composite MCP servers with virtual MCPs (vMCPs). The v0.26.0 and v0.26.1 notes told existing installations not to upgrade. v0.26.2, released on 2 October 2026, supports upgrades from v0.25.x and migrates composite servers to vMCPs. Read its upgrade notes first. From v0.26.0 the Basic role is called Standard.
  • Do not count an earlier patch. If you upgraded only for GHSA-vw82-7fv8-r6gp and are still on v0.24.1 or earlier, you remain exposed.
  • Audit access. Look in gateway and audit logs for requests to /mcp-connect-composite/ from users outside the groups your ACRs allow, and review tool calls made through restricted servers. Neither advisory publishes indicators; this is our suggestion.
  • Rotate credentials if you find misuse. If an unauthorized user reached a server that holds API keys or service credentials, rotate them.
  • Until you upgrade, assume any signed-in user can reach any composite server, and limit who holds accounts. We found no workaround documented by the vendor.

What is still unclear

  • v0.24.2. Obot released v0.24.2 on 26 August 2026. The affected range ends at 0.24.1, but its release notes list no changes, so we could not confirm whether it carries the fix.
  • The patched-version metadata. The GitHub advisory and the CVE record do not yet list a fixed version, so scanners that rely on that data may not flag v0.25.0 as fixed.
  • Exploitation. No source reports exploitation, and CVE-2026-103758 was not in the KEV catalog as of its 2 October 2026 version. NVD has not finished its analysis.

Sources